World: r3wp

There are real learning and semantic advantages to just going with 
one return model. We just need to make the limitations of whatever 
model we choose easy for regular programmers to workaround if necessary, 
and pick the defaults well so the workarounds won't need to be specified 
as often. The last model satisfies all of those at the expense of 
losing the benefits of dynamic return, and the next to last doesn't 
even lose those, though it does lose some simplicity. Given that 
the remaining benefits of dynamic return can be restored by keeping 
THROW dynamic and fixing the THROW/name bugs, I'm willing to part 
with dynamic return and get back the simplicity.

Removed all superfluous "and exit" references from the doc.

And the misleading


Making definitional return optional means that this option would 
need to be specified in the code that calls the functions that would 
benefit from it, rather than necessarily in the functions themselves.

comment is still in there.

If you write a USE using the definitional return option it is transparent 
to both dynamic and (foreign) definitional returns. The caller of 
USE can therefore decide freely whether to use dynamic or definitional 
return in a code block passed to USE.

You need to move and reword that statement, not remove it. Most of 
it still applies, and all of it applies to the other variant of that 
model.

If anything, it only applies to the other variant of the model (which 
is utterly useless anyway).

Agreed. But don't delete stuff that needs moving, move it.

I didn't delete it. I asked what is meant.

Oh, I missed the "is still in there" part. I'll reword.

Definitional return functions which do not catch dynamic return require 
no cooperation from the caller.

Definitional return functions which _do_ catch dynamic return, require 
cooperation from the caller.

And of course, requiring cooperating from the caller makes the whole 
endeavour useless.

That phrase might be left over from when those two interpretations 
were one. But both of those models are fairly useless, for the reasons 
given. All of the other models are preferable.

Only one is really useless.

Namely "Dynamic return with a definitional return option". It only 
solves the issue by requiring pervasive cooperation. Which, in reality, 
is of course no solution.

It really is debatable which is the worst of the two, but they are 
both the worst of the lot. Even pure definitional is better. It's 
because definitional is an option in those two, not the default.

In the first model you have a clear separation of concerns: mezzanine-level 
functions handling foreign code must use definitional return. Callers 
need not care.

In the second model, callers must use definitional return as well. 
Which makes it worse.

And in the other models, callers need care even less. Particularly 
the first one and the last two - pure definitional is not much better.

I am talking about models 3 and 4 if you number them from the top.

Right. So 1, 5 and 6 are the easiest to use, 2 is the simplest, 3 
is the most confusing, and 4 adds being useless to being confusing.

5 of ill-specified at the moment as well.

4 being useless and as confusing as 3 of course makes 4 the most 
confusing.

All of the ones that have two return models are confusing, but at 
least 5 has an option that is useful and consistent. But 6 would 
be preferred to 5 just because it's simpler.

3 would be less confusing if it didn't use the return: option to 
specify definitional return. The conflated option with return type 
is part of what makes it confusing, and the rest comes from bad option 
naming and having the interactions between the two semantic models 
be less clear. 4 is a little less confusing because RETURN is more 
consistent, but it is also less useful for the same reason.

If given a choice I would prefer only a single return type, dynamic 
or definitional. Definitional would be better, but we could work 
with either, as long as they have their version of the [throw] option. 
That means 6 or 1.

4 adds nothing to the discussion (and at least one advantage is wrong, 
which is irrelevant as 4 is irrelevant itself).

3 has a few advantages listed which are at least on the borderline 
to being wrong. That obviously hampers the discussion of 3.

Make that: "3 has a _dis_advantage listed, which is borderline wrong."

No, I'm sure the advantages are wrong too, moreso than the disadvantages.

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)