Re: Pseudo-Complete Lua Syntax

[Gavin Kistner <phrogz@...>]

On May 28, 2013, at 6:12 PM, Luiz Henrique de Figueiredo <lhf@tecgraf.puc-rio.br> wrote:
> The syntax in section 9 of the manual is based on the tokens described
> in section 3.1. The tokens in section 9 are either reserved words shown
> in bold or literal strings shown quoted. The exception as you have noted
> are Name, String, and Number. The words not in bold are non-terminals.

Thanks for the response (and the language :).

I never realized that the formatting of bold was intended to convey literal strings, so that's helpful. (But not EBNF, nor described in the manual. Why rely on formatting to convey something already covered by EBNF, and that you use for some of them?)


> There is indeed no formal grammar for the tokens; the textual description
> seems much more useful than regexes.

I agree that a textual description is more useful than regexes. However, an EBNF that isn't rigorous isn't much use (to me, anyhow). Wouldn't you agree that having the (excellent, informative) prose *and* a real, robust, correct grammar in the spec would be better than the current situation?


> The whitespace characters are the ones in ASCII, \t, \n, \b, \f, \r, ' ',
> ie, those with code 9, 10, 11, 12, 13, and 32.

Perfect information about what is considered whitespace, thank you.


However, regarding when and where whitespace is required vs optional: I humbly (and more clearly) reiterate that I think this should be included in a grammar somewhere. I truly do not understand how to rigorously apply the prose:
"[Lua] ignores spaces (including new lines) and comments between lexical elements (tokens), except as delimiters between names and keywords."

I am left with having to carefully consider and test the presence of whitespace before and after each and every surrounding terminal in the grammar to make my own determination based on my understanding of the language and behavior of the Lua interpreter.


Perhaps I'm being whiny because what I'm looking for hasn't been handed to me on a silver platter. However, as currently written, the current section 9 seems to me to be of very little benefit. About the only thing it seems good for, IMHO, is to lie to new users and grammar generators and make them think that the syntax of Lua is far simpler than it is. As it stands, the statement "Here is the complete syntax of Lua in extended BNF" is a lie. It is not complete, and it is not EBNF.

(Yes, that final language is intentionally inflammatory. I'm hoping to prod you right in the honor, with the goal of having more-precise, more-correct specifications. ;)