[REBOL] Re: Help me, Obi Reb Kenobi, you're my only hope!
From: lmecir:mbox:vol:cz at: 3-Sep-2002 9:32
I thank Romano for his finding and try to comprise out knowledge about Rebol
We can classify errors by the interpreter behaviour to three groups:
1) crashes (errors, that crash the interpreter). I think, that such errors
shouldn't exist at all. (Opinions?)
1a) Native function crashes, like SAME? crash, where it is enough to modify
the function - my IDENTICAL? doesn't crash. (I don't understand, why this
crash still persists?!)
1b) "Self-modifying" code crashes - there is only one recipe to "cure"
this - rewrite the interpreter, i.e. use a slightly different interpretation
strategy. An example of such crash is:
a: func [x] 
a a: 1
This crash has already been "cured", but the behaviour still is strange -
compare it to the Freebell interpreter's behaviour, where the above code
isn't self-modifying at all! These crashes can be eliminated - e.g. using a
strategy I proposed. (Opinions?)
2) Errors are representable by Rebol values which don't crash the
2a) Errors, that cannot be caught. Examples are THROW ERRORS caused by
RETURN or EXIT out of function, THROW out of a catch block or BREAK out of a
loop. I think, that the interpreter should be modified to be able to catch
2b) "Normal" errors, that can be caught by the TRY function (or my
Another possibility is to classify errors by aggressivity of their
evaluation. Almost every error is second class like:
type? make error! "" ; == error!
, which is OK, but:
type? (make error! "")
** User Error:
** Near: make error! ""
doesn't yield the same result as the former expression, which is an
interpreter quirk. I propose to change all errors to first class, which
type? (make error! "") ; == error!
III) Romano revealed, that some errors are third class, like:
type? make error! [throw no-loop]
** Throw Error: Nothing to break
** Near: type? make error! [throw no-loop]
, which is a bigger quirk than above.
Opposite opinions welcome