Re: Why is break not syntactically required to be the last statement in a block (anymore)?

[Lorenzo Donati <lorenzodonatibz@...>]

On 28/07/2022 20:01, Egor Skriptunoff wrote:
> On Thu, Jul 28, 2022 at 6:44 PM Lorenzo Donati wrote:
>
> > To avoid issues with what you mention, in order to just specify a
> > "static" level, also something like this:
> >
> > break<4>
> >
> > break ::4::
> >
> >   or
> >
> > break @4
> >
> > or whatever other syntax that is easily parseable with no excessive
> > lookahead and no ambiguities
>
> "break 4" syntax is good enough:
> the next statement cannot start with a literal number,
> so only a simple look-ahead is required.
>
> Would the "break 4" target be easy to locate when reading code?
> Absolute location identifiers (such as "goto ::my_break_label::")
> may be more understandable than relative values (such as "break 4").
In some cases, I agree that absolute locations are the clearer solution.
However, there are cases in which when you read an algorithm you don't 
really care where are you jumping to, but that you jump out enough.

Of course you can litter your nested loops with something like


if some_condition then goto BAIL_OUT end


but this code can be completely understood only knowing where the 
BAIL_OUT label is placed. It could be placed at the end of the nested 
loops matrioska structure:


for ...
 for ...
  for...
  end
 end
end
::BAIL_OUT::


But you can't be sure until you check it. And this could be 
annoying/error prone if that nested structure is several editor page 
long (I assume you have a good reason to have such a deeply nested 
structure spanning so much code, and that code cannot be refactored in a 
more readable way avoiding the nesting and maintaining the same efficiency).

OTOH, the statement:

if some_condition then break 3 end

is immediately clear "locally".

Moreover, if the algorithm needs to bail out from only the, say, two 
inner loops, but not the outer one, the syntax is easily understood.
With GOTOs you need additional labels, which may well become a 
maintenance nightmare or source of errors.

With the "break N" syntax you have two source of errors: the break 
statement and the nested loops structure. With "goto" you also add a 
third element: the label position (and its name).

Of course I assume who reads the code already knows the structure of the 
implemented algorithm and just needs to understand the details of the 
implementation, otherwise "break 3" is as obscure as "goto BAIL_OUT".

BTW, it could be useful to have a special value for "bail out of ANY 
loop", e.g. "break 0", regardless of nesting (it could be nice to be 
able to write "break all", but this will introduce a new keyword, so meh!).

Anyway the "break N" feature has a clear advantage: it is a structured 
alternative to "goto" with well understood jump target semantics.