On 01.02.22 07:36, Paul King wrote:
Hi Fred,
I think you have discovered a potential short-coming in the compiler.
The intention is to mostly follow Java behavior.
mostly, yes
A "break someLabel" statement should break out of an enclosed
statement having label "someLabel" (A) or the current
for/while/do/switch if no label is given (B). If an unknown label is
given, there should be a compile error (C). Currently, if the label is
known but not in the "Java correct" scope, we are getting (B) instead
of (C). So, it's not actually doing a GOTO "exit" in your example but
is exiting the "for".
int i = 5
for (int j=0; j<2; j++) { break exit }
i += 10
exit:
i += 100
assert i == 115
I do not fully recall what I thought back then how this was supposed to
be useful. As a "break the loop and then goto the given label" it sound
too complicated for anyone who is not used to old programming languages.
Plus the concept is somewhat foreign in itself - to Java. Plus (again)
it is not even working like that!
However, "continue exit" is actually doing a goto to "exit".
Now this was actually intentionally
The code was written before my time, I'll have to dive in further to
work out if this is a feature or bug.
First might be a "bug", second a feature... but none we advertised.
A loop consists basically (simplified too) of a loop-start, loop-body
and loop-end. loop-start or end may contain a condition and based on the
condition you jump to the body or to after the loop-end in the bytecode.
This allows the implementation of do-while, while and for-loops.
Now a break (without label) is a jump "out" of the loop, which means to
after the loop-end. And a continue (without label) is a jump to the
loop-condition in either loop-end or loop-start.
With label a break is to do the same, just that it allows to jump from a
nested to an outer loop-end. Similar for continue.
Since in bytecode this is all flat and scopes do not exist in the same
way, break and continue are actually goto instructions there (in Java too).
So I think the idea back then was to allow at least the continue to work
as a kind of goto. Actually it was the result of the implementation back
then, so idea is maybe too much. I wanted to discuss it, but nobody was
interested in discussing, thus the implementation stayed as is. I do not
remember that part of the code so clearly right now - so not sure if
there is potential for simplification - but to be more like Java, some
checks would have to be added mostly.
bye Jochen
