I've embraced a notion of "DEFINITIONAL QUIT"
And there's a split... such that there's a QUIT* function that is basically a THROW to whatever script, module initialization, or console that is running. And then QUIT is a global function that does some work and interpretation to produce a value given to the QUIT* that is relevant in the place where the QUIT was invoked.
QUIT* speaks in the language of values. If you say quit* 0 the calling script will get a literal INTEGER! of 0. If you say quit* 1 then the calling script will get a literal INTEGER! of 1.
QUIT does some interpretation, so that if you say quit 0 it will call quit* ~okay~, giving the calling script a friendly signal of success. If that caller is something like the console, then it will interpret that ~okay~ as a request to give exit code 0 to the shell.
But if you say quit 1 then QUIT interprets that as a request to make a FAILURE! antiform, with the ID nonzero-exit-code. This gets passed to quit*. Your calling script will have to handle that with a TRY or EXCEPT or similar. The console will recognize the error code, pick the integer out of it, and report it to the shell.
How Far Should QUIT Go?
At one time there was a refinement to QUIT, called QUIT:VALUE... which would bypass the processing.
It made explaining QUIT harder. And given that understanding QUIT*'s existence gives people a real leg up on grokking the system, I'd rather people just say quit* arbitrary-value than try to worry about that.
So that's a relief. But it also means that un-starred QUIT could really take any interpretation of its arguments.
First thought was modest things... like LOGIC! ?
Compare with things like:
quit either all [
result = expected
warnings = 0
] [0] [1]
either all [
result = expected
warnings = 0
][
quit 0
][
quit 1
]
Wouldn't it be nice if you could just say:
quit all [
result = expected
warnings = 0
]
This starts to make me think that QUIT passed a TEXT! string could be information about the failure. It could have FAIL-like meaning
quit ["Couldn't find file:" some-file]
That's pretty neat. Combine that with dialected function calls, and you could slip an error-code in there:
quit/5 ["Couldn't find file:" some-file]
(Though it probably shouldn't be a magic number.)
Maybe even kookier things:
quit 5:["Couldn't find file:" some-file]
Just thinking out loud here.
Started Questioning It With VOID
Where I started wondering about "is this going too far" was how to react to VOID.
quit case [
condition1 [...]
condition2 [...]
]
What if none of those cases run and you get a VOID. Is QUIT VOID obviously success... so same as ~okay~? Or is it obviously failure?
The problem being that if QUIT is going to take a NULL and have a false meaning to that, it can't use the <opt> parameter convention to force all parameterization stable unless VOID means also means fail... since <opt> turns into NULL.
I'll make an analogy: FAIL doesn't take VOID, and if it did, it wouldn't mean "oh, nevermind, don't fail"
fail if 1 > 2 ["math is broken"]
print "You wouldn't want this to print just because math isn't broken"
FAIL just doesn't accept VOID. I think there's not much sense in having QUIT accept it, either (although arity-0 quit is legal).
Okay, so if we back out from that... does LOGIC! make sense? Maybe, but...
Custom QUIT Dialecting: The Higher Calling?
Maybe QUIT should just do 0-arg, INTEGER! and FAILURE!?
You'd have to say quit fail "message", but that's more clear than quit "message". (just quitting with a message doesn't necessarily suggest failure).
This leaves the door open for you to define QUIT for your domain... you could have all kinds of dispositions of what to do when you quit. (I've shown dialecting RETURN.)
Unless I can think of a really good generalized feature for QUIT, this seems the smarter route.
I'm on the fence about LOGIC!. What pushes me over the edge in thinking "yes, it should be supported" is the idea that ~okay~ is what calling scripts get when you say just quit or quit 0.
That makes me feel like being able to say quit okay or quit ~okay~ or quit ok makes sense too.
And if you can do that, why not be able to pass a conditional expression?