Re: lua 5.2 EBNF in manual

[Dong Feng <middle.fengdong@...>]

2013/10/31 Robert Virding <robert.virding@erlang-solutions.com>

Actually that's wrong. The grammar is very, very close to being an LALR(1) grammar. I only needed to change the rule:

    stat -> functioncall

to

    stat -> prefixexp

and it went straight through a yecc, which is a yacc-like parser generator for Erlang, without a hitch. Without the change you get reduce-reduce conflicts. Then you just needed to add a check that the production WAS a function call otherwise generate an error and everything worked. Even the optional semicolon was easy to handle. So the grammar is very regular.

This does make it easier if you want to make your own Lua implementation or Lua source code tools.

Robert

The point is not whether the specification complying with LALR or not. The point is whether the syntax in specification should be LALR or LL.

I have no problem with LALR itself. As you pointed out, LALR usually has more clean rules because of its more powerful (and more unreadable) parser.

But I do not think LALR is naturally superior than LL in all aspects. Its clarity in syntax is at the cost of parse code's readability. LL parser, on the other hand, usually use more obscure syntax rules (for left-recursion elimination) and sometimes require additional semantic-phase trick (but this is usually local, comparing to a globally unreadable LALR parser). However, LL parsers are usually good to understand from source code.

I have no problem in choosing LALR in the spec per se. It is to me only nice-to-have to use a LL syntax. But it turns to be closer to should-have when the reference implementation itself is an LL parser. Losing consistency between spec and "reference implementation" is not a good trade in my opinion.