Infix macros?

[Matthijs Van Duin]

Will infix operators be allowed to be macros instead of subs?

They'd be kinda necessary for infix operators for which standard sub
conventions are insufficient and need to diddle the parse tree instead,
such as short-circuiting operators.

It would also allow Damien's original <~ operator (R2L method call) to be
implemented with something like this...

(warning: I had to invent a lot here, but it should hopefully make at least
a little bit sense :-)

macro infix:<~ (Perl6::Node $x, Perl6::Node $y) is tighter(&infix:=) {
# regular case, turn foo $x, $y <~ $obj into $obj.foo($x, $y)
if ($x ~~ Perl6::SubCall) {
return new Perl6::MethodCall: $x.name, $y, $x.args;
}

# ugly hack in case foo $x, $y <~ $o was parsed as foo($x), $y <~ $o
# however foo, $x <~ $obj should still give an error, so beware
if ($x ~~ Perl6::List && !$x.parens && $x.items > 0) {
my $z = $x.items[0];
if ($z ~~ Perl6::SubCall && !$z.parens && $z.args > 0) {
my @args = $z.args, $x.items[1...];
return new Perl6::MethodCall: $z.name, $y, @args;
}
}

# helpful error message ;-)
croak "Can't deal with the stuff left of <~ operator";
}

--
Matthijs van Duin -- May the Forth be with you!

[Larry Wall]

On Tue, Mar 11, 2003 at 04:39:05PM +0100, Matthijs van Duin wrote:
: Will infix operators be allowed to be macros instead of subs?

Yes, but they can't retroactively change the rules under which the left
argument was parsed. At most they can rearrange the returned parse
tree. The right argument is fair game for any parsing shenanigans
you want to try. (See other message on a ".select" macro, for instance.)

Larry