Front page | perl.perl5.porters |
Postings from April 2021
Re: infix feature exploration with Sub::Infix (TOBYINK) ?
Thread Previous
|
Thread Next
From:
Paul "LeoNerd" Evans
Date:
April 16, 2021 17:30
Subject:
Re: infix feature exploration with Sub::Infix (TOBYINK) ?
Message ID:
20210416183038.2223a679@shy.leonerd.org.uk
On Fri, 16 Apr 2021 11:52:58 -0500
"B. Estrade" <brett@cpanel.net> wrote:
> c) did we learn that what people *really* want are "hyperops" (not
> sure I understand that concept yet)?
I am somewhat dubious of this fact, but it seems at least some people
-really- do want it.
People continually ask for an "in" operator, so they can test if a
value is an element of a list. I'm forever pointing out that that's
already possible since basically forever using List::Util::any:
if(any { $str eq $_ } @values) { ... }
but for some reason some people dislike that. Maybe that extra set of
braces is offputting - I don't know.. They'd prefer to write
if($str in<eq> @values) { ... }
if($str in:eq @values) { ... }
(I'm still undecided about <cheverons> vs colon notation here)
I'm not sure I _quite_ feel the value proposition is really worth it;
but perhaps I would have felt the same way about say() before it was
added.
> Given a, b, c above; what fundamental core capabilities, if they do
> not exist or require "terrible" things, need to be provided so that
> these kind of language extensions *can* be satisfactorily facilitated
> using merely pure Perl or babby XS?
>
> In other words, what *actually* needs to be added to perl such that
> it maximizes the number of CPAN contributions either provide or
> leverage these capabilities?
PL_infix_plugin. See my branch
https://github.com/Perl/perl5/tree/leonerd/infix-plugin
> This kind of exercise is not like search optimization algorithms,
> like simulated annealing. We may be "stuck" in a local
> maximum/minimum with regards to Perl. And we need to "shake it up" to
> continue along the search for what Perl looks like optimally. I don't
> know if you understand that analogy, but it's one I have quickly at
> hand.
Indeed. My "shaking it up" is based around creating a couple of new
CPAN modules that I would suggest be used as the way to create syntax
plugins, rather than people using the core API directly:
https://metacpan.org/pod/XS::Parse::Keyword
https://metacpan.org/pod/XS::Parse::Sublike
plus I plan to have the new XS::Parse::Infix up as well once core can
support it.
> I have already, sufficiently I think, proven that 'trim' and 'say'
> should never have been implemented in core. One ship has sailed,
> another hopefully has sparked a greater journey of discovery. 'isa',
> I can't speak of, but it's striking how much less code it took to
> implement than 'trim'. Now I believe I have provided a compelling
> pathway to:
>
> * "cheaply" determine what infix ops would be unexpectedly useful
> * provide an opportunity to explore *what* can't be done in pure Perl
> or baby XS, and therefore warrants deeper core support
> * continue to develop this "model" for new feature exploration and
> cleanly determining exactly what core support is needed
Indeed - use my CPAN modules above.
> I will concede that the set of valid reasons for paying the cost of
> core development include, but are probably not limited to:
>
> * the alternative is inelegant
> * the alternative is orders of magnitude slower than lower level core
> support
> * pure Perl + baby XS can't support this feature with out a
> gratuitous amount of "adult" XS
Take a look at how little XS code is actually involved in using those
modules. E.g. I've already put up Syntax::Keyword::Match:
https://metacpan.org/source/PEVANS/Syntax-Keyword-Match-0.01/lib%2FSyntax%2FKeyword%2FMatch.xs
that's tiny. That's actually much much less code than it takes to
implement in core. Much easier to write, much faster to build and
unit-test and run through the CPAN cycle every few days, rather than
the yearly perl releases. It's verymuch the way I think we should do
things going forward.
> Thank you, again, LeoNerd for all your work. I hope you can see that
> I value your time. I don't mean to patronize here; but frankly if we
> can determine that this infix support is not needed, I think your
> talents (and the talents of the others) could be more appropriate
> applied in areas identified by the process I am suggesting (or some
> variation of it).
I've already built it. It took a few days. That's all. ;)
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Thread Previous
|
Thread Next