World: r3wp

Why would that break bind?

Because even if we made BIND not do the 'self trick by default, we 
would still *need* to add the /self option, and that option would 
*need* to have a 'self field to do the trick with, *every time*.

, and, the solution you mention is broken, without any hope that 
all the bugs will be cured, the more tricks you implement, the deeper 
you descend into the trouble

While I'm not even sure that we would still need /self, I can't see 
where the problem is. BIND/self simply won't work on context!s

Because otherwise every code block we are binding with BIND/self 
would leak references to whatever binding 'self had already.

You have to assume that the 'self trick needs to be able to work 
with every "context" that you pass to BIND, even if BIND doesn't 
do the trick by default. Because the trick is necessary for a lot 
of code. And leaked 'self references can be a security hole, allowing 
access to otherwise encapsulated code.

like the DO-IN-CONTEXT function - actually, I assumed, that there 
are two programmers: one implementing the other function, and the 
other implementing te DO-IN-CONTEXT function. Their functions will 
cooperate only if no tricks are played

Ah, but you were also assuming that BIND doesn't do or depend on 
the 'self trick. Try the function with BIND/self.

Make sure that DO-IN-CONTEXT uses BIND/self, depends on it, requires 
it. Then pass in a "context" created by a loop function.

It's all well and good to say that the current BIND does the 'self 
trick and you don't like that. But there is a lot of code that depends 
on that trick, so if you don't want to do it for your code, you better 
make that an option (perhaps the default one).

that code is scripts, modules, objects?

there is a lot of code that depends on that trick

 - Not R2 code of course. R2 breaks code that depends on 'self existing.

Where is the problem in doing bind/self for object! contexts and 
bind/no-self for context! contexts?

Andreas, yes, those. TO-MODULE would break utterly, for instance, 
no recovery possible, if BIND accepted contexts that didn't have 
'self.

There is no problem with not doing the 'self trick if you don't want 
to. The problem would be if you *can't* do the 'self trick with any 
indefinite-extent context that exists, and you would run into that 
problem if it was possible to make an indefinite-extent context without 
the special 'self field.

Btw, I felt uneasy when the first time I saw that code :

a-function: func [block [block!]] [ 
repeat i 1 [do-in-context block 'i] 
] 

do-in-context: func [block [block!] context [word! object!]] [do 
bind block context]

Now i know why. It's a serpentine way for simply doing:
>> repeat i 1 block

Erf :)

Why would that be a problem? Simply don't accept context!s wherever 
you can't handle them?

Sure, that's what is done with function! contexts after the function 
returns. And one of the functions that can't handle them is BIND.

Fine, but this is precisely about BIND acception two different types 
of contexts and determining by their type wether if should do the 
self trick or not.

accepting*

whether*, it*

It's a serpentine way for simply doing:

 - actually, it is not, just a hint: the code is perfectly OK, and 
 it works in my programs. The main difference between the code and 
 my production code is, that the A-FUNCTION and the DO-IN-CONTEXT 
 function are more complicated (actually doing useful things, the 
 code above is useful only for the demonstration purpose).

The unfamous "real use case" syndrom is back :)

Don't you see, if BIND/self is the only way to see the 'self word 
at all, and that word is otherwise not visible, and BIND/self would 
require the existence of that word, then there is no point in having 
a separate datatype. The only code that could possible be affected 
by the existence or not of a 'self field could not possibly be used 
with that type, and all other code wouldn't be able to tell the difference.

Brian, I guess we are missing each others point here.

so what Steeve, do you want to prove, that I did not use a real code 
and shorten it so, that the problem is still visible?

What Ladislav and I am suggesting is an _alternative_ to /self or 
/no-self. If we had separate datatypes, those refinements would not 
be needed at all.

So what you are asking for is a separate datatype that is like object!, 
except indistinguishable from it is any code that would accept it.

More like map!, I guess, but yes.

It's an alternative that wouldn't work: We'd still need /self or 
/no-self. For that matter, BIND has that option already, internally. 
It can be used by native code only, for now.

Why would we need that?

Use context!s internally, wherever you are currently using object!s 
with bind/no-self

The suggestion to add /self or /no-self to BIND is only a suggestion 
to make a proven, already existing, already used internal option 
externally visible.

I agree about everything but the "proven".

Proven to exist (by bug#447).

I don't see the point to another datatype which is *indistinguishable 
from object by all code that would accept it*. The only code that 
wouldn't accept it is BIND/self (the current BIND behavior). And 
BIND/self is the only way to see the 'self field at all - otherwise 
it basically is not there.

The point is that we would have a clean way to refer to an environment 
which is not conflated with an object.

And it's not indistinguishable from all code accepting it; it makes 
a big difference to code that uses BIND.

And finally, you still don't see that this only makes sense as a 
combined proposal with adapting BIND to predicate behaviour on the 
type of context.

But no reason to - there would be no difference that you could detect. 
If you don't use BIND/self, you can't get access to the 'self word 
at all. So if you can't get access to the word, why would it matter 
if tit's there?

So it's really about: context! + object! + bind without /self or 
/no-self

And if that all matters is a question about how you assume typical 
BIND code to look like. Ladislav's point (at least as far as I understand 
it, Ladislav please correct me if I'm mistaken) is that there are 
situation in which I as BIND user don't know whether I want to do 
BIND/self or BIND/no-self on the context.

But that wouldn't work: Leaked references to 'self would cause security 
holes. There is no code where the existence of 'self *matters in 
any way*, that would be safe to accept your context! type. So context! 
has no purpose - it would be *exactly the same as object in all code 
that could possibly work on it at all*.

The situation where the user of BIND doesn't know whether to use 
/self or not, is a case of a non-programmer trying to program. REBOL 
doesn't try to solve that problem.

Ok, this view is certainly a way to avoid the problem.

That problem can only be solved by the programmer reading the docs 
and making a decision.

Leaked references to 'self would cause security holes.

 - interesting, when checking the situation of Repeat, e.g., for me 
 the references to 'self are "leaked", are they a security problem?

Any code that can access 'self depends on being able to access 'self. 
For any code that doesn't access 'self, the existence of 'self doesn't 
matter.

I think continuing to argue here does not make any sense.

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.