World: r3wp

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."

Because that would be presumptuous and usually wrong :)

yes, like aggressive block evaluation  :-)

remember that mistake?  ;-)

Not really, but that sounds like a bad one. Got to go now, later! 
:)

I'm realizing that I coudn't really implement what I want.  because 
the selfless? AFAIK isn't a state flag, its the actuall fact of having 
self inside.   the code would still be subject to object's  limitiations 
on the access of self, which means you can't set it.

does context/make object!  simply protect/hide the self word when 
it creates the context?

You are able to make me feel so ignorant reading your discussion...

Maxim, the self word in object contexts doesn't actually exist. The 
word self that you see is a keyword of the BIND function. A selfless 
context has a flag in it (that you can't set with MAKE object!) that 
tells BIND to not set that keyword.

So if a selfless object actually has a real self field in it, it 
is still selfless.
>> selfless? foreach self [1] [bind? 'self]
== true
>> foreach self [1] [bind? 'self]
== make object! [
    self: 1
]

You can add a self field to a selfless context and it can be used 
like any other field. That is the whole point to selfless contexts.

Added an alternative BIND/CREATE to the #1758

Regarding the above "self issue", I am still a bit at odds, whether 
it wouldn't be preferable to have it as in R2, where all contexts 
were selfless, objects just containing the word 'self.

I must be somewhat "dense" not understanding the benefits of the 
change.

To make myself clear, I do not object against the word 'self being 
protected..., the only thing I mind about is the "keywordness" of 
the word.

When I think about it, it is funny, since I neither object against 
the fact, that the 'self word is a keyword of the object specification 
dialect, as it was in R2.

Benefits of the change:
- No overhead for the self field.

- No more blowing the stack accidentally because of circular references, 
or other annoying bugs.
- No problems with printing.
- No more settable self security hole.

Also, in R2 self is a predefined word in the object context, not 
a keyword. It's a keyword in R3.

If you like you can think of self as being a binding artifact in 
R3. At least it's not as much a keyword as 'export and 'hidden in 
module bodies :)

{- No more blowing the stack accidentally because of circular references, 
or other annoying bugs.} - interpreter bugs, if not corrected, they 
may be still "lurking"
{ - No problems with printing} - the same case

{- No more settable self security hole.} - that is not related to 
"keywordness", just to "protectedness"

{in R2 self is a predefined word in the object context, not a keyword.} 
- 'self is a keyword of the object specification dialect. Actually, 
it is a keyword of the object spec dialect in R3 as well. The introduction 
of the selfless contexts cured the problem of making 'self a keyword 
of other dialects, like FOREACH.

So, the main advantage to stay is the "no overhead for the self field"

coming at the price of needing the "sefless flag" for all contexts

(not that bad, I admit)

But, the second price is how to explain such property to beginners

On the other hand, we probably don't have to say to beginers that 
"there is no spoon" (ah, pardon, self), it suffices to say "self 
is protected".

The article

http://www.rebol.net/wiki/Exception_proposals

updated. Changes:

- LET function
- SELFLESS function
- readabilty improved

(the BIND-TO-NEW function was removed, which enhances source readability 
in my opinion)

Ladislav, those disadvantages applied to the self field. Of course 
there is other code that still has those disadvantages. That doesn't 
make R2's self field have them any less.

Agreed on the readability improvements of using the LET function. 
You didn't get the whole SELFLESS function.

And you might want to get into the habit of using CAUSE-ERROR, since 
it makes your code look simpler and hides the differences between 
R2 and R3 errors.

I just realized something: You don't need word references to have 
the full power of PARSE, you can use circular direct references instead. 
Of course you can't specify those structures in loadable source, 
you have to construct them dynamically, and you can't BIND them so 
you stiff can't use definitional scope for its operations. But it 
is at least in theory possible to match the patterns that finite 
nested rules can't match by using circular structures.

stiff -> still

Really awkward to do so though, and you can't just see the structure 
in source so it is harder for many people to understand.

Overall, the best and most efficient strategy for dealing with the 
problems of circular structures is to not use them, or to accept 
that they will have problems. Having *every* object have a circular 
reference in it was a bad idea because of that. Using word references 
instead of direct references is another way to deal with the problem 
though.

Word references - yes, that is fine

Added a REBOL-code almost-equivalent to the SELFLESS ticket, based 
on your trick, and a couple minor bug fixed. Rewrote LET to use the 
same trick. Strangely enough, the LET version has less overhead than 
the SELFLESS version of the same trick, especially in the error handling 
code. The LET function is now efficient enough to be acceptable as 
a mezzanine function, though not yet efficient enough to be used 
to implement low-level mezzanine functions.

You got the arguments to your error wrong :(

No big deal though.

We could really use a native LET or SELFLESS - either would do, actually, 
and could be used to implement the other.

Yes, "your error" - which one?

aha, yjou mean the implementation of SELFLESS

Yup. Compare the arguments to CAUSE-ERROR in the ticket version of 
SELFLESS.

Your second argument should be 'words instead of 'any-word.