Vaporizing Failed Conditionals In REDUCE

[hostilefork]

@hostilefork

min: null
max: _

<<BUNCH OF CODE THAT MUST SET MIN AND MAY OR MAY NOT SET MAX>>

uparse data [repeat (:[min max]) rule]

The reason I didn't say (min: ~) or (min: ~overwrite-me~) is because I wanted min to be "middlingly ornery". So I wanted to use it in expressions like any [min, ...] but I didn't want it to be able to be used as an opt out intention. This is the weird zone that NULL occupies and we're making the most of it.

Under this understanding...I'd be displeased if that turned into [repeat ([_]) rule], because I'd have liked to have been told about the issue.

I feel like a bit of a broken record revisiting all these old posts from when NULL was the only non-valued state, that was trying to do double duty as both "soft failure" and "opt out".

But this is yet another solved case. Nowadays NULL doesn't vaporize in REDUCE (it's an error), but VOID does vanish. And you can convert NULL to void with MAYBE if that's what you want to do.

Ever since introducing this distinction, I haven't really seen problems with vaporizing voids...and the NULL erroring has caught many issues. The abstract potential for problems with void opting out of REDUCE is there, but I haven't seen any problems. It feels especially solid now that these behaviors are specific to constructs like REDUCE, and the evaluator doesn't vaporize VOID...just the much rarer NIHIL.