Potentially influencing this, is that I've rewritten the inner guts of UPARSE such that definitional errors are used to signal a combinator failure...not "pure" NULL.
In the original concept, I'd been playing on the difference between null isotopes and pure NULL--to distinguish when a combinator "actually returned null" vs. when it wanted to indicate a mismatched rule failure. But using a definitional error is a cleaner solution, that really allows a combinator to synthesize any value.
-
It could mean that TRY makes more sense. It could leverage the same error, and any infix operations that work with it (e.g. if an ELSE-like construct reacts to the same error as TRY).
-
Though it might make less sense... as combinators that raise definitional errors are already sort of being TRY'd and having their errors defused... then moving on to the next alternate.
- So the TRY has in effect already happened, and you're asking it to take an additional disposition of not moving on to the next alternate.