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

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

Thread Previous | Thread Next
From:
B. Estrade
Date:
April 16, 2021 16:53
Subject:
Re: infix feature exploration with Sub::Infix (TOBYINK) ?
Message ID:
e7210ec3-a3c7-46e2-d854-aca06c4101fe@cpanel.net


On 4/16/21 10:52 AM, Paul "LeoNerd" Evans wrote:
> On Fri, 16 Apr 2021 09:48:09 -0500
> "B. Estrade" <brett@cpanel.net> wrote:
> 
>> First, I am sorry for being *that* guy with neilb's email. I'll read
>> more carefully in the future.
>>
>> On to the subject of the email. Since really learning about the
>> primary use case for sub prototypes, I've been trying to determine if
>> one could use it - or something - to use current perl to define an
>> infix operator.
>>
>> I decided to search CPAN (duh) and found Sub::Infix. It satisfies
>> what I would imagine such a native capability would provide. Even
>> better, it's on CPAN.
>>
>> Is there a deficiency in this approach that requires time being spent
>> on other solutions? A person owns their time, so no judgment. I am
>> just wondering if this was even known or considered?
>>
>> https://metacpan.org/pod/Sub::Infix
> 
> To quote its docs:
> 
>    > Sub::Infix creates fake infix operators using overloading.
> 
> Its own synopsis has:
> 
>    # Operator needs to be defined (or imported) at compile time.
>    BEGIN { *plus = infix { $_[0] + $_[1] } };
>   
>    my $five = 2 |plus| 3;
> 
> Not wishing to turn this mail into a long critique of Sub::Infix, but
> that's a) terrible, and b) about the best you can do from Pure Perl.
>

Sub::Infix is a straw man. A relevant straw man, but one none the less. 
I am not presenting it to be burned for effigy, but something needs to 
service this role.

This is great feedback. #a notwithstanding, #b is an extremely helpful 
statement.

My next question towards my interest is, can we leverage this "best you 
can do" to explore the evaluation of language features.

Necessarily, starting with "best one can do" in pure Perl is the precise 
place we need to exert the greatest pressure.

a) is this actually sufficient to deliver the actual value of custom infix?

b) do we really want custom postfix/circumfix/etc (this would a nice 
follow up "challenge")

c) did we learn that what people *really* want are "hyperops" (not sure 
I understand that concept yet)?

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?

In other other words, what core work provides the most value? And this 
ultimately is the "search space" over which we're operating for language 
extensions and allocating time, effort, and personal investment to achieve.

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.

 >
> Basically you can only have identifier-named operators and they have to
> be surrounded by |pipes|.
> 
> ...
>> Finally, I'd like to suggest that if having an easy way to add infix
>> operators in Perl is indeed a potential for game changing features
>> exploration, we should make an official call to any interested part
>> to; using Sub::Infix to submit any number of trial infix operators by
>> publishing them on CPAN (even under some Trial:: type of name space,
>> or not). And we can go from there. If this is _good enough_ to test
>> the efficacy of different infix options, is Sub::Infix not something
>> that we could use to rapidly prototype them? And better still, maybe
>> someone will figure out Sub::Infix::Tiny (bonus points if so). And
>> maybe we'll discover a) Sub::Infix is perfect and should be promoted
>> to "dual life" or generate new ideas to test in this way (e.g., CPAN
>> 'feature' Challenge).
> 
> I already have a much better way to do these; my upcoming
> XS::Parse::Infix. That allows this - taken from the unit tests of
> Syntax::Operator::Equ:
> 
>    ok(  "abc" equ "abc", 'identical strings');
>    ok(!("abc" equ "def"), 'different strings');
> 
>    ok(  123 === 123, 'identical strings');
>    ok(!(123 === 456), 'different strings');
> 
> Notice a) the lack of |pipes| and b) the use of non-identifier
> operators; ie. the ===.
> 
> This technique is more powerful still; it can create hyperoperators as
> well (i.e. operators that work on other syntax, such as other
> operators). This from Syntax::Operator::In:
> 
>    ok(    "c" in<eq> ("a".."e") , 'c is in a..e');
>    ok(not("f" in<eq> ("a".."e")), 'f is not in a..e');
> 

Thank you. I can't argue about how compelling an ability to do something 
is. I am attempting to figure out for myself, how determine where to 
allocate effort and personal investment as cheaply as possible.

The obvious answer for me is, we have a huge warehouse of options. Let's 
see what we can do to justify the human capital involved in "going deep" 
into Perl.

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

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

Hopefully you can see that I am not discounting the value of an infix 
infrastructure. My goal is not even to determine the value of the 
ability of supporting infix (in this case). My goal is to provide a 
logical, sane, and humane feature pathway that we "mere moral" Perl 
programmers can participate in.

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

Let's keep this conversation going with the higher order goals in mind, 
while lovingly burning our straw men. Even if we must add "infix" 
support as yet another straw man.

Cheers,
Brett

Thread Previous | Thread Next


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