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

Re: review of perlexperiment, 2021-10

Thread Previous | Thread Next
Paul "LeoNerd" Evans
October 3, 2021 21:49
Re: review of perlexperiment, 2021-10
Message ID:
On Sun, 03 Oct 2021 16:41:37 -0400
"Ricardo Signes" <> 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 <>

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


attempt to invoke sub HASH::meth {}.

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

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

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

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

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:

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

Paul "LeoNerd" Evans      |  |

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About