On Wed, Dec 17, 2008 at 9:53 PM, Yuh-Ruey Chen <[email protected]> wrote: > Lex Spoon wrote: >> On this list, the => form has so far been dismissed due to parsing >> concerns. If that's the only reason, let me try and allay that worry >> and put that horse back in the race. Scala also has a comma operator, >> but it still manages to parse the => syntax. They way it does it is >> to initially parse an expression and then, if it sees a =>, >> reinterpret what it has seen so far as a parameter list. It's an >> unusual parsing strategy, but it works well and the issue is >> localized. >> > > I don't think anyone is suggesting that it would be too difficult to > parse for bottom-up parsers. It's just that it makes it difficult for a > certain common class of bottom-up parsers, namely the LALR(k) for fixed > k parser generators, to parse.
Good point. Actually, though, the same sort of approach should still work. The grammar for a => entry would be something like: atomic_expression "=>" atomic_expression Then, the rule that assembles this parse tree into a real AST would analyze the expression on the left and either convert it to a parse tree, or emit a retroactive parse error. I know this initially violates some design sense--it does mine!--because normally a parser rule reuses subexpressions without change. However, in this case it works out well, and so I think the rule of thumb is misleading. This implementation technique should be simple, localized, easy to understand, and as a result robust. Lex _______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
