Feature request: `FOR / REPT ... ELSE` like Python

[ISSOtm]

Like it says on the tin.

REPT 1
    print "Hello "
ELSE
    println "world!"
ENDR

REPT 1
    BREAK
ELSE
    FAIL "Not reached!"
ENDR

[Rangi42]

Reusing the ELSE keyword might not be feasible given how conditionals and loops are captured/skipped, and also people sometimes get confused about what for ... else means in Python (thinking the else clause runs of the for loop does not complete, when it's the opposite).

So I think we should add a new keyword, ideally with an R suffix to match ENDR and because that's much less likely to collide with user identifiers than a single English word. Maybe "THENR"?

[ISSOtm]

I don't like this “suffix” syntax, I think it just looks weird. So let me throw around some ideas:

REPT 42
   break
ENDR AND
   ; ...
ENDC ; or ENDR? idk

REPT 42
    break
AND THEN ; We already reserve the `AND` keyword 😏 but we could make this `AND_THEN` if we wanted to
   ; ...
ENDR ; Keeps the mental model of “the entire loop construct ends at `ENDR`

REPT 42
    break
IF !BREAK ; Funky but maybe more explicit?
    ; ...
ENDR

REPT 42
    break
FINALLY ; ☕️
    ; ...
ENDR

[Rangi42]

ENDR AND is not practical to lex. Anything could go in that whitespace, e.g. ENDR /* many lines of comment */ AND. And if we required a single space, that's just adding a ENDR_AND keyword with extra complexity.

AND THEN is not "capturable"/"skippable", since and is an instruction. Also "then" is a single English word, IIRC already used for some label/macro, and the whole point is to avoid introducing new keywords that easily clash with identifiers.

IF !BREAK is, again, suffering from being a token with a space in it, and clashing with if/elif/else/endc capturing/skipping.

FINALLY is self-explanatory, which is nice, but unfortunately is an English word, and also lacks a clear connection to REPT/FOR.

The "suffix" syntax is what we're already used to for decades from END* keywords.

[ISSOtm]

The suffix syntax is something I heavily disagree with, especially as people keep writing it uppercase and it's very easy to mistake ENDC and ENDR when skimming; I have half a mind (and growing) to make 2.0 use braces instead, so don't test me >:) The suffixes also suck because there is no visual separation between END and the suffix. END_LOOP, END_IF, even ENDIF would be much better. I buy the “we've been used to this for decades” as much as we have for column-1 semantics: not anymore since 0.5.0 😉

Your point about whitespace is not wrong, but we can work around that by disallowing block comments there. (Who in their right mind would, anyway?) I know it's not ideal, but I'm offering those designs anyway because I think it's worth thinking about before implementation details come into the picture, i.e. to decide what we should aim for.

This still leaves AND_THEN and FINALLY, thus.

[Rangi42]

I'd strongly prefer to just add a new COMPOUND_KEYWORD, instead of repurposing two existing keywords with new special restrictions around what's allowed to go in between them. It would have to lex as a T_COMPOUND_KEYWORD anyway, the special handling would be at the character level, and that's just more special casing than it's worth to avoid introducing one new keyword, IMO.

Is there some way that "AND_THEN" or "FINALLY" could be tweaked to associate them with REPT/FOR loops? Like, "LOOP_THEN" or "LOOP_FINALLY"?

We could also just close this feature request. It may be a bad sign that Python's the only major language to have bothered with it. (Some templating languages have a feature like Jinja's for ... else or Jade's each ... else or Hugo's range ... else, but those all do the opposite of Python: the else clause runs if the for body never ran at all.)

The workaround is not too onerous, and apparently less ambiguous than any clause we could attach:

DEF broke = 0
REPT 1
    print "Hello "
ENDR
IF !broke
    println "world!"
ENDR

DEF broke = 0
REPT 1
    DEF broke = 1
    BREAK
ENDR
IF !broke
    FAIL "Not reached!"
ENDR

---

Snipping the broader "breaking change" discussion apart:

The column-1 behavior was surprising and inconvenient enough to be worth the necessary breakage of requiring a leading DEF keyword. Separate END* keywords are not something that keeps tripping people up. Plus, changing RGBASM to be a brace-styled language is visually drastic enough that if you really want to, you're definitely calling it rgbds-ng or rgbds-crab or issogbds or something, not "gbdev's rgbds v2.0". :P

Personally I'm happy that we got the important breaking changes out of the way in time for v1.0, and am not looking forward to something equally disruptive. Maybe 2.0 could even just do some "technically-breaking" stuff like changes to the object file format (AFAIK even additional features to it count as breaking, since the revision increments and you have to rebuild everything and we have to release a new rgbobj). But EQUS expansion in particular is a "future breaking change" we've talked about that I know would be a pain to deal with if it happens.

[ISSOtm]

My vote also goes towards AND_THEN or FINALLY, but at least we-ve steel-man'd that argument.

I would argue against the workaround for a few reasons:

• It requires naming broke, and we all know Naming Things is hard. (Plus, the usual scoping issues mean that encapsulating this somehow is limited.)
• You also need to purge broke afterwards!
• It's several extra lines that do not seem to me like they explicit the intent very well, so overall the logic's expression is muddied significantly.

---

As for whether brace syntax is drastic, I'd point out that you are biased here by your intensive usage of macros and such conditionals as of late, whereas most code out there would incur few changes from that. (Consider that most of pokecrystal, for example, is straight assembly code with some defs, despite assembling to an entire large game. I could tokei the macros/ directory vs. the rest to pull up some numbers, but I don't feel that it'd be meaningful.)

In the code I've written recently (e.g. gb-vwf, fortISSimO, etc.), I have written far more assembly than meta-programming, despite being one of the most experienced RGBASM meta-programmers.

[Rangi42]

"FINALLY" has the same sort of incorrect implications as "ELSE" -- users would probably expect FINALLY to always execute, like in a try {} catch() {} finally {} block -- so if we add this feature, let's use "AND_THEN" or some variation. (Or perhaps "AND_CONTINUE", since "continue" is more associated with loops than conditionals, and it's like the opposite of "break".)

However, I'd still lean toward not implementing this. Even though I'm fond of it in Python. I just don't think it comes up often enough. I've needed to write a few "while" loops, using the workaround of rept $7fff_ffff :: if !cond :: break :: endc :: ... :: endr (or a tighter upper bound than $7fff_ffff, but still), but never this. Despite having macros to do asm-level conditionals and loops (m_if and m_loop), dynamic text compression, Pokémon trainer data, etc. I don't see this pattern being used in your recent LADX text-wrapping macros either (there's a break but no boolean-flag else-clause workaround).

---

Re: braces, we have a lot of begin/end keyword pairs: if/endc conditionals, rept/endr loops, macro/endm macros, section/endsection sections, load/endl blocks, union/endu unions. Daid's GB.HLA, I believe, uses braces consistently for all of those -- it definitely does for #SECTION {}s. That is a level of dramatic change where I'd consider the end result to be not RGBDS any more. (Of course, having multiple good choices for SM83 assemblers, each with their own design opinions, is not a bad thing!) But we should probably continue that discussion in an rsgbds issue, or elsewhere.

[Rangi42]

Oh, how about "NOBREAK" or "NOTBREAK"? (Got the idea from https://stackoverflow.com/questions/9979970/why-does-python-use-else-after-for-and-while-loops/9979985#9979985, which suggested completed or afterBreak.)

[Rangi42]

We agree that "UNLESS_BREAK" is a decent keyword for this feature.