--- Luke Palmer <[EMAIL PROTECTED]> wrote:
> Yeah, that's true. But note that you can't do that black magic you
> were
> speaking of earlier:
>
> $a [ (cond ?? &infix:+ : &infix:*) but tighter(&infix:*) ] $b
>
> Because we can't choose the precedence of an operator after we parse
> it... unless we're doing bottom up, which we're not. I do think that
> the infix [] construct would have to have a fixed precedence.
>
Run time or compile time? If the [] is a compile time operation, it
doesn't matter, of course, since everything is done.
If the precedence of [] can vary, or if user-ops can vary their
precedence, the parser will have to have some sort of "late
reevaluation" mechanism.
This fits in with the "recompile if you change the world" thread from
last week, I guess.
It also ties in kind of nicely with the "feel" of Damian's OOPerl book:
making objects out of unlikely things. In this case, we're making
operators out of them.
my &op1;
my &op2;
sub foo {
my $x = $^a &op1 $^b &op2 $^c;
print "Foo: " . $x . "\n";
}
# (Luke: Because these are literal lists, I don't need >>:=<<,
right?)
(&op1, &op2) := (&infix:+, &infix:*);
foo(3,4,5);
# Prints 23
(&op1, &op2) := (&op2, &op1);
foo(3,4,5);
# Prints 17 (27 if the parser doesn't rescan :-)
=Austin
