lua-users home
lua-l archive

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

On Fri, Aug 6, 2021, 6:45 AM Lorenzo Donati <> wrote:
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
>>>     return;
>>>     print("unreachable code")
>>> with
>>>     return
>>>     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?
>> Cheers,
>> V.
> 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.

It's not about label placement, it's about goto placement. If you really need it, `do goto foo end` works. (This is even explicitly called out in PiL.)

But if you're implementing a DFA in Lua, then I've always liked implementing each state as a function and returning the new state as a reference to the function implementing it. Using a table of state functions and returning a key is also common.

Sure, goto avoids the need to manage stack frames, so that might be a small performance benefit. But that's why there's an officially sanctioned workaround.

/s/ Adam