 |
lua-l archive |
|
|
||
|
On 05/08/2021 18:59, Coda Highland wrote:
On Thu, Aug 5, 2021 at 9:56 AM Viacheslav Usov <via.usov@gmail.com> wrote:On Thu, Aug 5, 2021 at 3:26 PM Roberto Ierusalimschy <roberto@inf.puc-rio.br> 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.
Specifically, keep in mind that a goto that isn't the last statement of a block is necessarily an unconditional goto -- if it were conditional, it would be inside an if block. (If there's code after the goto in that if block, the goto is still unconditional from the perspective of that code.) So there are only two possibilities: (1) An unconditional forward jump. This means you're skipping over code, unconditionally. That either means that code could be removed or commented out, or that there would be a label immediately following the goto statement for use by another goto. Sub-possibilities: (1a) That other goto is earlier in the code. This is effectively implementing an if/else and could be replaced with that. (1b) That other goto is later in the code. This is effectively implementing a special-case first iteration of a loop and could be replaced with a loop. (2) An unconditional backward jump. This is just an uglier way of writing a loop and should be written as such. Conditional gotos are way more useful -- the typical argument for supporting goto is to short-circuit out of a nested structure, and those are necessarily conditional. /s/ Adam
Cheers! -- Lorenzo