Personally, I don't think we should support anything other than ldh [c]. The instruction, is only 1 byte and does not take an address input (outside of register c). Supporting alternative syntaxes, such as [ff00+c], misleads that the instruction takes an address input, which it does not.

I favor treating it like how we do rst nowadays. At the parser level, it'd be ld a, [expr + c], and it'd add an assertion that (expr) == 65280.

I favor treating it like how we do rst nowadays. At the parser level, it'd be ld a, [expr + c], and it'd add an assertion that (expr) == 65280.

Yes, that's how it's been ever since the lexer rewrite in 0.4.2. (Prior to that, [$ff00+c] and [$ff00 + c] were their own whole tokens, so you couldn't even do two-space [$ff00 + c] or all-space [ $ff00 + c ] or anything else mildly unusual.)

Personally I'd like it if the parser allowed five-token [ number + c ] -- not the fully-general [ expression + c ]. But that causes a "shift/reduce conflict" as the bison-generated parser cannot tell whether number + starts an expression, which is why we went with fully-general expression support there in the first place (thereby allowing all these weird variants of $ff00 that people don't/shouldn't actually use).

Thanks to the community feedback, here's what I'll probably go with. Still deprecate ld [c] but allow ld [$ff00+c] and ldh [c]. Technically allow (a) the redundant ldh [$ff00+c] and (b) the weird variants ld [65280+c], ld [$ff00+low(bc)], etc; but don't officially document them as allowed, and reserve the "right" to break them somehow later.