We need a name for “arity-1 IF”. This is the thing that turns falsey things into NULL, but passes through truthy things.
It’s really, really tempting to call it… IF
>> if 1 = 2 ;-- null >> if 1 = 1 == #[true] >> if <whatever> == <whatever>
You’d have to couple it with something else like a THEN to use it in the traditional way. That introduces some annoyance, like where would you put the THEN?
if x = 10 then [ ... ] else [ ... ] if x = 10 then [...] else [...]
So it’s a terrible idea…or is there another angle here?
Well, let’s back up a second. I mentioned we’re going to need this arity-1 construct one way or another… but I didn’t say there wasn’t still going to be an arity-2 form of IF.
Imagine we renamed today’s “arity-2 IF” to “WHEN”. So these would be equivalent:
if x = 2 then [print "x is two"] when x = 2 [print "x is two"]
Putting those two side by side,
if x = 2 [print "x is two"] starts to feel incomplete, and WHEN sounds like a merging (if you say “ifthen” real fast it sounds like “when”).
Something here feels like it couldn’t be the other way around. When you think of a small atomic box that just does one thing… giving the super short word that duty has a fair amount of draw.
IF/THEN/ELSE seem like they go together
If your language has an IF, and a THEN, and an ELSE… I think the natural assumption would be that you would put the THEN after the condition of the IF.
But that’s not today’s IF. You can use THEN with an IF should you want to…but you’ll be adding more code after a branch that already ran:
if 1 = 1 [ ... code runs ... ] then [ ... more code to run since last branch ran... ]
So you’d use THEN with a CASE or SWITCH, but not today’s IF…but that feels weird.
Arity-1 IF would correct this schematic. And wouldn’t it be easy to frame it as “WHEN is like an IF with the THEN built-in”?
PARSE’s IF is arity-1
PARSE’s IF just takes a condition. It confused me, and has been a source of confusion for others.
Previously I’d suggested making PARSE’s IF consistent as arity-2. But the consistency could go the other way as well, if both were arity-1.
It deepens the illusion
A big part of my affinity for the Rebol design space is how garden-variety the language can often look on the surface, when it’s working in a much stranger way…with that strange mechanic affording a lot of degrees of freedom in compositionality.
Having IF be a “vaporizer of falsey things” is a good trick and takes this composability further.
>> if 1 = 2 else [print "what's not to love?"] what's not to love?
The possibilities are getting kind of mind-boggling. Earlier in Ren-C there was a version of IF called IF? which would either run the branch or not, but return the truth or falsehood of the condition–not what the branch evaluated to. With arity-1 IF you can pass through the condition’s truthy or falseyness by using ALSO:
>> if <truthy> also [print "Running" <discarded>] Running == <truthy> >> if 1 > 2 also [print "Running" <discarded>] ;-- null
ALSO is like a THEN that throws away its result, passing through the condition. So there you have it, an IF construct that evaluates to its condition (if truthy) or null. Wild, huh?
So like I say, I don’t know what to call this, if it’s not IF
Maybe everyone would ignore it and use WHEN? I don’t know. I imagine I’d probably use a mixture.
But the case looks solid to me. This feels like what IF needs to be.