There's a sort of fundamental question about what REDUCE should do about NULLs:
>> reduce [1 if false [<vaporized>] 2]
== ???
It can't put NULL in the slots of the reduced block. So does it throw the NULL out, raise an error, or put voids or blanks in those positions?
Historically I'd tried adding refinements like REDUCE/TRY that attempted to take care of this situation...but there's a question of how many of these you want (and how to deal with multiple refinements that contradict each other). It felt unclean.
But with the help of predicates, we have a generic option:
>> reduce .try [1 if false [<vaporized>] 2]
== [1 _ 2] ; TRY turns NULL to blank
>> reduce .identity [1 if false [<vaporized>] 2]
== [1 2] ; we could say identity is "it was NULL and I meant it"
>> reduce .non.null [1 if false [<vaporized>] 2]
** Script Error: NON wasn't expecting NULL for its VALUE argument
What I'd propose is that the .non.null case be the default behavior. So the other choices would be a way of overriding that conservative handling that "just errored".
I've been toying with the idea that a lone dot be a synonym for identity. Which would make a clean way in general for "undoing" any work that a default predicate does to protect you, and get the "raw" result...such as the dissolving behavior here:
>> reduce . [1 if false [<vaporized>] 2]
== [1 2]
It's an interesting idea, in any case. This would be most useful if the system is conservative about noticing error conditions by default--as above--and you'd be turning off those protections like NON NULL.
But...what about voidify?
TRY has a nice name. VOIDIFY isn't as nice.
>> reduce .voidify [1 if false [<vaporized>] 2]
== [1 #[void] 2]
Is there some better conceptual name for "if something is null, make it void...otherwise pass it through"? You're saying "I want a value here, even if it's a bad one". REIFY wouldn't be particularly good since in most contexts we'd say that BLANK! is the "reified" version of NULL.
Anyway, wanted to introduce the concept of REDUCE predicates...and figured I'd mention this naming issue while I was at it.