On Wed, Mar 26, 2008 at 06:06:29PM +0100, TSa wrote: > HaloO, > > Larry Wall wrote: >> That interpretation doesn't help me solve my generic parsing problems, >> which is about the relationship of op1 to op2 and op3 in >> >> op1 a() op2 b() op3 c() >> >> and presumably the same thing for postfixes in the other order. > > My idea is to have a term re-writing stage before the precedence > parser does its job. I assume that "chalkboard mathematics" means > term re-writing. Which sort of means that infix:<->($x,$y) is a macro > that expands to infix:<+>($x,prefix:<->($y)).

Alas, you can't figure out which terms to rewrite until you've parsed them. >> So here's another question in the same vein. How would mathematicians >> read these (assuming Perl has a factorial postfix operator): > > Without implying to actually being a mathematician I'll > give my thoughts on the subject. > > >> 1 + a(x)**2! > > That is a poor version the the version below and obviously > depends on the precedence that ! has relative to **. > >> 1 + a(x)²! > > This means to me to square the return value of a(x), then > take the factorial and then add 1. Getting a(x) raised to > 2! would require the ! to be superscripted as well. Its ASCII > version would explicitly require a(x)**(2!). So a(x)**2! is > either ambiguous or requires lower precedence for !. My actual > reading of the ASCII version picks a(x) as the operation with > highest precedence and going from there outwards encountering > + to the left and ** to the right with ** being of higher > precedence. Then I'm left with + to the left and ! to the right > with precedence of ! higher than +. That's what I thought. Now note that ! can't easily be rewritten as a simple binary operator (unless you do something recursive, and then it's not simple). Now, I think I know how to make the parser use precedence on either a prefix or a postfix to get the desired effect (but perhaps not going both directions simulatenously). But that leads me to a slightly different parsing question, which comes from the asymmetry of postfix operators. If we make postfix:<!> do the precedence trick above with respect to infix:<**> in order to emulate the superscript notation, then the next question is, are these equivalent: 1 + a(x)**2! 1 + a(x)**2.! likewise, should these be parsed the same? $a**2i $a**2.i and if so, how to we rationalize a class of postfix operators that *look* like ordinary method calls but don't parse the same. In the limit, suppose some defines a postfix "say" looser than comma: (1,2,3)say 1,2,3say 1,2,3.say Would those all do the same thing? Or should we maybe split postfix dot notation into two different characters depending on whether we mean normal method call or a postfix operator that needs to be syntactically distinguished because we can't write $a.i as $ai? I suppose, if we allow an unspace without any space as a degenerate case, we could write $a\i instead, and it would be equivalent to ($a)i. And it resolves the hypothetical postfix:<say> above: 1,2,3.say # always a method, means 1, 2, (3.say) 1,2,3\ say # the normal unspace, means (1, 2, 3)say 1,2,3\say # degenerate unspace, means (1, 2, 3)say This may also simplify the parsing rules inside double quoted strings if we don't have to figure out whether to include postfix operators like .++ in the interpolation. It does risk a visual clash if someone defines postfix:<t>: $x\t # means ($x)t "$x\t" # means $x ~ "\t" I deem that to be an unlikely failure mode, however. So maybe .++ is just gone now, and you have to write \++ instead. Any objections? I suppose that means that .(), .[], and .{} would also be gone, in favor of \(), \[], and \{}. We'd given a different meaning to &foo\() at one point, but I think that went away. And since these postfixes aren't alphanumeric, you don't need the degenerate unspace to separate them from a variable name. So you generally wouldn't see them unless you wanted $a\ () with extra whitespace. Another possible downside: getting rid of the .postop form also has the side effect of getting rid of these bare forms .++ # meaning ($_)++ .() # meaning ($_)() .[] # meaning ($_)[] .{} # meaning ($_.{} .<> # meaning ($_)<> .i # meaning ($_)i :) I'm not sure that's a great loss. It does suggest an alternate approach, though, which is to keep the .() forms with forced method precedence, and only require \x form for alpha postfixes that want to keep their own precedence. Not sure if I like that entirely, but it could fall out naturally from the definition of unspace in the current scheme of things, so maybe it's a non-issue. And it makes it really easy to define postfixes equivalent to prefixes: &postfix:<-> ::= &prefix:<->; $x\- &postfix:<abs> ::= &prefix:<abs>; $x\abs and maybe even &circumfix:<| |> ::= &prefix:<abs>; |$x| except for the fact that that would collide with prefix:<|>... Larry