World: r3wp

You categorically ruled ou that there is code where the user of BIND 
does not know (or care) whether SELF is of importance. Anything that 
follows after that is only begging the question.

In any case, adding a BIND/self refinement would certainly be an 
improvement over the current situation.

REPEAT et al doesn't need to have 'self be bound in its code block. 
But if a reference to the object created by REPEAT persists after 
the function ends, any subsequent use of that object would either 
need to use its 'self, or not see its 'self at all. REPEAT *can't* 
know which. If the object is used by any code that needs to see 'self 
(like BIND/self) then that 'self absolutely must be there, because 
the otherwise the 'self references in the code block would retain 
the bindings they had before, which will likely be encapsulated code 
in a module (this is R3, remember). If the object doesn't need to 
use 'self, *it can't*: The reflectors, the formatting code, and BIND 
without the 'self trick can't tell if there is a 'self there or not, 
so if it's not there it *would make no difference whatsoever*. So 
all you are proposing is to make a datatype that doesn't contain 
a hidden 'self field, but which can *only* be used in cases where 
there not being a hidden 'self field is something that doesn't affect 
it at all.

If you make the loops and closures create a non-object that doesn't 
have a 'self field, all that you have done is make those objects 
not usable where the existence of the hidden 'self field matters 
in the slightest. And for code that doesn't use the 'self field, 
it doesn't *see* the 'self field either, and can't tell that it is 
there or not. So you have added nothing, and taken away something 
that might be useful for no good reason. It's a bad idea.

Yes, I like Ladislav's BIND/self proposal. The /self option would 
be used where 'self matters, and otherwise not used. Good balance 
to that.

I am not sure, whether I understand my proposal ;-) What does it 
mean for code like:

repeat self 4 [...]

?

You can do that now: The hidden 'self is overriden, and the 'self 
trick doesn't apply. Like this:
; Current behavior: 
>> a: construct [] 
== make object! [ 
] 
>> append a [self: 1] 
== make object! [ 
self: 1 
] 
>> do bind [self] a 
== 1 
>> protect/hide in a 'self 
== self 
>> do bind [self] a 
== make object! [ 
] 
>> same? a do bind [self] a 
== true

See, the override 'self can be modified, isn't hidden until you hide 
it, and easily overrides the hidden 'self like any other hidden field.

And if we BIND/no-self on a object with an overriden 'self field 
we can still see it. And if the override 'self is hidden, BIND/self 
doesn't unhide it, it inly unhides the original 'self.

And UNPROTECT will unprotect an override 'self field, even though 
it refuses to unprotect the original 'self field.

I don't think you can unhide a field at all, let alone 'self.

And you can't override a field unless it's hidden.

Ok, so let me try to recap this huge discussion. In R2 we had context! 
and object! as two separate types, although context! was hidden from 
users and only accessible by converting it to object! - conversion 
which was broken because it did not create 'self that object! requires. 
So, instead of fixing this by making context! accessible, it was 
decided to remove context! altogether and add 'self to all contexts, 
and add a bunch of exception refinements to BIND to work around all 
the problems that come out of that?

Do I need to say "KISS" here?

Nope. You missed a bit of the R3 part. But that is a good characterisation 
of how bad things got for R2.

The part you missed for R3 was that there were no exception refinements 
added to BIND to deal with this at all - they weren't needed. And 
we are proposing to add *one* refinement to BIND, out of a choice 
of two.

So given that, you can now say "KISS", and realize that we did.

The rest of the conversation was discussion of subtleties and implications, 
mostly as an object lesson.

Oh, and the stack-relative contexts of the function! type in R3 to 
make functions more safe for recursion and multitasking.

why not to fix context! vs object! discrepancy, at least for R3, 
instead of coming with other "workarounds"? :-)

We already fixed this for R3.

Question for Carl - after 2.7.8.  - are we finally back to R3? :-)

EXTRACT fix posted for R3 (and R2 as well). Good catch, Sunanda :)

The R3 version is a lot faster because of the native loops :)

Brian, I don't agree that a half-keyword SELF is the simplest way 
to solve the problem.

That's true. The simplest way to solve the problem would be to not 
have 'self at all, even for objects. Simplest isn't always best.

But if you are comparing to having separate object! and context! 
types, that would move all of the inherent complexity of the situation 
out into the mezzanine code, where dealing with complexity is the 
most expensive. And object! would still need all of the current 'self 
tricks to make it safe to use, so there's no real gain. At least 
with R3's solution the inherent complexity of the situation is encapsulated 
and dealt with.

Finally, the only reason we still need 'self is because you can't 
use path notation with the results of a function (BIND? in this case). 
So you have to have the result assigned to a word to be easily able 
to do the tricks one can do with path notation. Thus the only reason 
we need 'self is for convenience, so that the end developer doesn't 
have to constantly reinvent their own 'self references, badly.

When I say "badly", we come to the only thing you can't do with a 
roll-your-own 'self: The UNPROTECT exception. UNPROTECT won't unprotect 
'self: it refuses to. And it will unprotect any other protected word 
(future security restrictions allowing). So the one thing you can't 
fake is a persistent word reference to the object that you can't 
modify (the way you can in R2). At least not without writing your 
own UNPROTECT.

Admittedly, you can't do the BIND unhiding trick either, but if you 
roll your own (let's call it 'this), the 'this reference can go in 
another context and you will get the same advantages. Or you can 
bind all the code that needs to refer to 'this before you hide 'this, 
so you won't need to unhide 'this later (normally impossible).

Now keep in mind that the stuff that is done to hide 'self and prevent 
its modification will be there regardless of whether we have 'self: 
It's just ordinary PROTECT and PROTECT/hide. So getting rid of 'self 
doesn't get rid of the code used to implement it.

Brian... after more than 10 years of writing REBOL programs... I 
can't imagine how what you're talking about is useful in any way. 
I guess YMMV.

I wrote bug #1549 to describe what is the problem I am having with 
'self handling in R3

irreparable bugs

 isn't descriptive enough. Please add a comment explaining what the 
 bugs in question are, and why you think they are "irreparable", when 
 you link tickets that have known methods that can be used to solve 
 them, including one that is already fixed. And why DO-IN, a function 
 that only exists in the example code of the ticket, not in R3, matters. 
 If you don't do this *in the ticket or its comments* then the ticket 
 will need to be dismissed.

I mean, I can guess based on the discussion here, but I won't be 
the one deciding that ticket. And the one who will wasn't involved 
in this discussion and wouldn't have any idea what you are talking 
about.

#1552 added

Added more detail to the description of #1552.

After Beijing Olympics, China government blocks more and more web 
sites. Google Blogspot is one of them. Since most of Chinese people 
cannot visit my REBOL blog on Blogspot, so I decided to create a 
new REBOL blog in Sina.com.cn, which is China-local. The new blog 
will be dedicated to (1) People in China (2) Programming Beginners 
(3) Students in High-schools. It's been created for 4 days. 8 Lessons 
have been published. Check it out here http://blog.sina.com.cn/yingerpeifang
 BTW, "YingErPeiFang" means "Baby Formula".

Also, I think R3 Beta is on its way. It's time for me to talk about 
REBOL in China.

Cool!

How about a while-either function

while either [do this condition while true][do this condition while 
false] none would exit out of the loop

Just those three values? How would you like it to react to conditions 
that are other values than logic! or none?

Paul, can you give some actual scenarios you want it for?

If a block evaluates to anything other than that then it is true.

Can't think of anything actual Gregg that I'm working on but when 
stuff like that exists people tend to come up with scenarios after 
awhile.

When is the next R3 alpha being rolled out ?

Graham, it's been a long journey.

Carl, how is the next host/extension (with view as a plugin) comming 
along?

we need status update blog ;-)