World: r3wp

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

Yup, though that is likely not as good an idea as other words other 
than self. Regular object self binding is really helpful for OOP, 
even class-based OOP.

and since we have full control over the self word, because we are 
supplying/setting it then our class builder could properly bind the 
class methods to our instance selfless context.

idea here is just that self is the accepted rebol term for object 
member setup.

the selfless object would be class and its self would point to the 
instance... something which is impossible with selfish contexts.

hum... nope, it would have to be the other way round.  otherwise 
you can't safely have more than one instance per class.

Yup :)

anyhow... I think that SELFLESS is an enabler.  they allow us to 
evolve the language in specific domains while keeping the standard 
terms in our code.

Added this to the SELFLESS ticket: "The values would not be bound 
to the context."