There's a snazzy new potential for giving more informative messages / logs from failed parses... which means we now have a more interesting option than we might have had before.
Imagine something like:
>> parse "aaa" [some "a" some "b"] ** Error: SOME requires at least one match ** Where: [some "a" \\ some "b" \\] ; Note: this failure can be intercepted by TRY, EXCEPT, ATTEMPT
It can't be perfect unless it maintains some kind of large error tree that accumulates the list of all the reasons it decided to fail, so you might have to be in a debugging mode to ask it to give you a bigger diagnostic. But we can build it now with the participation of the combinators themselves.
But not only this, we could open up the full spectrum of return values. Right now if your parse returns NULL, it has to be contorted into a null isotope to avoid accidentally cuing an ELSE. Similar contortions for void, blank, and logic false.
result: parse block rules except e -> [print "Got an error", return] ; If you got here, you know result is good ; Even if it was a purposefully returned NULL, etc.
There'd be some way to rig this up without using enfix. I might make things more lax about letting you assign error isotopes, because the isotope will bubble through and cause a problem anyway. So you could write something like:
if fail? result: parse block rules [ print "You have a failure, use ^result to get it" ]
If you were willing to collapse failure down to a NULL or somesuch, or didn't even care about the result, you could just TRY it.
try parse block rules
Too Good Not To Be The Default
Of course you'll be able to reskin it however you like for the R3C's or R3Chius out there. But I think this looks like a perfect convergence to put in the box.
Errors aren't going to be that interesting on day one, but it's good to point the ship in the right direction.