Front page | perl.perl5.porters |
Postings from March 2013
Infix subroutines
Thread Next
From:
Brian Fraser
Date:
March 10, 2013 17:04
Subject:
Infix subroutines
Message ID:
CA+nL+nZdUMGpauTey43WnEDqEizDVjCUbRcLVtLQOxUZpETkdA@mail.gmail.com
Howdy all!
Let me start by saying that I am not proposing merging this into
blead. The implementation is awkward and broken and could use a
thousand improvements, and it's best to consider the end product more
as a reference for future attempts than anything else. My starting
goal here was to learn a bit how perly.y and toke.c worked with each
other, but ended up with this mistake.
Personally, I was surprised that the bulk of the commit was regenning
perly.y - the actual (broken, evil, etc) changes to the codebase were
around a hundred lines or so.
https://github.com/Hugmeir/utf8mess/tree/infix_subs
That branch introduces a new prototype, >, and a new feature,
'infix_subs'. Here's some examples, copypasted from the pod:
sub myeq ($>$) "string" myeq "string"
sub dor ($>$) $maybe_undef dor 1
sub zip (@>@) qw/a b c d/ zip (1, 2, 3, 4)
sub in (@>%) @keys in %hash ? 'Yes' : 'No'
sub to (\[$@]>*) @lines to $filehandle
Arguments on the lhs will be in $_[0], arguments on the rhs in $_[1].
The only differences with normal prototypes is that a sole @ wraps the
arguments in an arrayref, while a sole % wraps them in a hashref.
Also, the & prototype is unimplemented, except to check that the
arguments are coderefs, so don't expect { ... } doof { ... } to work;
additionally, the _ prototype is currently useless, because you must
always pass at least one argument, even if that's an empty list.
I originally picked the > prototype because someone jokingly mentioned
it on irc, then left it in case someone wants to add a
lower-precedence version using <, so you can have your sub myor work
slightly less wrong. I didn't do any of that, as it would've meant
implementing lazy arguments to get the short-circuiting right, and I
would've sodded that one up.
For the curious, you can see some examples in t/op/infix_subs.t.
Opinions welcome! ..and particularly, is there an actual need for
these? That is, should I actually try to polish/reimplement them with
the aim of eventually getting them merged?
Thread Next
-
Infix subroutines
by Brian Fraser