[prev in list] [next in list] [prev in thread] [next in thread]
List: lua-l
Subject: Re: [Proposal] Please skip empty statements after return
From: Philippe Verdy <verdy_p () wanadoo ! fr>
Date: 2019-06-24 22:28:20
Message-ID: CAGa7JC0tFLGwd0fUxjhSnFKrJev+uyxZvKpsgQ7BYyxLQLzP_A () mail ! gmail ! com
[Download RAW message or body]
the first one could be valid, if the (reachable) label had some code to
execute outside the label itself. But because there's no explicit return
statement at that point, it just returns nil (or an empty ordered list of
values, which is equivalent). All the question is about which instructions
can follow a return in the same block, and abviously an empty statement or
no statement at all after an explicit return but before the end of block is
functionnaly equivalent :
if the end of block is the main block os a function, it is exactly like if
there was two return statements, one explicit and another implicit, the
second one (insert implicitly just before "end" being normally unreachable,
and eliminated silently by the compiler as it is merged with the previous
explicit one).
Now comes the question of empty statements: it's something that the
compiler could eliminate siliently as well, not by the syntax itself, but
by the fact that there's no code emitted after the code already emited for
the explicit return.
But if one wants empty statements there, it should work: the semicolon at
end of a return is already optional and generating an empty statement, but
nothing syntaxically prevents from generating several empty statements.
That remarks also applies to any statement you put after a goto statement:
it can also have an empty statement with the (optional) final semilon.
So after any goto or return, accept any number of mpty statements, and a
**reachable** label (independantly of whever that label is then followed or
not by other statements, empty or not).
Being a ** reachable** label means that the syntax above points to it, or
that any reachable code below (and in scope) includes a backward goto
statement to it.
The "reachable" condition cannot be determined by the syntax but by code
flow analysis, which should then detect dead code and signal unreachable
code (I'm not sure it should be a syntax error, it could just be a warning,
because the compielr may elminate that dead code directly, and silently, or
would just emit a warning in a compiler with a debug mode (such as in an
IDE).
Such dead code may occur because of automatic code generators (e.g. using
templates). In C/C++ they just generate warnings if one wants to detect
them and has activated the correct warning level in the compiler options.
The same could apply to Lua. But then it's no longer to the syntaxic parser
to signal them and break which is in fact harmless in most cases
Lua already has some syntaxic "noop" features which is intended for code
generators, such as the trailing comma in lists of initilizers for table
contructors. I see no reason for not accepting also empty statements with
the same goal.
Le lun. 24 juin 2019 =C3=A0 06:10, Soni "They/Them" L. <fakedme@gmail.com> =
a
=C3=A9crit :
> Consider these currently invalid programs: (they are not equivalent.
> that's intended.)
>
> -- 1.lua
> function foo(x, y)
> if x then
> goto bye
> end
> return y
> ::bye::
> end
>
> -- 2.lua
> function foo(y)
> ;; function bar(x)
> ;;;; if x then
> ;;;;;; print(y)
> ;;;; end
> ;;;; return x, y
> ;; end
> ;; return bar
> end
>
> I wish the worked.
>
>
[Attachment #3 (text/html)]
<div dir="ltr">the first one could be valid, if the (reachable) label had some code \
to execute outside the label itself. But because there's no explicit return \
statement at that point, it just returns nil (or an empty ordered list of values, \
which is equivalent). All the question is about which instructions can follow a \
return in the same block, and abviously an empty statement or no statement at all \
after an explicit return but before the end of block is functionnaly equivalent \
:<div>if the end of block is the main block os a function, it is exactly like if \
there was two return statements, one explicit and another implicit, the second one \
(insert implicitly just before "end" being normally unreachable, and \
eliminated silently by the compiler as it is merged with the previous explicit \
one).</div><div>Now comes the question of empty statements: it's something that \
the compiler could eliminate siliently as well, not by the syntax itself, but by the \
fact that there's no code emitted after the code already emited for the explicit \
return.</div><div>But if one wants empty statements there, it should work: the \
semicolon at end of a return is already optional and generating an empty statement, \
but nothing syntaxically prevents from generating several empty \
statements.</div><div>That remarks also applies to any statement you put after a goto \
statement: it can also have an empty statement with the (optional) final \
semilon.</div><div>So after any goto or return, accept any number of mpty statements, \
and a **reachable** label (independantly of whever that label is then followed or not \
by other statements, empty or not).</div><div>Being a ** reachable** label means that \
the syntax above points to it, or that any reachable code below (and in scope) \
includes a backward goto statement to it.</div><div><br></div><div>The \
"reachable" condition cannot be determined by the syntax but by code flow \
analysis, which should then detect dead code and signal unreachable code (I'm not \
sure it should be a syntax error, it could just be a warning, because the compielr \
may elminate that dead code directly, and silently, or would just emit a warning in a \
compiler with a debug mode (such as in an IDE).</div><div><br></div><div>Such dead \
code may occur because of automatic code generators (e.g. using templates). In C/C++ \
they just generate warnings if one wants to detect them and has activated the correct \
warning level in the compiler options. The same could apply to Lua. But then it's \
no longer to the syntaxic parser to signal them and break which is in fact harmless \
in most cases</div><div><br></div><div>Lua already has some syntaxic "noop" \
features which is intended for code generators, such as the trailing comma in lists \
of initilizers for table contructors. I see no reason for not accepting also empty \
statements with the same goal.</div></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">Le lun. 24 juin 2019 Ã 06:10, Soni "They/Them" L. \
<<a href="mailto:fakedme@gmail.com">fakedme@gmail.com</a>> a écrit \
:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Consider these \
currently invalid programs: (they are not equivalent. <br> that's intended.)<br>
<br>
-- 1.lua<br>
function foo(x, y)<br>
if x then<br>
goto bye<br>
end<br>
return y<br>
::bye::<br>
end<br>
<br>
-- 2.lua<br>
function foo(y)<br>
;; function bar(x)<br>
;;;; if x then<br>
;;;;;; print(y)<br>
;;;; end<br>
;;;; return x, y<br>
;; end<br>
;; return bar<br>
end<br>
<br>
I wish the worked.<br>
<br>
</blockquote></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic