lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


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

----- Original Message -----
> From: "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. In particular, the grammar in
> the implementation is far from good for a tool like yacc. 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;
> 
> -- Roberto
> 
>