[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
