World: r3wp

PARSE operates on dynamic scope, but many of its constructs are affected 
by the closest thing that REBOL has to real lexical scope: nested 
structures. Basically, the only real lexical scope in REBOL is the 
kind you can get from an unbound LOAD. The rest is faked using "definitional" 
processes. And the definitional process is itself dynamic (though 
it is a one-way process, so its scope isn't bounded).

Right, the main advantage of the definitional approach is, that it 
resembles the lexical case very well, where needed, and only in exceptional 
cases it looks differently

That is true, but not enough - the dynamic transparency proposal 
also has that quality. The main advantage that only definitonal return 
has is that it can do things that dynamic return can't, even with 
transparency. And it does so with almost no added overhead, because 
the functions were getting bound anyway. That is why I support it.

Yes, that looks to me as the main argument to support the definitional 
return as well.

Nevertheless, as you mentioned above, the cost of binding may be 
prohibitive in cases when the block is supposed to be run only once 
(like in case of CATCH), which may indeed be the main reason, why 
to keep dynamic throw.

You don't lose anything that you haven't already lost for other reasons, 
and it is possible (in native code) to build in acceptable workarounds 
for its weaknesses, so there's no significant downside to definitional 
return (except the work Carl would have to do to implement it).

In the case of BREAK (I mean the one used in the DO dialect now), 
the situation is 50:50, since loops would be bound once, done many 
times anyway, making any slow-down % much smaller, and due to the 
fact, that some loops (as you mentioned earlier too), need to bind 
their bodies anyway

The main reason to keep dynamic throw is that you would (practically) 
lose a lot of capabilities if you lost it; the reason you already 
lost those capabilities for functions don't apply to throws, so it 
would be a real loss.

(and, that applies to the CONTINUE case as well)

I don't know how much R3 code you've had to optimize, but I've had 
to optimize it a lot. That BIND/copy overhead is significant. It 
takes a *lot* of loop reps to balance it out, more than most code 
needs to do by something like an order of magnitude. It's not 50:50.

Well, but don't forget about the binding being done anyway, which 
makes the binding time actually negligible

Carl has mused that there might be a faster way to do BIND/copy in 
loops. It would be welcomed.

The binding time is *not* done anyway by all loops. It is only done 
by REPEAT and *EACH, and we now often avoid using those functions 
*because* they rebind. REPEAT and *EACH are mostly used for small 
loop code, because of that binding time *and memory use*, which is 
even more significant than time in a lot of cases.

Code optimized to R3's characteristics is *much* more efficient in 
R3 than code optimized for R2. And it look better too (that was one 
of the reasons for a lot of the native changes).

Well, I do not hesitate to use Foreach or Repeat where appropriate

Nor do I.

But, since we have that many cycle alternatives, the frequency of 
usage of any of them is not too high

I've noticed that FOREACH, FORALL and MAP-EACH are used the most.

In mezzanine functions?

(I do not use Forall)

Though FORSKIP is used a lot too. LOOP, REPEAT and WHILE aren't used 
much anymore, and I can't remember the last time I saw FOR used in 
real code, though I use it a lot in adhoc file management code.

How about the general loop, is there a will to have it as a mezzanine?

you forgot until.... its usually the most practical loop for varying 
lenght loops.

I like it. And yes, I forgot UNTIL. I haven't seen UNTIL used in 
R3 except in text and example code.

All of the loops in R3 are native, so the optimization balance of 
them is different now.

I find While more comfortable, usually, but the fact is, that Until 
does not have some problems While does

I like your general cycle (except the name), and would use it in 
user code if it were available.

yes its nice that all loops are native... this is especially cool 
on  forskip... it was prohibitive in R2...

WHILE's biggest problem afaik is #1519.

I originally called it Cfor, but that name is even less appropriate, 
I guess

could it be called  ITERATE

aha, looks acceptable

Looks good to me. I don't like the word "cycle" for mezzanines, too 
academic (no offence, Ladislav :), and "general" is too long.

I know, "iterate" is a bit academic too, but at least it's one word.

That "general cycle" is the "official" (encyclopedic) name for such 
a cycle, but it does not look short enough for the real use.

, i.e. it is more appropriate in for the documentation purposes, 
than as a function name

Ladislav, Maxim, could you show some support for SELFLESS? Go to 
#1758 and leave comments. Carl changed it to "waiting".

SELFLESS? -> SELFLESS ?

No problem

I did my best to argue for it by doing a thorough ticket and writing 
best-possible-without-it example code for LET and BIND-TO-NEW, to 
show how much it is needed.

I really like LET

especially when you put GET and SET besides it... all of a sudden 
I wondered... well, shoudn't LET have been the very first function 
evaluator  :-D

Yup. I've been meaning to write a LET for years, but this has been 
the first excuse :)

Gregg: thanks for the "inverted programming" notion, I like it a 
lot. (used it in the #1758 comment)

Brian, BTW, there is one reason why to prefer LET instead of CONTEXT: 
CONTEXT always yields the block it reates, while LET could yield 
a result that is wanted more.

I agree, especially when that is what you want more. SELFLESS is 
more comparable to CONTEXT.

err, block: :object, in my post

Q:  is the self word of a context something that can be bound to 
blocks within a method of that object?

did not understand your question probably; did you mean something 
like this?

>> same? 'self first bind [self] make object! [a: 1]
== false

Or, maybe more in the line with what you wrote:

make object! [method: func [block] [bind block self]]