> -----Original Message-----
> From: Eirik Berg Hanssen [mailto:[EMAIL PROTECTED]
> Sent: Saturday, September 27, 2003 11:35 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Pondering parameterized operators
>
>
> Luke Palmer <[EMAIL PROTECTED]> writes:
>
> > Hmm, since we're requiring no whitespace between a variable and it's
> > subscript, this should be possible:
> >
> > if "Dough" [eqn 4] "Douglas" {...}
>
> Lisp! :-)
No, just horribly early evaluation.
That'll do, Luke. That'll do.
> if $test [$moon.is_waxing ? &infix:< : &infix:>=] $target {...}
This is right, presuming we have a way to give the parser the right data
(function properties).
> Let us see ... somewhat speculative and probably short-of-the-mark
> generalization coming up:
>
>
> macro infix:[ ($lhs, $op, $rhs)
> is parsed(/(<Perl6.expr>) \] (<Perl6.expr>)/) {
> return {
> $op($lhs, $rhs)
> };
> }
>
> (Precedence? Err ... the left hand side has already been parsed,
> so infix:[ must be of fixed precedence to the left hand side, right?
> Damn, I thought I had it ...)
This is text replacement, not expression evaluation. You do have it from
where I sit.
# Note: Need a way to parse nested []'s
macro [ ($whosit) is parsed(/(<?:\s[) (<expr>) \]/) {
eval $whosit;
}
The macro immediately evaluates the expression, so it has to be a deferrable
reference.
Then:
macro infix:eqn($n) is equiv (&infix:eq) {
"[&String::strncmp.assuming(n => 4)]"
}
so
if "Dough" eqn(4) "Douglas" {...}
becomes
if "Dough" [sub &String::strncmp.assuming(n => 4)] "Douglas" {...}
becomes
if "Dough" <temporary infix-binary inserted by macro> "Douglas" {...}
and it just works. Woo-hoo!
> Then vector operators, like >>+<<, are "really" just simple
> [vectorize &infix:+] and similar -- except properly optimized and
> presumably with proper precedence. And, you can write:
> if "Dough" [&String::strncmp.assuming(n => 4)] "Douglas" {...}
> Still long. Oh well. infix:[eqn, perhaps? At least that one will
> be of fixed precedence. Right?
See above. No precedence worries with an "unattached" macro -- do a text
replacement
or give the parser a correctly attributed tree, and let it worry about it.
=Austin
