Le lun. 1 juil. 2019 à 22:13, Jim <sysinit@yandex.com
<mailto:sysinit@yandex.com>> a écrit :
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).
