> -----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