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

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

Thread Previous
From:
B. Estrade
Date:
April 16, 2021 17:49
Subject:
Re: infix feature exploration with Sub::Infix (TOBYINK) ?
Message ID:
10eca8cf-cf6d-d927-85ad-73c94f3e40ce@cpanel.net
Thank you, all of your content inline below is helpful and insightful 
(of the +5 variety). I will definitely be keeping an eye out for your 
work and explore your branches and CPAN modules you mention below.

I can't speak on the syntax or others preferences. Seems like you're 
providing the kind of paths I am envisioning. This is good.

My next wonder is beyond infix and looking at what other interesting 
features have been desired. Does such a "short list" of feature requests 
exist?

If I can find a reasonably canonical list, my plan is to initiate the 
set of "feature challenges" I spoke of previously. My thought goes to 
generic semantics for expressing partial ordering among executable 
blocks - a generalization of expressing concurrent programming models in 
a way that is both semantically consistent with Perl and able to be 
handled in a correct way.

But I am not ready for that challenge myself. Maybe soonish. What's 
really starting to gather in my mind is a set of "grand challenges" for 
the Perl community to target. I promise not to post again for 24 hours 
from now :)

Cheers,
Brett

On 4/16/21 12:30 PM, Paul "LeoNerd" Evans wrote:
> 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. ;)
> 

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About