develooper Front page | perl.perl5.porters | Postings from August 2021

Re: PSC #034 2021-08-20 - "Namespaces Special"

Thread Previous | Thread Next
From:
Darren Duncan
Date:
August 28, 2021 03:47
Subject:
Re: PSC #034 2021-08-20 - "Namespaces Special"
Message ID:
609c4e11-6ff0-bd29-be10-06aad1fdd60d@darrenduncan.net
To start, I generally like the proposal made in this thread.

On 2021-08-27 5:08 a.m., Paul "LeoNerd" Evans wrote:
> We all generally agreed here - some other mechanism should exist, and
> if it had existed at the time when such features as `fc` were added
> then no doubt we would have used that, rather than the way they have
> been.

I'm thinking that once the new mechanism is implemented, a lot of existing 
routines such as `fc` should be converted to be implemented by it as if the 
feature had existed when they were introduced.

>    * What is the actual name for the fully-qualified namespace used by
>     these new functions? We used "builtin" during the discussion, but if
>      you have to `use` a module to get at them they can hardly be said to
>      be built-in

For my part, with my Muldis Data Language, I had decided on the namespace 
"foundation" for all the built-in routines whose implementations are hidden from 
the user and in terms of which (along with non-routine language fundamentals) 
all other routines are defined.  This isn't as short as "builtin" but the word 
itself doesn't imply its built in.

>    * Should it interact with `use VERSION`? Since we're already in a
>      world where `use VERSION` implies strict + warnings + a feature
>      bundle, it would be easy enough to suggest that it also pulls in a
>      function bundle of the same version. It would be nice if you could
> 
>          #!perl
>          use v5.40;
>          say "The reftype of arrays is ", reftype [];

I'm thinking that "use vN;" by itself should implicitly make available the 
ability to say "builtin::foo()" AND the set of foo() available will directly 
depend on the version in "use vN;" meaning we are more free to change the 
built-in set at any time in any way without breaking compatibility because its 
behavior matches the "use vN;" that is explicitly opted in to.

If one explicitly says "use builtin;" without a list then that is redundant with 
what the "use vN" already does in newer Perls.  While having a version with "use 
builtin vN" makes sense for a CPAN module back-porting the feature, combining it 
with a "use vN;" in newer Perls should perhaps be considered an error.

Also, "use vN;" should never import anything; instead one should have to 
explicitly "use builtin 'foo', 'bar', 'baz';" etc to import things, although you 
could have named bundles to make that more terse.

-- Darren Duncan

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About