Re: [Announce] Alpha release of a Lua debugger

[Rici Lake <lua@...>]

Thomas Lauer wrote:
> Rici Lake <lua@ricilake.net> wrote:
> > Thomas Lauer wrote:
>
> > One has to take responsibility for one's own modifications,
>
> Yeah, I am fully aware of that.

Sorry, that came out much snottier than I intended.

What I mean is, it's possible to implement new keywords without
creating that particular problem, or at least it is possible to
mitigate the effects.

For example, rather than make 'continue' a actual keyword in
the lexer, you can leave it as a TK_NAME and do a special case
recognition in the parser. It only needs to be checked when a
statement is expected, and since it must be a block ender, it can
only be followed by 'end', 'else'. 'elseif', 'until' and ';'.
There is no syntactically correct Lua program in which 'continue'
could be used as a variable which would fit into that syntactic
context: a variable name used at the beginning of a statement
must be followed by ',', '=', '(', '[', '{' or a string literal.
Since the Lua parser is LL(2) -- it allows an extra lookahead
if necessary -- 'continue' can be added without invalidating
existing programs.

That's not a general solution, of course; it doesn't work for
new statement keywords where the statement keyword is followed
by a <chunk> or an <expr>. One of the things I've been toying
with is to check whether the TK_NAME has been declared local
before recognizing it as a keyword. This still leaves the case
where the new keyword conflicts with an existing global (or
module global), but it will cover a goodly number of the
compatibility issues.

Looked at from another perspective, the use of barewords as
table keys is completely syntactically separate from their
use as keywords. A table key must either follow '.' or ':'
in postfix position, 'function' in a <function> statement,
or it must be used as the first token in a table field and
followed by '='.

Allowing reserved words to be used as table keys would
therefore not change the meaning of any syntactically
correct Lua program, something I think about every time
I write table-driven code generators.

The only counter-argument that I know of to doing this
is that it makes life more difficult for syntax highlighters
and other such tools which do not contain a full parser.