develooper 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 15:52
Subject:
Re: infix feature exploration with Sub::Infix (TOBYINK) ?
Message ID:
20210416165219.067a398a@shy.leonerd.org.uk
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.

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');

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


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