Allen's lambda syntax proposal

Lex Spoon spoon at
Thu Dec 18 06:19:46 PST 2008

On Wed, Dec 17, 2008 at 9:53 PM, Yuh-Ruey Chen <maian330 at> 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.


More information about the Es-discuss mailing list