Mailing List Archive

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

A special single-subject meeting to look into the "namespaces" question
which has been lurking. We invited a few extra people who have
expressed thoughts in that direction:

Present: Karl Williamson, Nicholas Clark, Paul Evans, Ricardo Signes,
Yves Orton


We began by revisiting the original questions that had led us to this
point. These were mostly concerns about how to add new functions to the
Perl language that had come up in the discussions about adding `trim`
and a few other places. It has been previously observed that using
feature bits via the `use feature` pragma are fine enough for genuinely
new syntax features such as control-flow syntax, but they are not a
good fit for adding things that look and behave like "regular"
functions.

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.

Having established this as the overall theme of the discussion, we
moved to focus on what should be provided instead and how it should
behave. We felt it would be nice to be:

* A polyfill - i.e. use some familiar syntax like
"use SomeModule qw( some function names );" so that a dual-life
module can be made and put on CPAN, allowing older perls to make
use of it.

* Lexical - much like `use strict`, `use feature`, etc.. rather than
any of the "inject subs into caller's package" ideas like Exporter.

Once these points we made, we observed that we still hadn't actually
answered a question of what namespaces should actually be provided. Or
even whether it was necessary to provide more than one at all. Various
previous email discussions had hinted at thoughts like "string" and
"ref" and "math" and "net" and so on, but so far we haven't really seen
a case to suggest needing more than one. If instead we say we'll just
take a single namespace, then that removes concerns like having to
decide which space everything lives in. It also adds a bit of "don't
add too much" pressure, and keeps minds focused on ensuring everything
has a unique name, thus avoiding such questions like "what if we wanted
both string::length and array::length?". If there's only one space of
names then there would need to be a fairly high bar to entry, as to
what we consider for inclusion. We don't want to create a thousand new
built-in functions that are all trivial variations on things that can
be done with existing Perl syntax and/or regular modules in core or on
CPAN. The space should be for things that are outright impossible in
pureperl (e.g. Scalar::Util::weaken()), or things that are
prohibitively expensive or complex to implement in that manner.

Since there didn't seem to be a case for adding multiple names we
proceeded on the basis of having just one. While we hadn't settled on a
name (see "outstanding questions" below), we had to pick something for
discussion purposes, so we settled on "builtin". It isn't ideal (see
below) but it serves for now.

The basic thought was roughly that new perls going forward would just
have a bunch of functions always available by a fully-qualified name,
such as `builtin::reftype`, that could be called immediately without
having to "use" anything; e.g. as

#!perl
print "The type of array refs is ", builtin::reftype([]), "\n";

or

$ perl -E 'say "The type of arrayrefs is ", builtin::reftype([])'

There would exist some module - perhaps of the same name - such that
you can (lexically) import these as short names:

#!perl
use builtin 'reftype';
print "The type of array refs is ", reftype([]), "\n";

It being a lexical import means it acts much like "use feature" et.al,
rather than package imports which cause namespace-pollution issues for
things like object classes. This was felt to be a useful property,
outweighing the "it is different to e.g. use Scalar::Util " feeling. In
any case it's an all-lowercase pragmatic module, it's allowed to feel
different.

Since we're looking at just one actual "namespace" for normal
functions, we wondered if actually the existing CORE::GLOBAL::
mechanism would already be sufficient for this. It turns out not really
- you can't add new names to it, only override existing ones, so it
wouldn't work as a polyfill mechanism on older perls.

For publishing a polyfill module, there were thoughts on how it should
be version-numbered, and whether the syntax ought to *mandate* that you
include a version number in the `use` statement. E.g. it's often a good
idea to `use List::Util v1.29 'pairs'` so if the List::Util module is
too old you get a nicer error message. But should we mandate this for
the functions module?

Next came the question of what actual functions to provide in this
mechanism. It seemed fairly noncontroversial that such things as
Scalar::Util::reftype() and ::blessed() would be available. There also
seems to be a case for things like POSIX::ceil() and ::floor(), which
seem good to have in the core language and not need to pull in the
giant POSIX.so just for that. The discussion continued into listing
more places where such things could be found - such as Internals::,
UNIVERSAL.c - but it seems we can consider these on a casewise basis,
once the initial mechanism is inplace and the overall shape seems like
a good one.

As time was nearly up, we decided there seemed a good enough place to
begin wrapping up. We were in fairly good agreement that a mechanism
needs to be created, and roughly what shape it should have. There
became evident a bunch of more specific questions about it, that seems
a good place to finish on as these are good candidates for further
discussion:

* 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

* What is the name of the shim-loader pragma module used to obtain the
shortname lexical aliases? It could match the function namespace,
but it doesn't have to. Other candidates include "function" or
"functions". Though they bear a visual similarity to the "feature"
module, which we are trying to avoid. Maybe there are some other
words to be found.

* What functions to actually include in this new namespace? We already
have quite a few candidates for places to look for existing ideas,
which should be sufficient to try out the mechanism before we think
about adding actually-new ones:
+ `Scalar::Util`
+ Existing features like `fc`
+ UNIVERSAL.c
+ The badly-named `Internals::`
+ Commonly-used POSIX functions like `ceil()`
+ Rarely-used POSIXisms in core perl like `gethostbyname`

* 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 [];


--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: PSC #034 2021-08-20 - "Namespaces Special" [ In reply to ]
Hi,


Thanks for the excelent writeup!


Op 27-08-2021 om 14:08 schreef Paul "LeoNerd" Evans:

...
> * 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


std::<function> is nice and short, even if a bit c++ish.


>
> * What is the name of the shim-loader pragma module used to obtain the
> shortname lexical aliases? It could match the function namespace,
> but it doesn't have to. Other candidates include "function" or
> "functions". Though they bear a visual similarity to the "feature"
> module, which we are trying to avoid. Maybe there are some other
> words to be found.


use std '<function>'; would serve I think.


> * What functions to actually include in this new namespace? We already
> have quite a few candidates for places to look for existing ideas,
> which should be sufficient to try out the mechanism before we think
> about adding actually-new ones:
> + `Scalar::Util`
> + Existing features like `fc`
> + UNIVERSAL.c
> + The badly-named `Internals::`
> + Commonly-used POSIX functions like `ceil()`
> + Rarely-used POSIXisms in core perl like `gethostbyname`


I cannot remember the last time I used ceil, but I use gethostbyname a
lot. But that may just me. I do not see a huge added value from removing
gethostbyname and others from the global namespace other than
orthogonality, but I  don't care to much either.


>
> * 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 [];


What to include and what not? As there is no backwards compatibility
issue, it is just a matter of taste and bikeshedding, but I think
restraint should be excerised. Once the deamon is out of the box, it
cannot be put back.


HTH,

M4
Re: PSC #034 2021-08-20 - "Namespaces Special" [ In reply to ]
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
Re: PSC #034 2021-08-20 - "Namespaces Special" [ In reply to ]
On Fri, Aug 27, 2021 at 11:47 PM Darren Duncan <darren@darrenduncan.net>
wrote:

>
> 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.
>

FWIW, "use VERSION" already can make keywords available lexically via
features, which is not quite importing but is the mechanism proposed here.

-Dan
Re: PSC #034 2021-08-20 - "Namespaces Special" [ In reply to ]
On Fri, Aug 27, 2021 at 9:23 PM Martijn Lievaart <m@rtij.nl> wrote:

> Hi,
>
>
> Thanks for the excelent writeup!
>
>
> Op 27-08-2021 om 14:08 schreef Paul "LeoNerd" Evans:
>
> ...
> > * 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
>
>
> std::<function> is nice and short, even if a bit c++ish.
>
> I second the idea that 'std' would be a great namespace. It's short and to
the point. I think there's also an optics benefit, that I think there's
some level of expectation for perl to have a "standard library".
Re: PSC #034 2021-08-20 - "Namespaces Special" [ In reply to ]
2021-8-27 21:08 Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:

>
> #!perl
> use v5.40;
> say "The reftype of arrays is ", reftype [];
>
>
>
There is one point I would like PSC to add to the discussion.

Are all builtin functions imported to the "main" namespace?

Or, are just only the functions we consider very important imported to the
"main" namespace?

I would like to add this to the discussion because the "main" namespace is
also the user's space, so smaller conflicts are better.
Re: PSC #034 2021-08-20 - "Namespaces Special" [ In reply to ]
* Yuki Kimoto <kimoto.yuki@gmail.com> [2021-08-30 12:46:19 +0900]:

> 2021-8-27 21:08 Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:
>
> >
> > #!perl
> > use v5.40;
> > say "The reftype of arrays is ", reftype [];
> >
> >
> >
> There is one point I would like PSC to add to the discussion.
>
> Are all builtin functions imported to the "main" namespace?
>
> Or, are just only the functions we consider very important imported to the
> "main" namespace?
>
> I would like to add this to the discussion because the "main" namespace is
> also the user's space, so smaller conflicts are better.

This all came about, IIRC, because off the "trim" drama. Can we add this to the
list of "test" cases for what it'd look like? IOW, as the discussion progresses,
it'd be helpful to see how this translated into real life to address one of the
main points of contention related to trim. I.e., the well founded fear that this
would admit a large number of "string" functions into the "main" namespace.

Cheers,
Brett

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native
Re: PSC #034 2021-08-20 - "Namespaces Special" [ In reply to ]
On Sun, Aug 29, 2021 at 11:46 PM Yuki Kimoto <kimoto.yuki@gmail.com> wrote:

>
> 2021-8-27 21:08 Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:
>
>>
>> #!perl
>> use v5.40;
>> say "The reftype of arrays is ", reftype [];
>>
>>
>>
> There is one point I would like PSC to add to the discussion.
>
> Are all builtin functions imported to the "main" namespace?
>
> Or, are just only the functions we consider very important imported to the
> "main" namespace?
>
> I would like to add this to the discussion because the "main" namespace is
> also the user's space, so smaller conflicts are better.
>

It won't go into any namespace if it is implemented as a lexical keyword
like you get from feature.pm.

-Dan
Re: PSC #034 2021-08-20 - "Namespaces Special" [ In reply to ]
On Mon, Aug 30, 2021 at 12:30 AM Dan Book <grinnz@gmail.com> wrote:

> On Sun, Aug 29, 2021 at 11:46 PM Yuki Kimoto <kimoto.yuki@gmail.com>
> wrote:
>
>>
>> 2021-8-27 21:08 Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:
>>
>>>
>>> #!perl
>>> use v5.40;
>>> say "The reftype of arrays is ", reftype [];
>>>
>>>
>>>
>> There is one point I would like PSC to add to the discussion.
>>
>> Are all builtin functions imported to the "main" namespace?
>>
>> Or, are just only the functions we consider very important imported
>> to the "main" namespace?
>>
>> I would like to add this to the discussion because the "main" namespace
>> is also the user's space, so smaller conflicts are better.
>>
>
> It won't go into any namespace if it is implemented as a lexical keyword
> like you get from feature.pm.
>

And furthermore, builtins are not in main either, they are in CORE.

-Dan
Re: PSC #034 2021-08-20 - "Namespaces Special" [ In reply to ]
2021-8-30 13:30 Dan Book <grinnz@gmail.com> wrote:

> On Sun, Aug 29, 2021 at 11:46 PM Yuki Kimoto <kimoto.yuki@gmail.com>
> wrote:
>
>>
>> 2021-8-27 21:08 Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:
>>
>>>
>>> #!perl
>>> use v5.40;
>>> say "The reftype of arrays is ", reftype [];
>>>
>>>
>>>
>> There is one point I would like PSC to add to the discussion.
>>
>> Are all builtin functions imported to the "main" namespace?
>>
>> Or, are just only the functions we consider very important imported
>> to the "main" namespace?
>>
>> I would like to add this to the discussion because the "main" namespace
>> is also the user's space, so smaller conflicts are better.
>>
>
> It won't go into any namespace if it is implemented as a lexical keyword
> like you get from feature.pm.
>
> -Dan
>

>> And furthermore, builtins are not in main either, they are in CORE.

Dan, thank you for the information.

From now on, I will say CORE.

I understand that is lexical.

My point is that already imported user functions need fully qualified names.

For example, Think about that the generic name ”get" is added to CORE
namespace.

User "get" function needs a fully qualified name.

# Old code
use Foo 'get';

get '/aaa';

# New code
use v5.40;

use Foo ();

Foo::get '/aaa';

So I feel it would be better to have fewer collisions.
Re: PSC #034 2021-08-20 - "Namespaces Special" [ In reply to ]
On Mon, Aug 30, 2021 at 1:09 AM Yuki Kimoto <kimoto.yuki@gmail.com> wrote:

>
> 2021-8-30 13:30 Dan Book <grinnz@gmail.com> wrote:
>
>> On Sun, Aug 29, 2021 at 11:46 PM Yuki Kimoto <kimoto.yuki@gmail.com>
>> wrote:
>>
>>>
>>> 2021-8-27 21:08 Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:
>>>
>>>>
>>>> #!perl
>>>> use v5.40;
>>>> say "The reftype of arrays is ", reftype [];
>>>>
>>>>
>>>>
>>> There is one point I would like PSC to add to the discussion.
>>>
>>> Are all builtin functions imported to the "main" namespace?
>>>
>>> Or, are just only the functions we consider very important imported
>>> to the "main" namespace?
>>>
>>> I would like to add this to the discussion because the "main" namespace
>>> is also the user's space, so smaller conflicts are better.
>>>
>>
>> It won't go into any namespace if it is implemented as a lexical keyword
>> like you get from feature.pm.
>>
>> -Dan
>>
>
> >> And furthermore, builtins are not in main either, they are in CORE.
>
> Dan, thank you for the information.
>
> From now on, I will say CORE.
>
> I understand that is lexical.
>
> My point is that already imported user functions need fully qualified
> names.
>
> For example, Think about that the generic name ”get" is added to CORE
> namespace.
>
> User "get" function needs a fully qualified name.
>
> # Old code
> use Foo 'get';
>
> get '/aaa';
>
> # New code
> use v5.40;
>
> use Foo ();
>
> Foo::get '/aaa';
>
> So I feel it would be better to have fewer collisions.
>

Imported symbols override builtins already, this is how modules like
autodie and Time::HiRes work. But yes, this chance of collision is
unavoidable and we have to take more care with more common names.

-Dan
Re: PSC #034 2021-08-20 - "Namespaces Special" [ In reply to ]
2021-8-30 14:12 Dan Book <grinnz@gmail.com> wrote:

> On Mon, Aug 30, 2021 at 1:09 AM Yuki Kimoto <kimoto.yuki@gmail.com> wrote:
>
> Imported symbols override builtins already, this is how modules like
> autodie and Time::HiRes work. But yes, this chance of collision is
> unavoidable and we have to take more care with more common names.
>
> -Dan
>

> Imported symbols override builtins already

Is this really?

perl -E 'sub substr { print "substr\n" }; substr();'

Output

Not enough arguments for substr at -e line 1, near "substr()"
Execution of -e aborted due to compilation errors.

Imported symbols don't seem to override CORE::substr,

Although the following is OK.

perl -E 'sub substr { print "substr\n" }; &substr();'

Output

substr
Re: PSC #034 2021-08-20 - "Namespaces Special" [ In reply to ]
Am 30.08.21 um 10:01 schrieb Yuki Kimoto:
>
> Is this really?
>
> perl -E 'sub substr { print "substr\n" }; substr();'
>
> Output
>
> Not enough arguments for substr at -e line 1, near "substr()"
> Execution of -e aborted due to compilation errors.
>
> Imported symbols don't seem to override CORE::substr,
>
> Although the following is OK.
>
> perl -E 'sub substr { print "substr\n" }; &substr();'
>
> Output
>
> substr
>

$ cat test_import.pl
#!/usr/bin/perl

use v5.20;

use strict;
use warnings;

use lib '.';
use MYImport;

substr();

$ cat MYImport.pm
package MYImport;

use parent 'Exporter';

our @EXPORT = qw(substr);

sub substr {
    print "substr\n";
}

1;

$ perl test_import.pl
substr
Re: PSC #034 2021-08-20 - "Namespaces Special" [ In reply to ]
On Mon, Aug 30, 2021 at 10:02 AM Yuki Kimoto <kimoto.yuki@gmail.com> wrote:

>
> 2021-8-30 14:12 Dan Book <grinnz@gmail.com> wrote:
>
>> On Mon, Aug 30, 2021 at 1:09 AM Yuki Kimoto <kimoto.yuki@gmail.com>
>> wrote:
>>
>> Imported symbols override builtins already, this is how modules like
>> autodie and Time::HiRes work. But yes, this chance of collision is
>> unavoidable and we have to take more care with more common names.
>>
>> -Dan
>>
>
> > Imported symbols override builtins already
>
> Is this really?
>
> perl -E 'sub substr { print "substr\n" }; substr();'
>
> Output
>
> Not enough arguments for substr at -e line 1, near "substr()"
> Execution of -e aborted due to compilation errors.
>
> Imported symbols don't seem to override CORE::substr,
>

That's not actually imported though.

$ perl -E 'BEGIN { package foo; *::substr=sub { print "substr\n" } }
substr();'
substr
$

Yes, it needs that package declaration …


Eirik
Re: PSC #034 2021-08-20 - "Namespaces Special" [ In reply to ]
In my mind, the initial list of functions that could be eligible to be
moved to std:: (or whatever we bikeshed the namespace to be) is the full
list of "overridable" functions -- that is, the things that don't *have* to
be built in to the parser itself.

This is a useful resource for identifying which those are:
https://stackoverflow.com/questions/3678882/which-perl-built-ins-cannot-be-overridden-in-coreglobal/3678957#3678957


On Mon, Aug 30, 2021 at 3:21 AM Eirik Berg Hanssen <
Eirik-Berg.Hanssen@allverden.no> wrote:

> On Mon, Aug 30, 2021 at 10:02 AM Yuki Kimoto <kimoto.yuki@gmail.com>
> wrote:
>
>> 2021-8-30 14:12 Dan Book <grinnz@gmail.com> wrote:
>>
>>> On Mon, Aug 30, 2021 at 1:09 AM Yuki Kimoto <kimoto.yuki@gmail.com>
>>> wrote:
>>>
>>> Imported symbols override builtins already, this is how modules like
>>> autodie and Time::HiRes work. But yes, this chance of collision is
>>> unavoidable and we have to take more care with more common names.
>>>
>>
Re: PSC #034 2021-08-20 - "Namespaces Special" [ In reply to ]
2021-8-30 17:16 Renée Bäcker <p5p.list@perl-services.de> wrote:

> Am 30.08.21 um 10:01 schrieb Yuki Kimoto:
> >
> > Is this really?
> >
> > perl -E 'sub substr { print "substr\n" }; substr();'
> >
> > Output
> >
> > Not enough arguments for substr at -e line 1, near "substr()"
> > Execution of -e aborted due to compilation errors.
> >
> > Imported symbols don't seem to override CORE::substr,
> >
> > Although the following is OK.
> >
> > perl -E 'sub substr { print "substr\n" }; &substr();'
> >
> > Output
> >
> > substr
> >
>
> $ cat test_import.pl
> #!/usr/bin/perl
>
> use v5.20;
>
> use strict;
> use warnings;
>
> use lib '.';
> use MYImport;
>
> substr();
>
> $ cat MYImport.pm
> package MYImport;
>
> use parent 'Exporter';
>
> our @EXPORT = qw(substr);
>
> sub substr {
> print "substr\n";
> }
>
> 1;
>
> $ perl test_import.pl
> substr
>
>
Renée, Eirik

Thank you.

I have understood that subroutine import and sub declaration in the current
package are different.

feature doesn't break imported subroutines, on the other hand, breaks sub
declaration.

perl -e 'use strict;use warnings;use feature "say"; sub say { print "ppp"
} say("aaa")'

Output

aaa

1. It has no effect on the CPAN libraries or user libraries.
2. It affects the user script, so it needs to be rewritten a little in
lexical scope.
Re: PSC #034 2021-08-20 - "Namespaces Special" [ In reply to ]
Op 31-08-2021 om 02:44 schreef Yuki Kimoto:
>
> 1. It has no effect on the CPAN libraries or user libraries.
> 2. It affects the user script, so it needs to be rewritten a little in
> lexical scope.


That is exactly why there always is a feature guard of some form, so
thhe user has to opt in to the new behaviour.


HTH,

M4
Re: PSC #034 2021-08-20 - "Namespaces Special" [ In reply to ]
On Mon, 30 Aug 2021 at 05:46, Yuki Kimoto <kimoto.yuki@gmail.com> wrote:

>
> 2021-8-27 21:08 Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:
>
>>
>> #!perl
>> use v5.40;
>> say "The reftype of arrays is ", reftype [];
>>
>>
>>
> There is one point I would like PSC to add to the discussion.
>
> Are all builtin functions imported to the "main" namespace?
>

No. That is the point of having a different namespace that is reserved for
this purpose. Functions would be imported from the "builtin" namespace
(whatever that might be) similarly to any other import. And in the shim
logic they might imported into the builtin namespace for you, as well as
optionally imported into your package.

eg: consider:

use builtin v5.32; # ensure that this perl has the builtin's necessary to
similute 5.32's set of functions

versus:

use builtin v5.32 qw(whatever); # ensure that this perl has the builtin's
necessary to simulate 5.32's functions, and import "whatever".

The former would ensure that builtin::whatever would be available assuming
it was part of 5.32's functions. The latter, would do the same but also
export "whatever" into your namespace. The version might be mandatory, so
that if you say:

use builtin v5.32 qw(whatevr); # ensure that this perl has the builtin's
necessary to simulate 5.32's functions, and try to import "whatevr".

we can do an error message like one of the following:

"Function "whatevr" is not a valid function from the v5.32 builtin
namespace, this either means this function was introduced in a later
version, or it means you have typoed the function name".
"This person does not have the shim modules in place to support v5.32
builtin namespace, install the latest version of the "builtin"
distribuition from CPAN"

depending on whether their perl is newer than 5.32 or if they have the
latest version of the builtin backcompat layer (however that might work in
practice).

cheers,
Yves


--
perl -Mre=debug -e "/just|another|perl|hacker/"
Re: PSC #034 2021-08-20 - "Namespaces Special" [ In reply to ]
Lexical method names? C<my sub foo {...}> works or no?

how about "my use ..." to somehow make caller()[0] refer to the top pad
instead of the package?



> * Lexical - much like `use strict`, `use feature`, etc.. rather than
> any of the "inject subs into caller's package" ideas like Exporter.
>
--
"Lay off that whiskey, and let that cocaine be!" -- Johnny Cash
Re: PSC #034 2021-08-20 - "Namespaces Special" [ In reply to ]
2021-9-1 0:06 demerphq <demerphq@gmail.com> wrote:

> On Mon, 30 Aug 2021 at 05:46, Yuki Kimoto <kimoto.yuki@gmail.com> wrote:
>
>>
>> 2021-8-27 21:08 Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:
>>
>>>
>>> #!perl
>>> use v5.40;
>>> say "The reftype of arrays is ", reftype [];
>>>
>>>
>>>
>> There is one point I would like PSC to add to the discussion.
>>
>> Are all builtin functions imported to the "main" namespace?
>>
>
> No. That is the point of having a different namespace that is reserved for
> this purpose. Functions would be imported from the "builtin" namespace
> (whatever that might be) similarly to any other import. And in the shim
> logic they might imported into the builtin namespace for you, as well as
> optionally imported into your package.
>
> eg: consider:
>
> use builtin v5.32; # ensure that this perl has the builtin's necessary to
> similute 5.32's set of functions
>
> versus:
>
> use builtin v5.32 qw(whatever); # ensure that this perl has the builtin's
> necessary to simulate 5.32's functions, and import "whatever".
>
> The former would ensure that builtin::whatever would be available assuming
> it was part of 5.32's functions. The latter, would do the same but also
> export "whatever" into your namespace. The version might be mandatory, so
> that if you say:
>
> use builtin v5.32 qw(whatevr); # ensure that this perl has the builtin's
> necessary to simulate 5.32's functions, and try to import "whatevr".
>
> we can do an error message like one of the following:
>
> "Function "whatevr" is not a valid function from the v5.32 builtin
> namespace, this either means this function was introduced in a later
> version, or it means you have typoed the function name".
> "This person does not have the shim modules in place to support v5.32
> builtin namespace, install the latest version of the "builtin"
> distribuition from CPAN"
>
> depending on whether their perl is newer than 5.32 or if they have the
> latest version of the builtin backcompat layer (however that might work in
> practice).
>
> cheers,
> Yves
>
>
> --
> perl -Mre=debug -e "/just|another|perl|hacker/"
>

demerphq. Thank you for your reply.

I would like to confirm with an expected example.

Perl 5.40 implements the following functions.

builtin::foo
builtin::bar
builtin::baz

use v5.40;

# OK
builtin::foo
builtin::bar
builtin::baz

# Not OK
foo
bar
baz

Perl 5.42 decides builtin::foo should be into CORE namespace.

use v5.42;

# OK
builtin::foo
builtin::bar
builtin::baz
foo

# Not OK
bar
baz

Is the Perl core team aiming for something like this?
Re: PSC #034 2021-08-20 - "Namespaces Special" [ In reply to ]
On Wed, 1 Sept 2021 at 02:50, Yuki Kimoto <kimoto.yuki@gmail.com> wrote:

> demerphq. Thank you for your reply.
>
> I would like to confirm with an expected example.
>
> Perl 5.40 implements the following functions.
>
> builtin::foo
> builtin::bar
> builtin::baz
>
> use v5.40;
>

The intersection of "use v5.40" and the builtin namespaces isnt well
defined yet. Personally I would expect it to imply: `use builtin v5.40;`
eg, it would NOT import any subs into the existing namespace, only make
sure that the builtin namespace is properly populated with the subs from
5.40. We didnt discuss this intersection in /too/ much detail, so I would
have to defer to the others from the call but to me its hard to imagine
that combining it with the import form would be helpful, as I can easily
imagine someone saying "I need a way to assert im on the right version, but
I dont want my namespace messed up". For instance, imagine we add some new
control keywords to the language. Those CANT be represented by builtin's so
they need to be tied to features or the version. But we also add some new
functions. I would expect that I can have a way where I get access to the
keywords, but do not want to pollute my namespace with the new functions.
So I expect that use v5.40 would NOT import functions but it would ensure
that they are available.

The whole point of the builtin mechanism is to provide a way to eliminate
surprise and controversy when we add new functions to the language. Much of
the debate is predicated that the functions will have some cost on
developers, and much of this cost is related to those functions being tied
to versions and being forcibly injected into every namespace. By decoupling
the addition of new functions from the namespaces they will occupy we
sidestep this controversy. I think few would object to the language
receiving a new function they personally will not use, provided they never
need to worry about it at all.


>
> # OK
> builtin::foo
> builtin::bar
> builtin::baz
>
> # Not OK
> foo
> bar
> baz
>

Yeah, that is my expectation. If you wanted to do foo without the namespace
qualifier you would explicitly say

use builtin v5.40 qw(foo bar baz);


> Perl 5.42 decides builtin::foo should be into CORE namespace.
>

I assume that when you say the CORE namespace you mean globally available
in all namespaces. If so then I personally would say that we would never do
that. The whole point of the builtin namespace is so that we *stop* having
functions that are injected into your namespace and which might break
backwards compatibility. With the builtin namespace (reminder "builtin" is
at this point purely a placeholder for whatever name is eventually chosen),
all new functional additions to the language are insulated from breaking
code, AND we provide a clean mechanism for people using older perls to
obtain the equivalent functions in their older perls so they can run more
modern code. Eg, we want to as much as possibly disconnect the perl version
from the subs that are available, and whether having them available could
break any code, either backward or forward compatible.

So I cant imagine any reason why would move something from builtin to CORE.
In fact I would say that one we have builtin I cannot see any reason we
would add /anything/ to CORE at all, maybe there are arcane reasons why
some special function might *have to*, but any true function should never
be added to the language via CORE, there is simply no need to do so at all.

NOTE, everything I say here is my interpretation of the consensus we had in
the call about the namespaces, obviously I dont speak for the entire
community and others might see it differently, but I believe I am not going
to far out on a limb with this. I mean, turn it around, if we have a
function in builtin why would we move it into CORE? What would we gain
besides headaches?

cheers,
Yves




--
perl -Mre=debug -e "/just|another|perl|hacker/"
Re: PSC #034 2021-08-20 - "Namespaces Special" [ In reply to ]
On Thu, Sep 2, 2021 at 4:37 AM demerphq <demerphq@gmail.com> wrote:

>
>> Perl 5.42 decides builtin::foo should be into CORE namespace.
>>
>
> I assume that when you say the CORE namespace you mean globally available
> in all namespaces. If so then I personally would say that we would never do
> that. The whole point of the builtin namespace is so that we *stop* having
> functions that are injected into your namespace and which might break
> backwards compatibility. With the builtin namespace (reminder "builtin" is
> at this point purely a placeholder for whatever name is eventually chosen),
> all new functional additions to the language are insulated from breaking
> code, AND we provide a clean mechanism for people using older perls to
> obtain the equivalent functions in their older perls so they can run more
> modern code. Eg, we want to as much as possibly disconnect the perl version
> from the subs that are available, and whether having them available could
> break any code, either backward or forward compatible.
>
> So I cant imagine any reason why would move something from builtin to
> CORE. In fact I would say that one we have builtin I cannot see any reason
> we would add /anything/ to CORE at all, maybe there are arcane reasons why
> some special function might *have to*, but any true function should never
> be added to the language via CORE, there is simply no need to do so at all.
>
> NOTE, everything I say here is my interpretation of the consensus we had
> in the call about the namespaces, obviously I dont speak for the entire
> community and others might see it differently, but I believe I am not going
> to far out on a limb with this. I mean, turn it around, if we have a
> function in builtin why would we move it into CORE? What would we gain
> besides headaches?
>

This is a somewhat orthogonal concern; CORE::say and CORE::fc exist for
example, but are not globally available. Of course we would continue to
provide new functions only as opt-in for a particular scope; the mechanism
of opt-in is all we are considering here.

-Dan
Re: PSC #034 2021-08-20 - "Namespaces Special" [ In reply to ]
On Fri, 27 Aug 2021 20:23:31 +0200, Martijn Lievaart <m@rtij.nl> wrote:

> Hi,
>
>
> Thanks for the excelent writeup!
>
>
> Op 27-08-2021 om 14:08 schreef Paul "LeoNerd" Evans:
>
> ...
> > * 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
>
>
> std::<function> is nice and short, even if a bit c++ish.
>
>
> >
> > * What is the name of the shim-loader pragma module used to
> > obtain the shortname lexical aliases? It could match the function
> > namespace, but it doesn't have to. Other candidates include
> > "function" or "functions". Though they bear a visual similarity to
> > the "feature" module, which we are trying to avoid. Maybe there are
> > some other words to be found.
>
>
> use std '<function>'; would serve I think.
>
>
> > * What functions to actually include in this new namespace? We
> > already have quite a few candidates for places to look for existing
> > ideas, which should be sufficient to try out the mechanism before
> > we think about adding actually-new ones:
> > + `Scalar::Util`
> > + Existing features like `fc`
> > + UNIVERSAL.c
> > + The badly-named `Internals::`
> > + Commonly-used POSIX functions like `ceil()`
> > + Rarely-used POSIXisms in core perl like `gethostbyname`
>
> I cannot remember the last time I used ceil, but I use gethostbyname
> a lot. But that may just me. I do not see a huge added value from
> removing gethostbyname and others from the global namespace other
> than orthogonality, but I  don't care to much either.

What he said.

I use POSIX::strptime more than ceil or floor
I would also suggest Time::Local functions: now you can make the names
default again instead of the silly long lames

> > * 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 [];
>
> What to include and what not? As there is no backwards compatibility
> issue, it is just a matter of taste and bikeshedding, but I think
> restraint should be excerised. Once the deamon is out of the box, it
> cannot be put back.
>
> M4

--
H.Merijn Brand https://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.33 porting perl5 on HP-UX, AIX, and Linux
https://tux.nl/email.html http://qa.perl.org https://www.test-smoke.org