lua-users home
lua-l archive

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

On the contrary, Roberto's proposal is the "break" we know from other languages, and not a "goto" at all.

For what it's worth, I would support a "break label" being allowed after any "do", and labeled "break" statements.  I could take or leave unlabeled breaks.  The Java spec provides an example of specifying the semantics of labels and breaks[1], and the elements of such a spec are things like:

- "scope" of a label (inside the block, presumably)
- whether labels are allowed to shadow same-named labels (no, in Java)
- what a "break" with no label does (breaks nearest loop or switch, which must exist)
- interaction with try/finally (n/a to Lua, but I love how the Java spec thinks of everything)

So basically, the semantics seem pretty easy, and the analogy with other languages is strong.

-- David

[1] see e.g.

On Thu, Jan 27, 2011 at 9:05 AM, Hans van der Meer <> wrote:
In my opinion this kind of use could best be characterized with the keyword "goto" not with "break". The keyword "break" in my ears sounds more like "break away" or "break out of". So, why not plainly call it "goto" here? We should not fear the ghost of Edsger Dijkstra coming from his grave to haunt us for it (see his famous article "GOTO considered harmful").

Hans van der Meer

On 27 jan 2011, at 17:42, Roberto Ierusalimschy wrote:

>>> I believe that this "break N" will kill code readability as sure as
>>> "goto" would.
>> Yeah, I would get lost pretty quick!  Named labels would help [...]
> If that could save Steve's right arm, we like the idea of break with
> labels.
> In Lua, we cannot have traditional labels, because the syntax "foo:"
> already has a different meaning. Instead, a simple syntax would be to
> add labels only to "do end" blocks, for instance like this:
>  do :label:
>    ...
>  end
> Then, a continue could be written like here:
>  while cond do
>    do :process_item:
>                    break :process_item:
>    end
>  end
> There are several details that could change (other mark instead
> of colons, whether the label after break needs marks, whether an
> optional [or mandatory] label could be added after the corresponding
> 'end', etc.), but the basic idea would not change much.
> -- Roberto