World: r3wp

Yeah, that break thing, I forgot: An interesting thing about PARSE 
was revealed during the course of implementing the parse proposals. 
It turns out that what most people (including me) thought about PARSE 
was wrong. ANY, SOME and WHILE aren't the only loops in PARSE for 
BREAK to break out of: Every rule is a loop. Even rules that don't 
have any iteration or repetition are effectively a LOOP 1. This means 
that while the *scope* of the BREAK operation in PARSE is definitely 
dynamic in its implementation (this also came out in discussions 
with Carl, though it doesn't use the unwind method), it is (afaik) 
impossible to construct a working example of BREAK that demonstrates 
this. I would love it if you could figure out how to write example 
code to prove this, Ladislav, since I've just been taking the author's 
word for it.

It doesn't matter for R2 and R3's implementations of PARSE, but it 
might matter for someone who wants to make a compiler for the PARSE 
dialect (which is at least theoretically possible). That would be 
a really cool project :)

I guess, that it may be implemented dynamically, but, the way it 
is implemented, makes it indiscernible from lexical. And, finally, 
what matters most is not the implementation, but the behaviour.

Dynamic scope and lexical scope have a lot of overlap. Being different 
in kind doesn't necessarily make them different in practice :)

So, if the BREAK in Parse actually always breaks out from the lexically 
closest block containing it, the behaviour is lexical, at least that 
is what I think the definition is about.

Of course, that is what makes it possible to consider changing to 
definitional return. If it was too different in practice, it wouldn't 
be an option, too much code would break and too much of the understanding 
of developers would break too.

...and, the biggest disadvantage of the dynamic return is the opposite 
- the fact, that knowing the lexically closest catching construct 
does not tell you, which construct will be the closest one at run 
time

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 :)