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
Incidentally, I recommend peering at TOBYINK's modules. His work first
caught my eye one night late as I was perusing CPAN 'recent' - something
I do often, with his "Mom" module. I mean, who wouldn't click that? The
result was me actually considering using Moo.
There are also things like Zydeco - an OOP framework I'd actually
consider using due to its lack of boiler plate. (Incidentally, a true
hidden gem of perl OOP IMO is HAUKEX's Util::H2O; recommend that if you
have not seen it).
I am pointing out many things here and highlighted TOBYINK because I was
already aware of his innovative use of exiting perl/Perl. This is the
spirit I wish to promote. He's not the only one, I do have a short list
of authors I've really come to appreciate.
Another reason I am pointing this out has to do with the idea of
sane/humane feature development. Is there a reason Sub::Infix can't be
the way that custom infix operators as-CPAN modules can't be explored? I
have not tried to implement the doh operator ... yet :)
So I submit that part of the "sane" approach would be to somehow
determine a short list of perl's most requested language extensions.
From, create a short description (but not too short) of what it should
do; then make open calls for our most creative and ambitious perlers to
create a prototype on CPAN. The purpose of this is to a) see if such a
thing would be possible in pure Pure (or babby XS); b) flesh out
questions about how to make it "perlish", and c) provide users with a
one or more implementations on CPAN to test the usefulness of such
module(s) - I suppose a "reverse dep" check on other CPAN modules is
probably a better and more implicit way to determine this - it's already
there now.
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).
Unless I am grossly judging what I foresee, LeoNerd (e.g., and not to be
insensitive or presumptuous) would be able to focus on other things if
he wishes. If not, fine also. This is is not about me, him, or anyone -
it's about working out what the process to featurehood is. Furthermore,
this could end up showing that Sub::Infix is insufficient in some way
that requires core changies; and that my general points are flawed in
some fundamental ways.
FWIW, I could see the "call" to be handled in much the same way as the
original PRCs were. This really pulled me in when neilb started doing
them years ago. And I will be forever grateful that he did.
I suppose if I *should* offer to facilitate such a "challenge". So here
it goes, if anyone is interested in participating in such a 'CPAN
feature Challenge', email me (off list preferred). Please don't wait 24
hours to let me know.
Cheers,
Brett :)
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
Incidentally, I recommend peering at TOBYINK's modules. His work first
caught my eye one night late as I was perusing CPAN 'recent' - something
I do often, with his "Mom" module. I mean, who wouldn't click that? The
result was me actually considering using Moo.
There are also things like Zydeco - an OOP framework I'd actually
consider using due to its lack of boiler plate. (Incidentally, a true
hidden gem of perl OOP IMO is HAUKEX's Util::H2O; recommend that if you
have not seen it).
I am pointing out many things here and highlighted TOBYINK because I was
already aware of his innovative use of exiting perl/Perl. This is the
spirit I wish to promote. He's not the only one, I do have a short list
of authors I've really come to appreciate.
Another reason I am pointing this out has to do with the idea of
sane/humane feature development. Is there a reason Sub::Infix can't be
the way that custom infix operators as-CPAN modules can't be explored? I
have not tried to implement the doh operator ... yet :)
So I submit that part of the "sane" approach would be to somehow
determine a short list of perl's most requested language extensions.
From, create a short description (but not too short) of what it should
do; then make open calls for our most creative and ambitious perlers to
create a prototype on CPAN. The purpose of this is to a) see if such a
thing would be possible in pure Pure (or babby XS); b) flesh out
questions about how to make it "perlish", and c) provide users with a
one or more implementations on CPAN to test the usefulness of such
module(s) - I suppose a "reverse dep" check on other CPAN modules is
probably a better and more implicit way to determine this - it's already
there now.
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).
Unless I am grossly judging what I foresee, LeoNerd (e.g., and not to be
insensitive or presumptuous) would be able to focus on other things if
he wishes. If not, fine also. This is is not about me, him, or anyone -
it's about working out what the process to featurehood is. Furthermore,
this could end up showing that Sub::Infix is insufficient in some way
that requires core changies; and that my general points are flawed in
some fundamental ways.
FWIW, I could see the "call" to be handled in much the same way as the
original PRCs were. This really pulled me in when neilb started doing
them years ago. And I will be forever grateful that he did.
I suppose if I *should* offer to facilitate such a "challenge". So here
it goes, if anyone is interested in participating in such a 'CPAN
feature Challenge', email me (off list preferred). Please don't wait 24
hours to let me know.
Cheers,
Brett :)