World: r3wp

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.

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.