On Sat, Jun 29, 2019 at 10:11:49PM +0200, Philippe Verdy wrote:
> to repeat the nightmare of semicolons at end of statements ?
how is that a "nightmare" ?
It's a nightmare because of cases where it is absent (syntax ambiguity which is solved by a hack in the parser, partly solved by adding the semicolon, but only optionally); not because of cases where it is present (where it is non-ambiguous).
For this reason, several quality projects for Lua highly recommend using the semicolons (actually empty statements) everywhere... except that this empty semicolon must now be accepted after a goto, or a return or after the end of an infinite loop, and after a reachable label (that has "goto" statements point to the label, where the label is in lexical scope from the "goto" statement), even if it is not the common practice of removing them (but only where this is not ambiguous, i.e. not before function calls without any assignment which are the only case allowed of "_expression_ statements").
Yes,it is a nightmare that was introduced by the currification syntax (which is "syntaxic sugar" initially added to Lua, without serious prior discussion about its syntaxic effect).
No such nightmare would have occured if either:
- semicolons were always needed (like in C/C++/Java), or
- were removable by a cleaner syntax, discrimating whitespaces/comments when they contain at least one newline (like in _javascript_/ECMAscript, but this also creates some problems when the code presentation is changed, for refactoring purpose or because the code is to be packed to remove all "unnecessary" whitespaces/comments, because the semicolons then need to be added everywhere a newline was significant).
If we leave aside the problem of code packing (which will be made by bots using true syntaxic parsers), there remains the problem of code refactoring (made by humans which may not see that the newline in Lua is just like any regular whitespace) :
This causes unexpected bugs when the code is changed by humans (e.g. by removing a statement just before a function call statement, or because one user may not see that what "looks like" a function call statement was actually the continuation of a currified function call and then could insert statements in the middle).
