Mailing List Archive

review of perlexperiment, 2021-10
Porters,

We had fifteen experiments when 5.35.0 began, and we have closed out one of them, the win32 pesudo-layer. I would like to close out more and move other forward. Here is a review of a number of them.

*isa* — I believe isa is complete. It works, it can be used, no design changes seem to be in the wings. What prevents us from calling this stable (and including it in the v5.36.0 feature bundle)? #18754 <https://github.com/Perl/perl5/issues/18754>

*:const* — This is a somewhat esoteric feature, but I have used it and it does what it says on the tin. I believe it is largely unused, but the behavior is what I expected, and it is occasionally useful. Unless it is going to produce an undue maintenance burden, *I believe we should land this experiment.* What prevents us from doing so? #14428 <https://github.com/Perl/perl5/issues/14428>

*variable-length lookbehind* — This appears to work and the user-facing design does not seem to need changing, even if bugs are later found. *I believe we should land this experiment.* What prevents us from doing so? #18756 <https://github.com/Perl/perl5/issues/18756>

*private character hooks *— It's not clear to me that this is actually intended for use outside of core, in which case I don't know that it needs to be considered much. My question is: By what criteria would we ever decide to change the status of this code? #18758 <https://github.com/Perl/perl5/issues/18758>

*Unicode property wildcards* — I believe this is not receiving enough use to really warrant a clear result from use testing, so the question is the nearly same as above: By what criteria would we ever decide to change the status of this design? While we might change the guts later, is the design right? (Design is the key question about experiments, with implementation mattering most when it affects the practicality fo the design.) #18759 <https://github.com/Perl/perl5/issues/18759>

*regex strictures* — I believe this should be moved to strict.pm, with the shift to "use strict" meaning "use strict VER". Beyond that, though, we may want to discuss whether this needs splitting into more strictures, especially since it also provides warnings. I feel this may be stalled due to lack of engagement from users or porters. #18755 <https://github.com/Perl/perl5/issues/18755>

*refaliases — *I'm very keen to see this one land. The biggest problem is the bug "lexical subs don't close over refaliases <https://github.com/Perl/perl5/issues/18980>", which to my mind makes them incomplete. #14150 <https://github.com/Perl/perl5/issues/14150>

*declared refs* — Declared refs is mostly sugar to make refaliases more attractive. Without merging refaliases, my take is roughly "what's the point"? #15458 <https://github.com/Perl/perl5/issues/15458>

*signatures *— This needs its own post. #13681 <https://github.com/Perl/perl5/issues/13681>

*smartmatch* — We have resisted removing this failure for years, as we want to replace it with something else. My take: we should just rip this out and later, *maybe*, put something else in. #13173 <https://github.com/Perl/perl5/issues/13173>

*installhtml* — I don't think this makes sense as an experiment. We should drop the experimental classification. #12726 <https://github.com/Perl/perl5/issues/12726>

*pluggable keyword API* — Calling this experimental is also weird. We have had a number of PSC (and other) conversations about changing how pluggable keywords work so that their implementation could be less exposed, and certain hooks could be made experimental so they'd warn when being hooked into. *I would love to see an email about this from Nicholas or Paul.* #13199 <https://github.com/Perl/perl5/issues/13199>

--
rjbs
Re: review of perlexperiment, 2021-10 [ In reply to ]
On Sun, 03 Oct 2021 16:41:37 -0400
"Ricardo Signes" <perl.p5p@rjbs.manxome.org> wrote:
> *isa* — I believe isa is complete. It works, it can be used, no
> design changes seem to be in the wings. What prevents us from
> calling this stable (and including it in the v5.36.0 feature bundle)?
> #18754 <https://github.com/Perl/perl5/issues/18754>

Largely just waiting on it to timeout really.

There's still *an* ongoing problem in that it works kinda weirdly with
the underlying reftype of an object.

By which I mean, I had *wanted* the operator to work such that

$obj isa Some::Class => implies "Some::Class" is somewhere in the
@ISA tree for $obj

But this isn't actually true for the special stringy names of the
reftype; e.g. any blessed hash reference happens to be true for

$obj isa HASH

and yet the @ISA tree does not contain qw(HASH), nor does

$obj->meth(...)

attempt to invoke sub HASH::meth {}.

It's a bit of a thorn in the design. It's discussed more in

https://github.com/Perl/perl5/issues/18531

but we never really reached a conclusion.



> *smartmatch* — We have resisted removing this failure for years, as
> we want to replace it with something else. My take: we should just
> rip this out and later, *maybe*, put something else in. #13173
> <https://github.com/Perl/perl5/issues/13173>

I'm hoping eventually to make match/case into core syntax:

https://metacpan.org/pod/Syntax::Keyword::Match

which would be able to replace almost all of the current uses of
given/when, without needing to bother thinking about smartmatch.

Alternatively, somewhat ironically, the strong splitting of PV vs IV/NV
as achieved by Nicholas et.al. recently, may actually be an 11th hour
saviour for smartmatch, in that it will suddenly make at least the
string-vs-number tests it performs somewhat more reliable. It still
won't save the overall "THIS IS CRAZY" feel of whether it even makes
sense to ask such questions as

%ENV ~~ &is_even

though. :)



> *pluggable keyword API* — Calling this experimental is also weird.
> We have had a number of PSC (and other) conversations about changing
> how pluggable keywords work so that their implementation could be
> less exposed, and certain hooks could be made experimental so they'd
> warn when being hooked into. *I would love to see an email about
> this from Nicholas or Paul.* #13199
> <https://github.com/Perl/perl5/issues/13199>

In summary: I'd love to basically say that PL_keyword_plugin and all
the associated machinery, including *all* of the lexer and parser API,
are no longer for public use, and they are simply the internal
mechanism used to make XS::Parse::Keyword work, and that
XS::Parse::Keyword will now be the "public" API used by XS authors to
provide extension keywords.

Already I've rewritten all of mine on CPAN to use it, and honestly I'm
not really aware of any other "production-grade" syntax modules on CPAN
not written by me. There's a few bits and pieces out there, but to my
knowledge nothing large or with much following.

I further explain the case in my talk "Perl's Amazing Time Machine"
from CitC earlier this year:

https://www.youtube.com/watch?v=Kc_bP73xNyM

(The brief summary begins at 45:20 until 47:10, if you don't fancy
watching the whole ~50minute talk)

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: review of perlexperiment, 2021-10 [ In reply to ]
On Sun, 03 Oct 2021 16:41:37 -0400
"Ricardo Signes" <perl.p5p@rjbs.manxome.org> wrote:

> *smartmatch* ? We have resisted removing this failure for years, as we want to replace it with something else. My take: we should just rip this out and later, *maybe*, put something else in. #13173 <https://github.com/Perl/perl5/issues/13173>

Back in 2017 we tried replacing smartmatch with "dumbmatch" and in
result we made everyone angry and broke half of CPAN:

http://blogs.perl.org/users/leon_timmermans/2017/12/smartmatch-in-5277.html
https://www.nntp.perl.org/group/perl.perl5.porters/2017/08/msg245769.html
https://github.com/Perl/perl5/issues/16310
https://www.nntp.perl.org/group/perl.perl5.porters/2017/12/msg248507.html

I don't want that to happen again.

Smartmatch is widely used because of two reasons. First of all, it
solves an important problem: it provides "switch" and "in" operators.
Of course, it does that in a completely insane way, but currently there
are no (core) alternatives to it.

The other reason is that we have completely failed to communicate that
we don't want our users to use smartmatch. Until 5.18 it didn't warn at
all, now it gives an "experimental" warning which is meaningless. Do
signatures and smartmatch have the same status? Absolutely not. Yet
that's what our documentation and warnings say.

If we want to remove smartmatch, we need to properly deprecate it and
provide a replacement for it. BTW, I believe LeoNerd is working on the
latter.

Speaking of deprecating things, the dumbmatch fiasco has showed that our
two stable releases deprecation cycle is way too short. When the users
of LTS distributions upgrade, they skip multiple Perl releases, so from
their POV features disappear without any warnings! This worked OK for
unimportant stuff that no one cared about, but I think something like
smartmatch will need a longer deprecation period.
Re: review of perlexperiment, 2021-10 [ In reply to ]
On Sun, Oct 3, 2021 at 5:50 PM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> > *pluggable keyword API* — Calling this experimental is also weird.
> > We have had a number of PSC (and other) conversations about changing
> > how pluggable keywords work so that their implementation could be
> > less exposed, and certain hooks could be made experimental so they'd
> > warn when being hooked into. *I would love to see an email about
> > this from Nicholas or Paul.* #13199
> > <https://github.com/Perl/perl5/issues/13199>
>
> In summary: I'd love to basically say that PL_keyword_plugin and all
> the associated machinery, including *all* of the lexer and parser API,
> are no longer for public use, and they are simply the internal
> mechanism used to make XS::Parse::Keyword work, and that
> XS::Parse::Keyword will now be the "public" API used by XS authors to
> provide extension keywords.
>
> Already I've rewritten all of mine on CPAN to use it, and honestly I'm
> not really aware of any other "production-grade" syntax modules on CPAN
> not written by me. There's a few bits and pieces out there, but to my
> knowledge nothing large or with much following.
>

Off the top of my head, some decently used ones are: Function::Parameters,
Switch::Plain (which is rather trivial), Kavorka (which uses the deprecated
Parse::Keyword), Moops (which uses various problematic keyword modules),
and less-used: Zydeco, Quote::Code, Dios

-Dan
Re: review of perlexperiment, 2021-10 [ In reply to ]
2021-10-4 5:42 Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:

>
> *installhtml* — I don't think this makes sense as an experiment. We
> should drop the experimental classification. #12726
> <https://github.com/Perl/perl5/issues/12726>
>
>
One by one, starting with the ones that seem to have little impact.

Is there anyone who opposes this?
Re: review of perlexperiment, 2021-10 [ In reply to ]
On Mon, Oct 04, 2021 at 05:53:45PM +0900, Yuki Kimoto wrote:
> 2021-10-4 5:42 Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
>
> >
> > *installhtml* — I don't think this makes sense as an experiment. We
> > should drop the experimental classification. #12726
> > <https://github.com/Perl/perl5/issues/12726>
> >
> >
> One by one, starting with the ones that seem to have little impact.
>
> Is there anyone who opposes this?

I would oppose it, in its current state. The intended usage pattern and documentation
should be sorted out first. Specifically, the current Makefile.SH says this

# XXX Experimental. Hardwired values, but useful for testing.
# Eventually Configure could ask for some of these values.

Relevant excerpts from The INSTALL file:

=item HTML pages

Currently, the standard perl installation does not do anything with
HTML documentation, but that may change in the future. Further, some
add-on modules may wish to install HTML documents. The html Configure
variables listed above are provided if you wish to specify where such
documents should be placed. The default is "none", but will likely
eventually change to something useful based on user feedback.

=head1 installhtml --help

Currently, the supplied ./installhtml script does not make use of the
html Configure variables. This should be fixed in a future release.

Configure actually does ask for some html installation variables, but nothing uses
them. Presumably, there was a mismatch between what Configure asks for and what
installhtml actually needed, but that mismatch was never resolved. Recording the correct
installation location in Config.pm is useful because that would allow CPAN modules to
reliably look up where to install HTML files.

I think this all should be sorted out before declaring it non-experimental.

--
Andy Dougherty doughera@lafayette.edu
Re: review of perlexperiment, 2021-10: install.html target [ In reply to ]
On 10/4/21 3:08 PM, Andy Dougherty wrote:
> On Mon, Oct 04, 2021 at 05:53:45PM +0900, Yuki Kimoto wrote:
>> 2021-10-4 5:42 Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
>>
>>>
>>> *installhtml* — I don't think this makes sense as an experiment. We
>>> should drop the experimental classification. #12726
>>> <https://github.com/Perl/perl5/issues/12726>
>>>
>>>
>> One by one, starting with the ones that seem to have little impact.
>>
>> Is there anyone who opposes this?
>
> I would oppose it, in its current state. The intended usage pattern
and documentation
> should be sorted out first. Specifically, the current Makefile.SH
says this
>
> # XXX Experimental. Hardwired values, but useful for testing.
> # Eventually Configure could ask for some of these values.
>

[snip]

>
> Configure actually does ask for some html installation variables, but
nothing uses
> them. Presumably, there was a mismatch between what Configure asks
for and what
> installhtml actually needed, but that mismatch was never resolved.
Recording the correct
> installation location in Config.pm is useful because that would allow
CPAN modules to
> reliably look up where to install HTML files.
>
> I think this all should be sorted out before declaring it
non-experimental.
>

I agree with Andy Dougherty, except that I would go further and drop
this make target entirely.

Earlier this year I worked on a refactoring of 'ext/Pod-Html', in the
course of which I had occasion to peer into 'installhtml'. I don't
claim to be an expert on that program since, among other things, I have
never actually had to use it in 21 years. But I did have occasion to
make one change in it ("set default podpath to './lib'";
f5e0f10e7065bfa21679406e5c9a604536f75585) in order to resolve an old bug
ticket, https://github.com/Perl/perl5/issues/11859.

Looking at the code for the 'install.html' target in 'Makefile.SH', I
now see that that code retains "-podpath=." -- which means it probably
does the wrong thing. At the very least, it's now out of synch with the
default values for the 'installhtml' program itself.

Given this problem with the target, and given that we have next to no
data from end-users as to how either the target or the program is
actually used, I believe that not only should we *not*
de-experimentalize the 'install.html' target, we should deprecate it and
then drop it altogether.

Thank you very much.
Jim Keenan
Re: review of perlexperiment, 2021-10: install.html target [ In reply to ]
2021-10-5 5:18 James E Keenan <jkeenan@pobox.com> wrote:

> On 10/4/21 3:08 PM, Andy Dougherty wrote:
> > On Mon, Oct 04, 2021 at 05:53:45PM +0900, Yuki Kimoto wrote:
> >> 2021-10-4 5:42 Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
> >>
> >>>
> >>> *installhtml* — I don't think this makes sense as an experiment. We
> >>> should drop the experimental classification. #12726
> >>> <https://github.com/Perl/perl5/issues/12726>
> >>>
> >>>
> >> One by one, starting with the ones that seem to have little impact.
> >>
> >> Is there anyone who opposes this?
> >
> > I would oppose it, in its current state. The intended usage pattern
> and documentation
> > should be sorted out first. Specifically, the current Makefile.SH
> says this
> >
> > # XXX Experimental. Hardwired values, but useful for testing.
> > # Eventually Configure could ask for some of these values.
> >
>
> [snip]
>
> >
> > Configure actually does ask for some html installation variables, but
> nothing uses
> > them. Presumably, there was a mismatch between what Configure asks
> for and what
> > installhtml actually needed, but that mismatch was never resolved.
> Recording the correct
> > installation location in Config.pm is useful because that would allow
> CPAN modules to
> > reliably look up where to install HTML files.
> >
> > I think this all should be sorted out before declaring it
> non-experimental.
> >
>
> I agree with Andy Dougherty, except that I would go further and drop
> this make target entirely.
>
> Earlier this year I worked on a refactoring of 'ext/Pod-Html', in the
> course of which I had occasion to peer into 'installhtml'. I don't
> claim to be an expert on that program since, among other things, I have
> never actually had to use it in 21 years. But I did have occasion to
> make one change in it ("set default podpath to './lib'";
> f5e0f10e7065bfa21679406e5c9a604536f75585) in order to resolve an old bug
> ticket, https://github.com/Perl/perl5/issues/11859.
>
> Looking at the code for the 'install.html' target in 'Makefile.SH', I
> now see that that code retains "-podpath=." -- which means it probably
> does the wrong thing. At the very least, it's now out of synch with the
> default values for the 'installhtml' program itself.
>
> Given this problem with the target, and given that we have next to no
> data from end-users as to how either the target or the program is
> actually used, I believe that not only should we *not*
> de-experimentalize the 'install.html' target, we should deprecate it and
> then drop it altogether.
>
> Thank you very much.
> Jim Keenan
>

There seemed to be some different opinions

Ric

-Delete experimental

Andy

-organize

James E Keenan

-Deprecate and drop

.Is it possible to adjust?
Re: review of perlexperiment, 2021-10 [ In reply to ]
On Sun, Oct 03, 2021 at 04:41:37PM -0400, Ricardo Signes wrote:

> *pluggable keyword API* — Calling this experimental is also weird. We have had a number of PSC (and other) conversations about changing how pluggable keywords work so that their implementation could be less exposed, and certain hooks could be made experimental so they'd warn when being hooked into. *I would love to see an email about this from Nicholas or Paul.* #13199 <https://github.com/Perl/perl5/issues/13199>

I really don't have an opinion about removing hooks (in general), or this one
in particular. (I note that Paul has mailed specifics about this one.)

The thoughts I had were more that we shouldn't add new hooks as we had been
- a pointer in a data structure that your code manipulates to "register"
its callback, and de-facto scribbles over the previous value/does something
with it/who knows.

Instead we should have an API - one API call that your uses to register its
callback, and a second to de-register the callback.

(And I think two API calls total, not two per callback type.
Have "what are you hooking into" be an enumeration)

This way we can have the "register" API generate warnings at load time if
the feature is deprecated, which are visible to the *user* of the module,
in Perl space.

Instead of what we have now which is we try to make the C compiler generate
deprecation warnings, which are visible to the OS package builder automated
toolchain, which couldn't give two hoots about it, and they fall on the
floor.

But I don't think that this fits into this thread.

Nicholas Clark
Re: review of perlexperiment, 2021-10 [ In reply to ]
On Tue, 5 Oct 2021 11:50:15 +0000
Nicholas Clark <nick@ccl4.org> wrote:

> Instead we should have an API - one API call that your uses to
> register its callback, and a second to de-register the callback.

A good idea.

And incidentally exactly how XS::Parse::Keyword/Infix/Sublike already
work:

https://metacpan.org/pod/XS::Parse::Keyword#register_xs_parse_keyword

https://metacpan.org/pod/XS::Parse::Infix#register_xs_parse_infix

https://metacpan.org/pod/XS::Parse::Sublike#register_xs_parse_sublike

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: review of perlexperiment, 2021-10 [ In reply to ]
On Mon, Oct 4, 2021 at 9:08 PM Andy Dougherty <doughera@lafayette.edu>
wrote:

> On Mon, Oct 04, 2021 at 05:53:45PM +0900, Yuki Kimoto wrote:
> > 2021-10-4 5:42 Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
> >
> > >
> > > *installhtml* — I don't think this makes sense as an experiment. We
> > > should drop the experimental classification. #12726
> > > <https://github.com/Perl/perl5/issues/12726>
> > >
> > >
> > One by one, starting with the ones that seem to have little impact.
> >
> > Is there anyone who opposes this?
>
> I would oppose it, in its current state. The intended usage pattern and
> documentation
> should be sorted out first. Specifically, the current Makefile.SH says
> this
>
> # XXX Experimental. Hardwired values, but useful for testing.
> # Eventually Configure could ask for some of these values.
>
> Relevant excerpts from The INSTALL file:
>
> =item HTML pages
>
> Currently, the standard perl installation does not do anything with
> HTML documentation, but that may change in the future. Further, some
> add-on modules may wish to install HTML documents. The html Configure
> variables listed above are provided if you wish to specify where such
> documents should be placed. The default is "none", but will likely
> eventually change to something useful based on user feedback.
>
> =head1 installhtml --help
>
> Currently, the supplied ./installhtml script does not make use of the
> html Configure variables. This should be fixed in a future release.
>
> Configure actually does ask for some html installation variables, but
> nothing uses
> them. Presumably, there was a mismatch between what Configure asks for
> and what
> installhtml actually needed, but that mismatch was never resolved.
> Recording the correct
> installation location in Config.pm is useful because that would allow CPAN
> modules to
> reliably look up where to install HTML files.
>
> I think this all should be sorted out before declaring it non-experimental.
>

Likewise, to me it only really makes sense to install pod files as html in
core if the toolchain can also do that. MakeMaker never finished adding
support for it, and Module::Build's support is known to be buggy (and no
one has volunteered to fix those issues in the past more than a decade).

Leon
Re: review of perlexperiment, 2021-10 [ In reply to ]
On 10/3/21 2:41 PM, Ricardo Signes wrote:
>

> *private character hooks *— It's not clear to me that this is actually
> intended for use outside of core, in which case I don't know that it
> needs to be considered much. My question is:  By what criteria would we
> ever decide to change the status of this code? #18758
> <https://github.com/Perl/perl5/issues/18758>

I added this hook for a module I still intend to write. I originally I
thought I would get done before the next release came out, and that
people could start using it immediately from cpan instead of waiting for
that release. But that didn't happen. I made it experimental so as to
preclude someone else writing a module before the interface was really
nailed down.
>
> *Unicode property wildcards* — I believe this is not receiving enough
> use to really warrant a clear result from use testing, so the question
> is the nearly same as above:  By what criteria would we ever decide to
> change the status of this design?  While we might change the guts later,
> is the design right?  (Design is the key question about experiments,
> with implementation mattering most when it affects the practicality fo
> the design.) #18759 <https://github.com/Perl/perl5/issues/18759>

My understanding has always been that Perl intends to support the
Unicode regex requirements. I wrote this only because it is in Unicode

https://www.unicode.org/reports/tr18/proposed.html

I marked it as experimental because I think every new thing should go
out as experimental, so that if it turns out to be an albatross, we can
jettison it easily, or modify it for the better. Also, as a result of
our experiences, Unicode has retracted whole sections of their regex
Standard. Apparently, Perl is in the forefront of implementing this UTS
(Unicode Technical Standard. Unicode views UTS's as less set in stone
than the regular Standard. It's a good thing to mark some of these
things as experimental, so that should Unicode revise things, we aren't
left holding the bag. I wish I had done this with their Age property,
whose definition seemed unlikely to be useful, but I didn't have the
confidence back then to question their wisdom, and not knowing what I
have since discovered, that they hadn't actually tried to use some of
the things they specified. Well, they eventually discovered that the
Age property was useless in patterns as defined, and changed what should
happen. But we were left holding the bag. (I had implemented the
Present In property as a Perl extension to DTRT with Age; what Unicode
changed Age to is essentially that, so Perl already had a work-around.)

The link above is to the proposed revisions to TR 18, to show it is
evolving. I am currently working to support some of the more recent
things in it.

>
> *regex strictures* — I believe this should be moved to strict.pm, with
> the shift to "use strict" meaning "use strict VER".  Beyond that,
> though, we may want to discuss whether this needs splitting into more
> strictures, especially since it also provides warnings.  I feel this may
> be stalled due to lack of engagement from users or porters. #18755
> <https://github.com/Perl/perl5/issues/18755>
>

I wrote this because the regex syntax was designed for concision without
regard to error proneness. It catches questionable things, like lint or
Perl Critic, but usually things you really shouldn't have done. I made
it experimental so that I could add things to it without being
constrained by what was then in the field. Over several releases, I did
add new things, but haven't found new issues for the past several releases.
Re: review of perlexperiment, 2021-10 [ In reply to ]
On Sun, 03 Oct 2021 23:51:43 +0200, Tomasz Konojacki <me@xenu.pl> wrote:

> On Sun, 03 Oct 2021 16:41:37 -0400
> "Ricardo Signes" <perl.p5p@rjbs.manxome.org> wrote:
>
> > *smartmatch* — We have resisted removing this failure for years, as
> > we want to replace it with something else. My take: we should
> > just rip this out and later, *maybe*, put something else in. #13173
> > <https://github.com/Perl/perl5/issues/13173>
>
> Back in 2017 we tried replacing smartmatch with "dumbmatch" and in
> result we made everyone angry and broke half of CPAN:
>
> http://blogs.perl.org/users/leon_timmermans/2017/12/smartmatch-in-5277.html
> https://www.nntp.perl.org/group/perl.perl5.porters/2017/08/msg245769.html
> https://github.com/Perl/perl5/issues/16310
> https://www.nntp.perl.org/group/perl.perl5.porters/2017/12/msg248507.html
>
> I don't want that to happen again.
>
> Smartmatch is widely used because of two reasons. First of all, it
> solves an important problem: it provides "switch" and "in" operators.
> Of course, it does that in a completely insane way, but currently
> there are no (core) alternatives to it.

I agree on this statement. And my mind is ambiguous.
As a developer and maintainer of perl I want it gone
As an (end)user I want it to stay, even in its current state: there is
no (easy) alternative, and I have a few (huge) scripts that depend on
it. All of them were converted from insane if/elsif/else trees into
readable switch structures. I really don't feel thrilled to rewrite
them again. (all I use is undef/numeric/string/regex, no overloading,
hashes or arrays).

> The other reason is that we have completely failed to communicate that
> we don't want our users to use smartmatch. Until 5.18 it didn't warn
> at all, now it gives an "experimental" warning which is meaningless.
> Do signatures and smartmatch have the same status? Absolutely not. Yet
> that's what our documentation and warnings say.
>
> If we want to remove smartmatch, we need to properly deprecate it and
> provide a replacement for it. BTW, I believe LeoNerd is working on the
> latter.
>
> Speaking of deprecating things, the dumbmatch fiasco has showed that
> our two stable releases deprecation cycle is way too short. When the
> users of LTS distributions upgrade, they skip multiple Perl releases,
> so from their POV features disappear without any warnings! This
> worked OK for unimportant stuff that no one cared about, but I think
> something like smartmatch will need a longer deprecation period.
>


--
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
Re: review of perlexperiment, 2021-10 [ In reply to ]
On Wed, Oct 6, 2021 at 11:13 AM H.Merijn Brand <perl5@tux.freedom.nl> wrote:

> On Sun, 03 Oct 2021 23:51:43 +0200, Tomasz Konojacki <me@xenu.pl> wrote:
>
> > On Sun, 03 Oct 2021 16:41:37 -0400
> > "Ricardo Signes" <perl.p5p@rjbs.manxome.org> wrote:
> >
> > > *smartmatch* — We have resisted removing this failure for years, as
> > > we want to replace it with something else. My take: we should
> > > just rip this out and later, *maybe*, put something else in. #13173
> > > <https://github.com/Perl/perl5/issues/13173>
> >
> > Back in 2017 we tried replacing smartmatch with "dumbmatch" and in
> > result we made everyone angry and broke half of CPAN:
> >
> >
> http://blogs.perl.org/users/leon_timmermans/2017/12/smartmatch-in-5277.html
> >
> https://www.nntp.perl.org/group/perl.perl5.porters/2017/08/msg245769.html
> > https://github.com/Perl/perl5/issues/16310
> >
> https://www.nntp.perl.org/group/perl.perl5.porters/2017/12/msg248507.html
> >
> > I don't want that to happen again.
> >
> > Smartmatch is widely used because of two reasons. First of all, it
> > solves an important problem: it provides "switch" and "in" operators.
> > Of course, it does that in a completely insane way, but currently
> > there are no (core) alternatives to it.
>
> I agree on this statement. And my mind is ambiguous.
> As a developer and maintainer of perl I want it gone
> As an (end)user I want it to stay, even in its current state: there is
> no (easy) alternative, and I have a few (huge) scripts that depend on
> it. All of them were converted from insane if/elsif/else trees into
> readable switch structures. I really don't feel thrilled to rewrite
> them again. (all I use is undef/numeric/string/regex, no overloading,
> hashes or arrays).
>

I have a similar position, though I personally have avoided using it
wherever possible. Note for this particular simple case,
https://metacpan.org/pod/Switch::Plain could be a
sufficient replacement, though it doesn't have special undef handling. And
https://metacpan.org/pod/Syntax::Keyword::Match will soon be getting
stabilized and cored. Both of these options only work on 5.14/5.16+ of
course.

The use as an "in" operator is more difficult to replace with current
available options, IMO.

-Dan
Re: review of perlexperiment, 2021-10 [ In reply to ]
On Sun, Oct 3, 2021 at 11:52 PM Tomasz Konojacki <me@xenu.pl> wrote:

> On Sun, 03 Oct 2021 16:41:37 -0400
> "Ricardo Signes" <perl.p5p@rjbs.manxome.org> wrote:
>
> > *smartmatch* — We have resisted removing this failure for years, as we
> want to replace it with something else. My take: we should just rip this
> out and later, *maybe*, put something else in. #13173 <
> https://github.com/Perl/perl5/issues/13173>
>
> Back in 2017 we tried replacing smartmatch with "dumbmatch" and in
> result we made everyone angry and broke half of CPAN:
>
> http://blogs.perl.org/users/leon_timmermans/2017/12/smartmatch-in-5277.html
> https://www.nntp.perl.org/group/perl.perl5.porters/2017/08/msg245769.html
> https://github.com/Perl/perl5/issues/16310
> https://www.nntp.perl.org/group/perl.perl5.porters/2017/12/msg248507.html
>
> I don't want that to happen again.
>
> Smartmatch is widely used because of two reasons. First of all, it
> solves an important problem: it provides "switch" and "in" operators.
> Of course, it does that in a completely insane way, but currently there
> are no (core) alternatives to it.
>
> The other reason is that we have completely failed to communicate that
> we don't want our users to use smartmatch. Until 5.18 it didn't warn at
> all, now it gives an "experimental" warning which is meaningless. Do
> signatures and smartmatch have the same status? Absolutely not. Yet
> that's what our documentation and warnings say.
>

I agree. I don't really think we can drop it now but that doesn't mean this
isn't actionable. I think it would be very useful to have a CPAN module
that's more-or-less a drop-in replacement. For given/when that's already
quite possible, for the smartmatch operator itself that would require
custom infix operators to land first.


> If we want to remove smartmatch, we need to properly deprecate it and
> provide a replacement for it. BTW, I believe LeoNerd is working on the
> latter.
>

Yeah, that's the more-future oriented approach. I suspect it's best to do
both.


> Speaking of deprecating things, the dumbmatch fiasco has showed that our
> two stable releases deprecation cycle is way too short. When the users
> of LTS distributions upgrade, they skip multiple Perl releases, so from
> their POV features disappear without any warnings! This worked OK for
> unimportant stuff that no one cared about, but I think something like
> smartmatch will need a longer deprecation period.
>

Yeah, having a fixed time period seems suboptimal. IME different situations
ask for different periods of time.

Leon
Re: review of perlexperiment, 2021-10 [ In reply to ]
On Sun, Oct 3, 2021, at 5:51 PM, Tomasz Konojacki wrote:
> The other reason is that we have completely failed to communicate that
> we don't want our users to use smartmatch. Until 5.18 it didn't warn at
> all, now it gives an "experimental" warning which is meaningless. Do
> signatures and smartmatch have the same status? Absolutely not. Yet
> that's what our documentation and warnings say.

"Until 5.18" — in other words, "for the last eight years."

"meaningless" —
given is experimental
(S experimental::smartmatch) "given" depends on smartmatch, which is
experimental, so its behavior may change or even be removed in any
future release of perl. See the explanation under "Experimental
Details on given and when" in perlsyn.

Smartmatch is experimental
(S experimental::smartmatch) This warning is emitted if you use the
smartmatch ("~~") operator. This is currently an experimental
feature, and its details are subject to change in future releases of
Perl. Particularly, its current behavior is noticed for being
unnecessarily complex and unintuitive, and is very likely to be
overhauled.

We need to be able to say that some things aren't guaranteed, and then *after eight years of saying that*, it needs to be able to mean something.

Saying, "The practical impacts of changing this feature are big and need real consideration" is one thing. I am really not enthused by "we've been saying it might be changed or removed for eight years, and this is meaningless and not enough."

--
rjbs
Re: review of perlexperiment, 2021-10 [ In reply to ]
On Wed, Oct 6, 2021, at 4:24 PM, Leon Timmermans wrote:
> On Sun, Oct 3, 2021 at 11:52 PM Tomasz Konojacki <me@xenu.pl> wrote:
>> Speaking of deprecating things, the dumbmatch fiasco has showed that our
>> two stable releases deprecation cycle is way too short. When the users
>> of LTS distributions upgrade, they skip multiple Perl releases, so from
>> their POV features disappear without any warnings! This worked OK for
>> unimportant stuff that no one cared about, but I think something like
>> smartmatch will need a longer deprecation period.
>
> Yeah, having a fixed time period seems suboptimal. IME different situations ask for different periods of time.

The policy is already "different periods of time."

perlpolicy:
If something in the Perl core is marked as deprecated, we may remove
it from the core in the future, though we might not. Generally,
backward incompatible changes will have deprecation warnings for two
release cycles before being removed, but may be removed after just
one cycle if the risk seems quite low or the benefits quite high.

--
rjbs
Re: review of perlexperiment, 2021-10 [ In reply to ]
On Fri, 08 Oct 2021 14:44:24 -0400
"Ricardo Signes" <perl.p5p@rjbs.manxome.org> wrote:

> "Until 5.18" ? in other words, "for the last eight years."

In terms of LTS Linux distributions, smartmatch was introduced in RHEL 6
and it started warning in RHEL 8, which is currently the latest version.

>
> "meaningless" ?
> given is experimental
> (S experimental::smartmatch) "given" depends on smartmatch, which is
> experimental, so its behavior may change or even be removed in any
> future release of perl. See the explanation under "Experimental
> Details on given and when" in perlsyn.
>
> Smartmatch is experimental
> (S experimental::smartmatch) This warning is emitted if you use the
> smartmatch ("~~") operator. This is currently an experimental
> feature, and its details are subject to change in future releases of
> Perl. Particularly, its current behavior is noticed for being
> unnecessarily complex and unintuitive, and is very likely to be
> overhauled.
>
> We need to be able to say that some things aren't guaranteed, and then *after eight years of saying that*, it needs to be able to mean something.
>
> Saying, "The practical impacts of changing this feature are big and need real consideration" is one thing. I am really not enthused by "we've been saying it might be changed or removed for eight years, and this is meaningless and not enough."

"Or even be removed" sounds like an unlikely possibility, not a threat.
Also, you're quoting perldiag, which I think is something that many users
won't ever see. The warning triggered by ~~ is just "Smartmatch is
experimental".

I know this isn't what our documentation literally says, but I think the
experimental status was supposed to mean "new, unpolished feature", not
"something that was implemented almost 15 years ago and everyone wants
it gone".

BTW, signatures have a similar problem. They've been marked as
experimental for an overly long time, which diminished that status and
caused the users to ignore it. Now it feels like everyone and their dog
is using signatures in production code.
Re: review of perlexperiment, 2021-10 [ In reply to ]
On 10/8/21 4:30 PM, Tomasz Konojacki wrote:
> On Fri, 08 Oct 2021 14:44:24 -0400
> "Ricardo Signes" <perl.p5p@rjbs.manxome.org> wrote:
>
>> "Until 5.18" — in other words, "for the last eight years."
>
> In terms of LTS Linux distributions, smartmatch was introduced in RHEL 6
> and it started warning in RHEL 8, which is currently the latest version.
>

So, are you proposing that, once again, Perl's development be throttled
to the tempo of RHEL? I thought we'd gotten past that.

Jim Keenan
Re: review of perlexperiment, 2021-10 [ In reply to ]
On Fri, 8 Oct 2021 18:36:55 -0400
James E Keenan <jkeenan@pobox.com> wrote:

> So, are you proposing that, once again, Perl's development be throttled to the tempo of RHEL? I thought we'd gotten past that.

Of course not, but when we're discussing deprecating widely used
features, we have to remember that LTS distributions exist.
Re: review of perlexperiment, 2021-10 [ In reply to ]
2021-10-4 6:50 Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:

> On Sun, 03 Oct 2021 16:41:37 -0400
> "Ricardo Signes" <perl.p5p@rjbs.manxome.org> wrote:
> > *isa* — I believe isa is complete. It works, it can be used, no
> > design changes seem to be in the wings. What prevents us from
> > calling this stable (and including it in the v5.36.0 feature bundle)?
> > #18754 <https://github.com/Perl/perl5/issues/18754>
>
> Largely just waiting on it to timeout really.
>
> There's still *an* ongoing problem in that it works kinda weirdly with
> the underlying reftype of an object.
>
> By which I mean, I had *wanted* the operator to work such that
>
> $obj isa Some::Class => implies "Some::Class" is somewhere in the
> @ISA tree for $obj
>
> But this isn't actually true for the special stringy names of the
> reftype; e.g. any blessed hash reference happens to be true for
>
> $obj isa HASH
>
> and yet the @ISA tree does not contain qw(HASH), nor does
>
> $obj->meth(...)
>
> attempt to invoke sub HASH::meth {}.
>
> It's a bit of a thorn in the design. It's discussed more in
>
> https://github.com/Perl/perl5/issues/18531
>
> but we never really reached a conclusion.
>
>
Is it possible to change to the expected behavior?

# Syntax
$obj isa Foo

# Logic (Although it has to be written in C)
my $ok;
if (Scalar::Util::blessed $obj) {
my $class = ref $obj;
my $isa_classes = mro::get_linear_isa($class);
for my $isa_class (@$isa_classes) {
if ($isa_class eq 'Foo') {
$ok = 1;
last;
}
}
}
Re: review of perlexperiment, 2021-10 [ In reply to ]
2021-10-4 6:50 Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:

> > *smartmatch* — We have resisted removing this failure for years, as
> > we want to replace it with something else. My take: we should just
> > rip this out and later, *maybe*, put something else in. #13173
> > <https://github.com/Perl/perl5/issues/13173>
>
> I'm hoping eventually to make match/case into core syntax:
>
> https://metacpan.org/pod/Syntax::Keyword::Match
>
> which would be able to replace almost all of the current uses of
> given/when, without needing to bother thinking about smartmatch.
>
> Alternatively, somewhat ironically, the strong splitting of PV vs IV/NV
> as achieved by Nicholas et.al. recently, may actually be an 11th hour
> saviour for smartmatch, in that it will suddenly make at least the
> string-vs-number tests it performs somewhat more reliable. It still
> won't save the overall "THIS IS CRAZY" feel of whether it even makes
> sense to ask such questions as
>
> %ENV ~~ &is_even
>
> though. :)
>
> from CitC earlier this year:
>
> https://www.youtube.com/watch?v=Kc_bP73xNyM
>
> (The brief summary begins at 45:20 until 47:10, if you don't fancy
> watching the whole ~50minute talk)
>
> --
> Paul "LeoNerd" Evans
>
> leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
> http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/


Is it possible to write a pre-RFC with match case syntax?

In my opinion, Syntax::Keyword::Match is very well designed.

I feel it is kind to prepare an alternative to the current smartmatch first.
Re: review of perlexperiment, 2021-10 [ In reply to ]
On Thu, 14 Oct 2021 12:58:25 +0900
Yuki Kimoto <kimoto.yuki@gmail.com> wrote:

> Is it possible to write a pre-RFC with match case syntax?

At some point, but I think it's still somewhat early yet. Almost nobody
is actually using SKM yet:

https://metacpan.org/dist/Syntax-Keyword-Match/requires?size=500

and additionally the design is far from finished yet. Still much to do.

> In my opinion, Syntax::Keyword::Match is very well designed.
>
> I feel it is kind to prepare an alternative to the current smartmatch
> first.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: review of perlexperiment, 2021-10 [ In reply to ]
On Thu, 14 Oct 2021 12:41:35 +0900
Yuki Kimoto <kimoto.yuki@gmail.com> wrote:

> Is it possible to change to the expected behavior?
...

That would be /possible/ but it would mean that it no longer behaves
like the existing ->isa method.

The original ->isa method behaves badly too:

$ perl -E 'say "URGH" if (bless {}, "not-a-hash")->isa("HASH")'
URGH

Thus is the core of the problem. Do we

a) Implement `isa` exactly like `->isa`, including that mistake?

b) Implement `isa` better, knowing it no longer matches `->isa`

Pick one. Both are bad. :(

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: review of perlexperiment, 2021-10 [ In reply to ]
2021-10-14 18:57 Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:

> On Thu, 14 Oct 2021 12:41:35 +0900
> Yuki Kimoto <kimoto.yuki@gmail.com> wrote:
>
> > Is it possible to change to the expected behavior?
> ...
>
> That would be /possible/ but it would mean that it no longer behaves
> like the existing ->isa method.
>
> The original ->isa method behaves badly too:
>
> $ perl -E 'say "URGH" if (bless {}, "not-a-hash")->isa("HASH")'
> URGH
>
> Thus is the core of the problem. Do we
>
> a) Implement `isa` exactly like `->isa`, including that mistake?
>
> b) Implement `isa` better, knowing it no longer matches `->isa`
>
> Pick one. Both are bad. :(
>
>
I pick b) Implement `isa` better, knowing it no longer matches `->isa`

Porters, Which do you want, a or b?

1 2  View All