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

[REBOL] Re: Tools for Rebol Coders

From: rotenca:telvia:it at: 8-Jan-2002 1:08

Hi Ladislav and Joel, <Joel>
> Based on the documented (RCUG) meaning of RETURN, I agree > with Ladislav that both examples demonstrate bugs in REBOL.
I think that the set-word return is a bug (already reported to Feedback), but useful to extend to set-word binding preserving conversions. I agree with Ladislav: we need a conversion function for any-words which be binding-trasparent. <Joel>
> The verbiage and examples lead me to conclude that the only > difference between explicitly RETURNing a value and implicitly > returning the last value is that RETURN may be used to exit > "prematurely" at any point within the function. Nowhere that > I can find does the documentation state (nor imply) that
About Return error!, i think it is a documented feature. The error exception happens only when the error! is evaluated. To bypass or delay the evaluation, you must pass it at a function: Return is a function, ergo... The point here is that Return is a function, not an end-before-the-time of block. The difference is also evident when you think at [throw] which throw only Return not every end of block. 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. <Ladislav>
>My POV is, that the first sample's function A should behave exactly like the >first sample's function B. (it is contained in my REP). If you see it like >me, send a request to feedback, please. If you don't, can you tell me your >preference?
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? 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]. --- Ciao Romano