Re: infix feature exploration with Sub::Infix (TOBYINK) ?

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/

• infix feature exploration with Sub::Infix (TOBYINK) ? by B. Estrade
• Re: infix feature exploration with Sub::Infix (TOBYINK) ? by Paul "LeoNerd" Evans
• Re: infix feature exploration with Sub::Infix (TOBYINK) ? by B. Estrade
• Re: infix feature exploration with Sub::Infix (TOBYINK) ? by Paul "LeoNerd" Evans
• Re: infix feature exploration with Sub::Infix (TOBYINK) ? by B. Estrade