lua-users home
lua-l archive

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

Even if the lexer creates a single lexeme for ">=", the parser could still accept it as a fallback but this requires splitting parsing rules for matching the next "=" within the context of use (an assignment statement). This may seem inelegant, but that's what is done actually in complete parser s that would have to work around would would be otherwise a syntax error with an unexpected token.

However you could as well drop the ">=" token and always treat it as two tokens (optionally separated by spaces/comments) without creating syntaxic ambiguities in expressions expecting the binary comparator. just consider, this code:

  if x > = 0 then

Is it really ambiguous for programmers and more difficult to parse ?

As well for other diagrams used in operators, which could be parsed more leniently by allowing them to be split by optional whitespaces/comments In fact it could simplify the lexer, with a very modest slowdown for the parser as it will read, and shift a few more tokens in an automata which is a bit larger in terms of total number of states.

If you don't do that, yes there programmers have to use explicit whitespace separators between ">" terminating an attribute and the "=" sign marking an assignment. This is minor because usual conventions recommend separating "=" in assignments for formatting the code.

This is then a very minor issue we can live with.

Le mer. 19 août 2020 à 17:39, Soni "They/Them" L. <> a écrit :

On 2020-08-19 12:36 p.m., Sergey Zakharchenko wrote:
> Hello,
> As far as i understand, the current (5.4.0) parser requires a space
> after the attribute's closing '>' if it's followed by a '=', resulting
> in an error "'>' expected near '>='" when parsing e.g. "local
> a<close>=f()". I don't mind that too much, but it seems a bit
> inelegant to me. Is it going to stay this way, or will the construct
> without a space be allowed eventually?

actually, it's the lexer that requires it. while it could probably be
done, it'd require a completely different parser design.