lua-users home
lua-l archive

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

On 05/08/2021 18:59, Coda Highland wrote:
On Thu, Aug 5, 2021 at 9:56 AM Viacheslav Usov <> wrote:

On Thu, Aug 5, 2021 at 3:26 PM Roberto Ierusalimschy
<> wrote:

It is a source of syntax ambiguity. Compare
    print("unreachable code")

    print("unreachable code")

Thank you for the explanation.

Breaks followed that rule to keep open the possibility of labeled
breaks.  After goto, we gave up the idea of labeled breaks, but now I
particularly would prefer that all of them (break/return/goto) followed
this rule.

Without goto, any statements after transfer of control are
unreachable, and it is best for clarity not to have them. So the rule
makes perfect sense in this case.

With goto, well, they are reachable if there is a label statement just
after the transfer of control.

What speaks against relaxing the current restriction on the return
statement, so that it must be the last statement in its block, or it
must be immediately followed by a label statement?


Think about it more practically. How WOULD you write code using goto that
would put a label in that position? All of the ways that come to mind would
be better served with other code structures.

IIRC one of the reasons GOTOs where introduced was to support automatic code generators (especially for finite state machines).

In that case the option of using other code structures could not be practical, since the code generator would have to be more complex and generate loops using explicit loop structures instead of gotos.

Therefore adding restrictions on label placements could be detrimental to simpler code generators.

Specifically, keep in mind that a goto that isn't the last statement of a
block is necessarily an unconditional goto -- if it were conditional, it
would be inside an if block. (If there's code after the goto in that if
block, the goto is still unconditional from the perspective of that code.)
So there are only two possibilities:

(1) An unconditional forward jump. This means you're skipping over code,
unconditionally. That either means that code could be removed or commented
out, or that there would be a label immediately following the goto
statement for use by another goto. Sub-possibilities:
(1a) That other goto is earlier in the code. This is effectively
implementing an if/else and could be replaced with that.
(1b) That other goto is later in the code. This is effectively implementing
a special-case first iteration of a loop and could be replaced with a loop.
(2) An unconditional backward jump. This is just an uglier way of writing a
loop and should be written as such.

Conditional gotos are way more useful -- the typical argument for
supporting goto is to short-circuit out of a nested structure, and those
are necessarily conditional.

/s/ Adam


-- Lorenzo