Re: [ANN] Lua 5.2.0 (beta-rc1) GOTO

[Pierre-Yves Gérardy <pygy79@...>]

On Thu, Jun 16, 2011 at 10:10, Michael Rose <michael.h.rose@web.de> wrote:
> We have to distinguish the current Lua beta and my suggestion.
> In my '@' extension, such labels are perfectly legitim. They need not be
> of identifier form to allow compiler generated labels being safely different
> from user generated ones.

I got confused because you used "name" in your description, and I
undestood it is defined in the Lua grammar.
The implementation could be greatly simplified by slightly changing
the rules, though.

>       case '@': {
>         save_and_next(ls);
>         switch (ls->current) {
>           case '@':  next(ls);  return '@';
>           case '[':  next(ls);  return TK_STATBEG;
>           case '|':  next(ls);  return TK_STATEXP;
>           case ']':  next(ls);  return TK_STATEND;
>         }

You could hard code the "|" and "]" tokens in the parser and get rid
of the second and third @ which are bulky and redundant (they're not
needed for a non-ambiguous grammar).

var = @[ statements | expresion ]

>         if (lisdigit(ls->current)) {
>             ...
>         }
>         for (;;) {
>             ...
>         }
>     } // case '@'

That logic belongs to the parser.

With distinct initial tokens, and if you forbid spaces in labels, you
can get away with something like this (there are probably in the use
of next(), I havent played with the parser for some time):

       case '@': {
         save_and_next(ls);
         char c = ls->current;
         switch (c) {
           case '@':  next(ls);  return '@'; // I'm puzzled with this one.
           case '[':  next(ls);  return TK_STATBEG;  // @[ statements
| expresion ]
           case '(':  next(ls);  return TK_IDENTIFIER; // @( identifier )
           case '>':  next(ls);  return TK_GOTO; // @>valid lua names
numbers and "strings" 123>
           case '!':  next(ls);  return TK_LINENUMBER; // @!123"file.name"
           default:  return TK_LABEL; // to allow Lua 5.2
compatibility, assuming that the @ is kept for labels
          }
       }

That's it :-)
You can then add the relevant entries in the statement function in lparser.c.

If you restrict the labels and identifiers to valid Lua lexemes, you
can also reuse the lexer rather than rolling your own hand-made
solution.

The choice of the sigils is a matter of taste, but the initial tokens
simplify the implementation. Good luck to introduce a bug in this
code.

Regards,
-- Pierre-Yves