Re: lua 5.2 EBNF in manual

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

2013/10/29 Roberto Ierusalimschy <roberto@inf.puc-rio.br>

> That's why I think it is annoying to document the BNF differing than the
> actual implementation. There is no such problem in the real parser, and
> there should be no need to invent another solution.

The purpose of the specification is to specify, not to give you a ready
implementation for one particular tool.

Yes. But a BNF with left-recursion mandates a parsing algorithm with more strength (and with more complexity) so it imposes an obstacle to implementers pursuing a simpler parser. It is like to say to anyone who wants to implement an LL parser: go figure out a recursion-eliminating solution on your own.

 

In particular, the grammar in
the implementation is far from good for a tool like yacc.

Yacc is LALR so it is unsurprising it usually has clearer BNF, but not without a cost in code readability.

 

Moreover, in
my opinion, the grammar in the real parser is more difficult to read,
because sentences that we tend to think as a block, such as 'a:f(x)', are
broken in a kind of CPS. Finally, the real parser must rely on semantics
analysis to reject things like these:

  f(x).a;
  f(x) = a;

Yes, that is a problem. But the problem in complex software specification is, English text usually has this or that ambiguity (and EBNF is not such a perfect formal presentation cover every corner of a language anyway). Without a formal tool being able to stand on its own, a consistent connection between spec text to a reference implementation has irreplaceable value. Now we have a more understandable BNF but lose such connection. I am not fully convinced it is a good trade.

 

-- Roberto