[Proposal] Please skip empty statements after return

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[Proposal] Please skip empty statements after return

Soni "They/Them" L.
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.

Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Please skip empty statements after return

Jim-2
On Mon, Jun 24, 2019 at 01:10:03AM -0300, Soni "They/Them" L. wrote:

> 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.

Maybe it has to do with the used encoding/formating ? :D


Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Please skip empty statements after return

Soni "They/Them" L.


On 2019-06-24 4:45 p.m., Jim wrote:

> On Mon, Jun 24, 2019 at 01:10:03AM -0300, Soni "They/Them" L. wrote:
> > 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.
>
> Maybe it has to do with the used encoding/formating ? :D
>
>

my email client replaced those with non-breaking spaces I guess. ignore
that, they were plain spaces when I sent them. they aren't strictly
needed tho.

Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Please skip empty statements after return

Jim-2
On Mon, Jun 24, 2019 at 05:06:59PM -0300, Soni "They/Them" L. wrote:
>> Maybe it has to do with the used encoding/formating ? :D

> my email client replaced those with non-breaking spaces I guess. ignore
> that, they were plain spaces when I sent them.
> they aren't strictly needed tho.

just kidding.
it looked too tempting to brush it aside.


Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Please skip empty statements after return

Philippe Verdy
In reply to this post by Soni "They/Them" L.
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 à 06:10, Soni "They/Them" L. <[hidden email]> a écrit :
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.