World: r3wp

We actually need that option for both function! and closure! types, 
because of their different contexts. It is easier to add this as 
an option than as different types.

Especially since Carl is the one who suggested options in the first 
place, so we know it's possible to implement.

That's why I said any-function!.

not possible to get accepted as a mezzanine because...not possible 
for a regular programmer to come up with a workaround like this" 
- why, then, was my CLOSURE constructor accepted?

No, it would need two added function types, not just one. And names 
for those types, and names for the wrapper functions that create 
those types, and so on. An option is easier.

We are talking past each other.

That was a backport, Ladislav. R2 has more lax standards. We are 
trying to cut back on that in R3, but R2 is a lost cause.

The disadvantage is that we don't have a function constructor which 
does not rebind return in the function body.

If you want to talk about intimidating R2 functions, look at APPLY 
or MAP-EACH. Neither of those would be accepted for R3.

Agreed, Andreas. I was just saying that a spec option is a better 
solution to that problem than new datatypes.

Yeah, and as I did not suggest new datatypes, I was wondering where 
that came from.

we don't have an any-function! constructor...

Guess I misinterpreted that :(

Which was meant to imply that we have neither a constructor for closure! 
nor for function! nor for any other user-definable function type 
:)

Misleading, though. Sorry for that.

One of the goals of the native changes in R3 is to cut down on the 
need for arcane workarounds in regular REBOL code. For every arcane 
workaround that you might see in a mezzanine, you will see the same 
workaround need to be done over and over again in user code. Usually 
badly. There have been a host of native changes to make regular REBOL 
code easier to write and read and cleaner to look at. We even got 
more of these in the last 3 releases.

For that matter, that is what the call for idioms is for.

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.