Mailing List Archive

On Sat, 20 Nov 2021 16:58:53 +0000
"Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:

> * An 'import' sub

This bit is now done.

> If anyone wants to help writing those - especially the docs - your
> assistance would be most welcome ;)

More eyes looking at the docs in particular would be useful. While the
"builtin" module itself is documented, it isn't very discoverable
currently. Perhaps some other modules/docs could mention it in places
as well.

There's now a PR ready for review / comment / suggestions:

https://github.com/Perl/perl5/pull/19232


As well as finishing off the implementation for RFC 0008 (Stable
Booleans), this is also making the start at RFC 0009:

https://github.com/Perl/RFCs/blob/master/rfcs/rfc0009.md

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

2021-11-21 9:17 Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:

>
> There's now a PR ready for review / comment / suggestions:
>
> https://github.com/Perl/perl5/pull/19232
>
>
>
Thank you for the implementation!

I see all commits. It looks good to me.

Personally, in the next step, I want to see builtin.pm work correctly as a
dual life module,

because I want to check if that old Perl calls the functions of the
builtin.pm module.

Latest update:

Current pending PR adds a `use builtin :ver` tagging system

https://github.com/Perl/perl5/pull/19282

This isn't yet integrated into the main `use VERSION` but we could
perhaps consider that sometime.

About the only big thing left to consider, is where to keep track of
ideas for more functions to add. I'm sure there's a huge supply of
potential ideas:

* getcwd (from `Internals`)

* unicode_to_native and native_to_unicode (from the odd `utf8`)

* Other bits and pieces from Scalar::Util ?

* refcount

* trim / trimmed

* Aliases of *all* the current core ops that behave like simple
functions (e.g. bless, lc/uc/fc). This covers probably about 70% of
all the CORE:: keywords to be honest.

I don't really want to make an exhaustive list in email because that'll
constantly get out of date as people add more ideas and we remove
implemented ones.

Does anyone have a good suggestion on where to keep that as an online
dynamic TODO list?

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Mon, 22 Nov 2021 08:38:31 +0900
Yuki Kimoto <kimoto.yuki@gmail.com> wrote:

> Personally, in the next step, I want to see builtin.pm work correctly
> as a dual life module,
>
> because I want to check if that old Perl calls the functions of the
> builtin.pm module.

Yes, once there's a development release including this (which I expect
will be 5.35.8 due in just a few days now), I'll take a look at what
can be done to dual-life this as a concept.

It will require making a brand new distribution with a new .xs file.
There may be possibility to reüse the current .pm file or that may need
creating as well.

Once I have an initial version I'll take a look and see how much
copy-pasting I had to do to make it work, and whether some of that can
be automated into some sort of autogeneration system to avoid needing
to keep the two separate files in sync manually.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Wed, Dec 15, 2021 at 11:03 AM Paul "LeoNerd" Evans <
leonerd@leonerd.org.uk> wrote:

> I don't really want to make an exhaustive list in email because that'll
> constantly get out of date as people add more ideas and we remove
> implemented ones.
>
> Does anyone have a good suggestion on where to keep that as an online
> dynamic TODO list?
>

Github wiki?

-Dan

On Wed, Dec 15, 2021 at 03:53:07PM +0000, Paul "LeoNerd" Evans wrote:
> Latest update:
>
> Current pending PR adds a `use builtin :ver` tagging system
>
> https://github.com/Perl/perl5/pull/19282
>
> This isn't yet integrated into the main `use VERSION` but we could
> perhaps consider that sometime.
>
> About the only big thing left to consider, is where to keep track of
> ideas for more functions to add. I'm sure there's a huge supply of
> potential ideas:
>
> * getcwd (from `Internals`)

Internals::getcwd no longer exists in perl.

(See commit e4140d10fb3651bc from September.)

It's only needed on miniperl for bootstrapping *nix systems. It's the
fallback to use if there isn't platform specific code.

Ignoring os2 and dos, we have:

VMS => _vms_cwd
MSWin32 => _NT_cwd
qnx => _qnx_cwd
cygwin => cwd
amigaos => _backtick_pwd


Internals::getcwd is an unconditional 10 line wrapper around getcwd_sv()

A correct builtin getcwd would need to duplicate all the platform specific
logic from Cwd.pm into C.

This seems like a lot of work to basically stand still.

Nicholas Clark

On Wed, Dec 15, 2021 at 03:53:07PM +0000, Paul "LeoNerd" Evans wrote:

> I don't really want to make an exhaustive list in email because that'll
> constantly get out of date as people add more ideas and we remove
> implemented ones.


Is there any plan to make *anything* in builtin:: declare that it's
experimental?

Historically we've gone through a lot of pain adding things to core that
turned out to be not correct, or "could be improved", but we didn't want to
change it because by then it had been in a release and it was assumed to be
stable.

Hence the whole idea of experimental features, and having a couple of
releases to see if experiments worked. And all things added by features
were initially experimental, and warned as such, and might change.

Yet it seems that we're bypassing all of that approach, and simply adding
functions to builtin:: which are treated as stable and supported, without
any real cycle of validating that

1) the API is correct
2) the benefit from being in builtin:: outweighs the cost of violating
"don't repeat yourself" (because they are already have a different
well known name)


We seem to risk repeating mistakes from 10 years ago.

Nicholas Clark

On Wed, 15 Dec 2021 19:55:08 +0000
Nicholas Clark <nick@ccl4.org> wrote:

> On Wed, Dec 15, 2021 at 03:53:07PM +0000, Paul "LeoNerd" Evans wrote:
>
> Is there any plan to make *anything* in builtin:: declare that it's
> experimental?
...

Ohright, yes that's an excellent point. The whole lot probably ought to
be warning that, indeed.

It could probably warn at `import` time, except that won't catch the
cases where people invoke it directly by its fully-qualified name.
Offhand I can't think of a good way to warn on those bits.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Wed, 15 Dec 2021 19:46:14 +0000
Nicholas Clark <nick@ccl4.org> wrote:

> Internals::getcwd no longer exists in perl.
...

Ah in that case probably easiest not to bother for now :)

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

2021-12-16 2:52 Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:

> On Mon, 22 Nov 2021 08:38:31 +0900
> Yuki Kimoto <kimoto.yuki@gmail.com> wrote:
>
> > Personally, in the next step, I want to see builtin.pm work correctly
> > as a dual life module,
> >
> > because I want to check if that old Perl calls the functions of the
> > builtin.pm module.
>
> Yes, once there's a development release including this (which I expect
> will be 5.35.8 due in just a few days now), I'll take a look at what
> can be done to dual-life this as a concept.
>
> It will require making a brand new distribution with a new .xs file.
> There may be possibility to reüse the current .pm file or that may need
> creating as well.
>
> Once I have an initial version I'll take a look and see how much
> copy-pasting I had to do to make it work, and whether some of that can
> be automated into some sort of autogeneration system to avoid needing
> to keep the two separate files in sync manually.
>
>
>
Thank you.

If dual-life builtin.pm is created at 5.35.8, I will test it in my local
environment.

Personally, I want to use trim or slurp on my CPAN module if the functions
are implemented in builtin.pm.

On Thu, 16 Dec 2021 07:55:10 +0900
Yuki Kimoto <kimoto.yuki@gmail.com> wrote:

> Personally, I want to use trim or slurp on my CPAN module if the
> functions are implemented in builtin.pm.

So why not use existing CPAN solutions for those? `trim` has about 15
different possibles, and `slurp` usually comes from File::Slurp::Tiny.

Also I don't believe there are currently suggestions to add a `slurp`
here.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

2021-12-16 8:00 Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:

> On Thu, 16 Dec 2021 07:55:10 +0900
> Yuki Kimoto <kimoto.yuki@gmail.com> wrote:
>
> > Personally, I want to use trim or slurp on my CPAN module if the
> > functions are implemented in builtin.pm.
>
> So why not use existing CPAN solutions for those? `trim` has about 15
> different possibles, and `slurp` usually comes from File::Slurp::Tiny.
>
> Also I don't believe there are currently suggestions to add a `slurp`
> here.
>
>
Sorry, this is an assumption.

slurp is a practical user function example.

I said I want to use builtin.pm in my CPAN module if these functions *were*
added.

On Wed, 15 Dec 2021 21:14:44 +0000
"Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:

> It could probably warn at `import` time, except that won't catch the
> cases where people invoke it directly by its fully-qualified name.
> Offhand I can't think of a good way to warn on those bits.

Actually I think a better bet would be to put the warning in the
callchecker, so it happens for every callsite of both
lexically-imported and fully-qualified callers.

Wouldn't do much about

my $code = \&builtin::weaken;
$code->( $var );

but I suspect if you're doing *that* you hopefully know what you're
doing anyway.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Wed, 15 Dec 2021 21:14:44 +0000
"Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:

> Ohright, yes that's an excellent point. The whole lot probably ought
> to be warning that, indeed.

The more I think about it, the more I'm suddenly not sure if actually
every builtin function ought to be warning that it is experimental.

The entire list currently looks like this:

true, false # names for !!1 and !!0 constants

isbool # a wrapper for SvIsBOOL

weaken, unweaken, isweak # copied from Scalar::Util
blessed, refaddr, reftype

Of these 9 functions, 2 are names for constants that have been in
perl for basically all of time, and 6 are copies of same-named same
behaviour from Scalar::Util where they've been for a good decade or
more. Only `isbool` is actually new here.

I wonder quite what the overall "experimental" status of these things
ought to be. In practice the design of the latter 6 of these is
entirely fixed, being a clone of the "set in stone" design from
Scalar::Util. Perhaps the idea of "builtin" in the first place is
experimental, but at least those final 6 functions can't really be very
flexible within it. They're constrained by the past ~20 years of
Scalar::Util usage. The same however can't be said for actual new
designs - maybe some mythical trim() that turns up at some point in the
future, or new things related to type systems, object systems, whatever
else we might add down the line.

Overall then I'm not sure whether it makes sense to just add a single
"experimental::builtin" category that can be turned on or off in bulk,
because that doesn't necessarily capture the varying degrees to which
each individual function might be considered experimental.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/