lua-users home
lua-l archive

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

That's also my favorite syntax: using labelled loops is clearer than
inserting a label after the loop, just before any unrelated
instruction. And this fixes the allowed semantics for break<label> and
continue<label> by allowing only to reference a labelled loop (a
for/while/repeat statement), and not random places anywhere in the
code. In addition it is quite simpler to implement for the parser, as
there's never any label defined with forward references. As well, this
allows stricter restrictions about reachable labels (you cannot break
or continue into an inner loop).

So why not labelling loops like

for<label> ... do
   while<label2> ... do
      repeat<label3> ...
         if ... then
      until ...
      continue<label> ...

And not need to support numeric expressions (or even just integer
constants) for "indirect" references of counted loops (this is also
very ugly if you need code refactoring where a single outer loop may
need to be expanded into several nested loops, or where several outer
loops could be compressed into a single loop (by changing the
presentation of iterators); it's not obvious from the number of loops
where you'll effectively go, as well basic refactoring where you would
attempt to replace the inner code of a loop into a separate function
would no longer work as expected.

Now labeled instructions may also be useful for some constructions.
Goto statements are a nightmare in most source codes and should only
be allowed by code generators which can check their validity, not code
written by humans! But code generators may use a specific restricted
dialect of Lua (possibly generating some bytecode directly, but with a
special JIT validator in Lua to perform some validity checks, like
what Java VM or .dotNet are doing) and not requiring to use the normal
Lua parser where "goto" (and optional "labels" before random
statements) are allowed everywhere.

Labels and goto statements are just there for compatibility with
legacy code (where you could not do things efficiently without them)
and not using "strict" validation, but we should be allowed to use Lua
in "strict" mode where they are forbidden, allowing the Lua engine to
perform more optimizations if needed (this will be required if later
there are new object programming concepts enforced, notably for
functional programming: from strict code you could call only code
using strict semantics, and nonstrict code may only be called by using
some sandboxing environment. In strict mode, we could still use
<labeled> loops.

Le jeu. 28 juil. 2022 à 21:17, Lars Müller <> a écrit :
> To throw an alternative syntax in the pot: Labeling loops / blocks. This is how you can continue / exit outer loops in languages like Go or Java: Loops can be labeled with "<name>: <loop>" and continue/break take an optional name:
> foo: for ... do
>     while ... do
>         continue foo
>     end
> end
> bar: for ... do
>     repeat
>         break bar
>     until ...
> end
> As I recall it, this is the right explanation for the current situation.
> FWIW, I'd still like "break" to be improved to manage multi-level breaks, even as syntactic sugar for an hidden goto+label definition.
> I don't despise GOTOs, but I think that using a goto to exit a multilevel loop is very error prone, especially if the label is far away from the goto, which is not so rare a case when algorithm with 3 or 4 nested loops are used (and this is really the case where you would find a multilevel break really useful).
> Semantically a multilevel break is a very clear program action, which should be understandable at the break site ("I want to exit multiloop").
> Using a goto at that same point must rely on "meta" information to convey the same meaning to the code reader, such as a comment or a descriptive label, but these may be misleading (possibly ambiguous: "goto start", to exit a multiloop).
> I would welcome a syntax like "break 4", to exit four loop levels.
> WRT the parser lookahead capabilities, maybe an uglier syntax could avoid excessive lookahead, like "break<4>". After all with Lua 5.4 and const/to-be-closed vars the syntax has already been uglified a lot, IMHO.
> An alternative would be sort of like "relative jumps" (breaks are essentially that):
> goto +1 = break (jumps just after the end of current loop body)
> goto +2 = break 2 (jumps just after the end of the innermost enclosing loop body)
> This could be generalized to implement a "continue" statement (multilevel too):
> goto -1 = continue (jumps at the end of current loop body)
> goto -2 = continue 2 (jumps at the end of the innermost enclosing loop)
> (and maybe someone could come up with a syntax that's nicer than in these ramblings of mine :-).