World: r3wp

There, 3 and 4 have been tweaked to be a little better. 3 (and 4 
transitively) could use another couple disadvantages listed, but 
the ones there may be sufficient.

Swapped 5 and 6 in the page, and reworded them accordingly. Now the 
differences between them are more clear. Swap "5" and "6" when reading 
back to the conversation above between Andreas and me. I now prefer 
5, though would accept 6.

ok, I've read the whole exceptions document and a few (very old!) 
tickets at least 3 times now.


I'll start by being honest and saying that some of this is going 
a bit deep into some details and I'm pretty sure that I'm not graping 
all implications.  The background for all the discussion hasn't "sinked 
in" yet, so its a bit hard to be totally conclusive about my evaluation 
thus far.


this being said... when I arrived at 5, i.e. "Definitional return 
only, with an option to not redefine RETURN and EXIT", it suddently 
starts making sense overall.  6. seems to be redundant and maybe 
even harmfull if we keep THROW dynamic.  This is scaled with CC#1744 
"fixed" and a wider use of THROW, encouraged, since it now allows 
custom escape/exception modeling by non guru-level Rebolers (and 
by guru I mean one of 3-4 rebolers on the earth... maybe not even 
including Carl ;-).


this means, that return does one thing, throw does another.  they 
become two completely different things, clear and conscice in all 
code.


the only real issue I have is that we seem to loose return in parse, 
 but if we keep throw dynamic, then that is moot, and we can just 
use THROW instead.  In fact, woudn't that be preferable, since its 
more accurate?  we are pre-empting the parse return and providing 
our own... which is what throw should be doing ... its more consistent 
overall.


so go ahead rip my arguments appart... it will only help me understand 
this completely.  :-)

You missed one thing: To make PARSE rules task-safe, we should be 
moving them into function blocks anyways. And recursion-safe, for 
some really obscure tricks that the new PARSE IF operation lets us 
do, but the task-safe thing will come up more often.

that's true

So the "return from PARSE rules" thing will only be a problem for 
R2-style code. Once we do all the other tricks to make it R3-style, 
we get proper behavior for free :)

Oh, and BREAK/return works in the parens in PARSE rules in R3 - it's 
a drop-in replacement for most uses of RETURN in those same parens.

Also, PARSE has its own RETURN operation that acts like BREAK/return.

The RETURN changes for functions won't affect any of that.

Which reminds me, BREAK will likely still have to be dynamic because 
of the PARSE support - PARSE rules aren't nested. No definitional 
BREAK (or CONTINUE). Must add this to the page later.

PARSE rules aren't *always or even usually* nested

Don't forget Ladislav's USE-RULE for PARSE.

Here is Ladislav's Exception proposals page: http://www.rebol.net/wiki/Exception_proposals
Everybody who has a proposal chime in!

I made some notes here and there, but can't seem to make time to 
really think deeply about all this. Consider these thoughts lightly 
---


The FOREACH trick is clever, but it makes me wonder if things are 
a bit inverted. Should there be a core binding func that does that 
service *for* FOREACH and other funcs that need that behavior.

Even though it's temporary, should this:
    if set-word? first words
be this:
    if find words set-word!

(behavior alterations and 'values being modified ignored due to temp 
status of func)


TRY/EXCEPT doesn't read particularly well to me, because 'except 
sounds like you're leaving something out, rather than catching the 
error.

Re: "things are a little bit inverted" - yes, I think so, now, the 
problem may be, that Carl hesitated (maybe still does?) to give us 
such "low level stuff"

The if set-word? first words was rather an error from me, as you 
noticec.

I also think that Carl hesitates to give us lower-level constructs. 
 This has been the historic case, BUT, now that a lot of people are 
actively contributing and actually producing working concepts, ports, 
prototypes and stuff, Carl is slowly realizing how usefull it is 
for *him* to open up on the lower levels of REBOL.


the exception/return/throw discusission going on is a good example 
of this active participation of the community.  Obviously, not everyone 
is willing or able to participate, but in such deep discussions, 
there is rarelly a huge mass of people anyways.

I really hope that brian, Ladislav and Carl will get together in 
a possibly heated discussion about all of this.  the difference in 
mindsets is a perfect setup to get the best overall solution.

my only desire in all of this discussion is that trhow/catch is kept 
dynamic and that /name be implemented with context matching and that 
catch doesn't handle throw/name.

(note that they need not be *implemented* as dynamic returns, but 
they should function as such)

catch doesn't handle throw/name

 - you could always use catch/name [...] 'none versus throw/name 'none, 
 if you did not want to catch other throw/name calls, so this is still 
 just "cosmetic", and surely not serious in any sense I can imagine.

For an even more interesting thing - a definitional catch/throw pair 
(which can be ported to R2) see the Exception_proposals article. 
Advantage: you do not have to use any name, yet, only the right throw 
is caught.

yes that is interesting, but /name is usefull for some code patterns 
like named exceptions.


thing is that currently, catch  withouth /name does make that impossible 
afaik.  if we built a mezz which re-threw them, afaik, that would 
change the context and thus make context sensing impossible... though 
your skill in this type of low-level manipulations might (will? ;) 
prove me wrong.

:-'

Named exceptions are child's play for definitional catch/throw

ok, what would be the advantage of using a dynamic catch/throw, if 
any?

it is already available, that is about all

but, sure, you may get a different answer if you ask some fans of 
dynamic constructs

ok, so its just less complicated to build mezz code with dynamic 
returns, but that means dropping a few possibilities with definitional 
ones?

its just less complicated to build mezz code with dynamic returns 
- who told you that?

the opposite is true

its just my bumbling appraisal so far, because it seems to me that 
you don't need to redefine and contextualize everything within your 
mezz code... but I do say I'm novice at this subject.  (I'm trying 
hard to completely "get" it/

ok, so its easier cause its managed by the core, but that means you 
can't play around with it within the mezz... is that a better appraisal?

hence, "harder" to adapt, but "easier" out-of-the-box?

Compare this:


dynamic: func [block i] [append block 'i if i > 0 [dynamic block 
i - 1] block]


definitional: closure [block i] [append block 'i if i > 0 [definitional 
block i - 1] block]

probe dynamic [] 3

probe definitional [] 3

Which one is harder?

At the first sight, none is, I bet, but at the second one:

probe reduce dynamic [] 3

probe reduce definitional [] 3

The answer is different

So, which one is harder?

Btw, for DYNAMIC you will get different answers depending on whether 
you are running it in R2 or in R3

R3 
>> probe reduce dynamic [] 3
** Script error: i word is not bound to a context
** Where: reduce
** Near: reduce dynamic [i i i i] 3

>> probe reduce definitional [] 3
[3 2 1 0]
== [3 2 1 0]

So, any favourite?

I'm trying to understand what's going on in R3...

(in the dynamic version)

I could show you a similar example with CATCH/THROW, but it would 
require more code

Dynamic variables in R3: they are "not bound to a context" when the 
function is not running.

(that formulation is a bit unfortunate, meaning, that I would not 
have used it, but, in essence, it means: "don't ask what the value 
of dynamic variable is, when the function is not running")

Nevertheless, you can insert something like


if i = 0 [print mold block] to see the result, and compare that to 
the result in R2

wow, I think you've just illustrated a big part of the issue and 
you should add the above to your exceptions page.

it does a better job at explaining the underlying issue than the 
R3 error page IMHO.