I Had A Thought...
(me? a thought? I know, you're shocked.) 
I was looking at this:
is-rebol: did parse filename [... any [%.reb %.r3 %.r]]
And I thought to myself "aw shucks, that won't work in this modern world, where PARSE returns a FAILURE!..."
Then I thought: well, hell. what do we really have to gain by not letting FAILURE! count as falsey, as far as DID is concerned?
For that matter... what if DID was willing to say ~null~ for GHOST! , and ~okay~ for empty pack?
This would make DID a kind of universal "did the branch run, did the parse succeed" kind of operator.
I don't think (?) this should be extended to NOT. The reasoning is that if you consider NOT an inversion of conditional testing, then you wouldn't want it having an answer for GHOST!--because it's neither true nor false (think of how ANY and ALL discard ghosts). Also, ANY and ALL would "elevate a FAILURE! to an error". NOT probably fits in that logical sphere.
But DID has the possibility to bend that, and become more powerful.
And its complement, DIDN'T actually becomes useful... as NOT DID (vs. DID NOT). By running the NOT after the DID, you get its FAILURE!-and-VOID-defusing behavior.
(Note that this makes DID and DIDN'T the prefix tests for what drives THEN and ELSE...!)
1 Like
Well... almost... because ELSE doesn't currently run if you have a definitional error.
But maybe it should?
Let's Think About: TRANSCODE
TRANSCODE:NEXT returns NULL if it's at the end of the input.
But if TRANSCODE:NEXT returns a FAILURE!, that means there was some sort of syntax problem or otherwise.
If you write:
item: transcode:next data else [
...
]
I'd guess probably you're expecting that ELSE to mean "nothing left to transcode", not "nothing left to transcode -or- there was a syntax error".
I think we can finesse this, by saying that ELSE will pass errors to the branch...but it won't disarm them.
So if you don't want the ELSE to panic on a failure, it has to say:
item: transcode:next data else (^e -> [
...
])
You have to have an argument-taking branch, which is able to accept a meta-parameter that takes FAILURE!. If not, it panics.
Then DID and DIDN'T can validly be called the conditions for THEN and ELSE, without ELSE automatically squashing failures.
It just means you can't say:
blah blah else [
...
] except e -> [
...
]
But who was going to say that anyway?
Well, I had been doing it, occasionally. 
But let's go back to my example:
item: transcode:next data else [
...
]
I said: "I'd guess probably you're expecting that ELSE to mean "nothing left to transcode", not "nothing left to transcode -or- there was a syntax error".
But hey...now if you do mean that, you can say it.
item: transcode:next data else (^e -> [
...
])
And I think that's probably more clear than ELSE...EXCEPT was for this intent.
Only thing is you have to DISARM the error to pick fields out of it (I'm not sure it's a good idea to allow you to say ^e.id, which is why EXCEPT disarms the error it passes you).
DISARM of variables may get easier in particular, with disarm $error... and we see a good reason here to be null-tolerant with disarming.
1 Like