Hi Ladislav, >> 2) Have you thought about throw err: try [...] ? Don't we need a sort of >> fire-throw? >> 3) Normally when an error is throw, it is catchable without try. What >> happens in your proposal?
> 2) There are two possible answers to this question. The first one is: there > is no need to introduce a new function. Even now the [catch]/throw differs > from catch/throw (the former pair works only for errors and "fires" them, > the latter works for any Rebol value and doesn't necessarily fire errors). > The second one is, that because the mechanisms differ a lot, they should be > distinguishable. It is a matter of preference only. > > 3) I think, that the catch/throw mechanism (which differs from > [catch]/throw) should work as it does now. And how to throw and fire an error? If we do in your proposal: throw make error! "my-error" we do not fire our error! and if there is no catch, we end with an ** Throw Error: No catch for throw: "my-error" ** Near: throw make error! "my-error" if there is a catch we have not error at all. instead of (not catched) ** Throw Error: ** User Error: my-error ** Near: throw make error! "my-error" or (catched and evaluated) ** User Error: my-error ** Near: throw make error! "my-error" we must always use the [catch] attribute to fire-throw the error? And if the throw is a script file which some code do, instead of a sub func, what happens? > There is a need to have transparent functions in Rebol. (They are useful for > new control functions creation.) My implementation is only a hack, because > it is a self-modifying code, which is ugly IMHO. The only reason, why it is > so ugly, is the behaviour of Rebol errors, which unreasonably complicates > things. I agree, but I think that the function attributes implementation requires a deep revision. --- Ciao Romano -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
