World: r3wp

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]]

yes that'ts it.

because with SELFLESS it would be interesting!

>> a: context [a: 1]  same? a first bind [self] a
== true

With selfless contexts it wouldn't work. In certain circumstances 
this can be useful.

but if SELFLESS simply ignored the self word, then self would be 
bound to object SELFLESS was called in... which is very nice to allow 
loops which can access contexts.

that does not look right to me at all

Loops in OO code can be helpful :)

aha, maybe I misunderstood again

Ladislav, you are right.
>> a: context [a: 1]  same? a first do bind [self] a
== true

Dammit.
>> a: context [a: 1]  same? a do bind [self] a
== true

Q: would SELFLESS rebind values given with /set  ?

that is what I would expect, but its not defined in your ticket.

though maybe its better if it didn't.

No, it wouldn't rebind the values. For that matter it doesn't bind 
the original words.

It just uses SET semantics for the values.

I am thinking that SELFLESS could be used to build classes if we 
specified self as a word.

since self could be set to another context... it would be interesting 
since 

a  and  self/a  would effectively be different values  :-)