World: r3wp

We can backport stuff from R3 to R2, but what we can't backport is 
simplicity :(

Btw, Ladislav, thanks again for the CLOSURE constructor. If you hadn't 
come up with that great a solution then R2 likely wouldn't have gotten 
closures at all, and none of the other fake datatypes would have 
made it in either, which would have been a real tragedy if we missed 
out on the typeset! stuff.

If I did not came with CLOSURE, not even R3 would have gotten it, 
I bet

True, but you notice that R3 got it as native. We are trying to hide 
complexity.

Strangely enough, when I backported CLOSURE to R2 I had forgotten 
that you had written a version, but what I came up with ended up 
being the same code, exactly. So I attribute it to you through my 
unconscious :)

As an additional advantage, the meaning and expected behavior of 
'''return''' and '''exit''' from code blocks is clear with dynamic 
return, since dynamic return is defined in relation to the flow of 
calls to functions rather than in terms of lexical scoping.

That is highly debatable.

Especially if already using lexical scoping terminology, there's 
nothing that makes dynamic scoping instrinsically more clear than 
lexical scoping. And even when limiting this discussion to REBOL, 
where lexical scope is only faked, that does not make the concept 
in any way less "clear" than it's non-faked dynamically scoped counterpart.

It is clear *once you accept the idea of dynamic scope*, which is 
an inherent part of the semantics of all dynamic escape functions. 
And that limitation is listed as a disadvantage in the same model.

Disadvantage: "Some people seem to question or have trouble understanding 
dynamic return as a concept, let alone its benefits."

It's a *real* disadvantage.

Just got done with the style makeover and rewording of some of the 
models based on the misunderstandings above.

So to sum up. Advantage: dynamic scoping is more clear. Disadvantage: 
dyanmic scoping is less clear.

One scoping model is more clear. Two scoping models is less clear. 
Refresh the page.

Both scoping models are part of REBOL. So my summary still stands.

I find it more confusing to understand how REBOL works when I let 
myself think it really has lexical scoping. It is much more clear 
when i realize that it doesn't, not really.

The downside to adding definitional scoping of returns is that it 
enhances the illusion of lexical scoping, which enhances the confusion.

Or reduces the generall mess caused by too much dynamic scope.

Definitional scope is a a major part of what makes REBOL usable at 
all. Like it or not.

But there are too many upsides to definitional return to ignore. 
So if it makes return less useful, at least it makes it easier.

I prefer the "Definitional return with an option to not redefine 
RETURN and EXIT, dynamic return as a fallback" model because it is 
the most useful. But I would be willing to accept the "Definitional 
return with an option to not redefine RETURN and EXIT, no dynamic 
return" model if it becomes the community consensus - it would mean 
fewer bug reports, at least from users unfamiliar with REBOL, particularly 
R2.

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.