Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Re: Tools for Rebol Coders

From: lmecir:mbox:vol:cz at: 8-Jan-2002 17:40

Hi Romano, <<Romano>> (...) I could agree with Ladislav when he asks a change in the actual error! specific. But i do not think that the actual implementation of Return error! is a bug. <</Romano>> For me it doesn't matter whether it is a bug or not. I just prefer and propose a more reasonable behaviour. <<Romano>> About Ladislav's Rep, i want to ask him: 0) The by-default-disabled error! is an object! or a error! datatype? 1) When an error is Fired, can it be catched by try? 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? <</Romano>> 0) I prefer it to be an ERROR! datatype value. 1) I think, that this sample code can illustrate what I mean: fire: func [[catch] error [error!]] [ throw error ] error? try [fire make error! "my-error"] fire make error! "my-error" 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. <<Romano>> I think that a big problem about the implementation of error and Return is its interaction with functions attributes [catch] and [] (which throw a return only if is argument is an error!). It is strange, undocumented or buggy (as you like) and all these things constrain to make "strange" things with third of functions to construct trasparent functions (like in Ladislav's transp-func]. <</Romano>> 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. Cheers Ladislav