Resurrecting the "IF" Combinator... as WHEN

[hostilefork]

@hostilefork

I don't think it's a good idea to make substitions via GET-GROUP! (or whatever comes to replace it) silently continue on NULL. If you forgot to set a variable that was supposed to hold something (as in rule above), that should give you an error. But I don't think you should have to write :(maybe even? num)

Having spent some time with this in practice, I'm wondering if it's doing more harm than good to not allowing NULL in GET-GROUP! substitutions to mean "rule doesn't match".

It's particularly painful with WHILE:

while :(mode = 'read) [some chunk]

; vs.

while when (mode = 'read) [some chunk]

I am uncertain that the safety advantage is really worth it. NULL variables aren't unset variables. Having the state mean "don't keep going" seems useful enough to outweigh the occasional accident of "I meant to have a rule here but forgot it" case.

So I'm changing splicing to be null tolerant (well, tolerant in the sense that it won't abruptly fail, but triggers a rule mismatch).

The bigger issue is that leading colon for this is likely not going to be what it is, given the new general semantics of "optionality" that leading colon implies. So I'm thinking that's going to be doubled groups again.

while ((mode = 'read)) [some chunk]