World: r3wp

Generic functions that work on objects don't see the code that originated 
them. They can only tell how the objects are supposed to behave with 
their own code. Original intent was contextual (using the term correctly 
this time). Current behavior is a different context.

It's like that quote from The Incredibles: "I know what I said before! 
Listen to what I'm saying *now*."

I provided above a specific example, that demonstratd clearly what 
I meant. The support for code like that is missing in R3 and remains 
missing, even if any of #1544 or #1543 will be accepted.

What you want is for objects created by loops and functions for their 
local variables, but persisting after their creators are finished 
with them, to *break* all other code that expects objects to behave 
like objects. Same as in R2. It was a bad idea in R2 (which we can't 
fix) and it's a bad idea in R3.

This is what we get for calling objects "contexts": It makes us think 
they are contextual, when they aren't.

If you don't like the hidden 'self field in objects in R3, fine, 
but it was a fix to major problems in R2. Problems we don't want 
to come back.

...to *break* all other code that expects objects to behave like 
objects...

 - this has been demonstrated by Andreas to be false - I do not want 
 to break any behaviour of objects, I do want to not break behaviour 
 of other contexts than objects

...and, besides, my code example above is not of the kind "after 
their creators are finished with them"

Only the function! type creates other "contexts" than objects: It 
creates a stack-relative objects. All other contexts *are* objects, 
internally. Even those used by closures and loop functions. There 
is no difference.

yes, harm already done, the closure, For, Use, Repeat, Foreach, etc. 
contexts already broken

They were broken in R2. Problem solved for R3 - we just have to manage 
the binding trick.

as demonstrated by my code, already broken, my code works in R2

Oh, and module and script contexts are objects too (internally in 
the case of modules).

Your code does what you want it to in R2. That is not the same thing 
as not being broken.

OK, I say it differently: the functionality demonstrated by my code 
is not broken in R2. The functionality demonstrated by my code is 
broken in R3.

Your car has a broken axle that makes it go left.
 "Oh, don't worry, I only want to go left anyways."

There should have been a :) in there somewhere I guess.

OK, playing with you: "my car has a broken axle that makes it go 
left, therefore, I can easily demonstrate, that the functional ability 
of my car to go left is not broken". how can I call a car, that does 
not have this functionality, i.e. it cannot go left?" - I call it 
broken

Sorry, i meant "go left only in a 20ft radius circle", I didn't mean 
something most people would want to do when they aren't showing off.

Once again, this issue could easily overcome by having to separate 
types

Imagine that your DO-IN-CONTEXT function was written by someone else, 
to take any object, and depended on the 'self override. That is the 
most common case for functions that operate on objects they did not 
create and use 'self. Those would be broken if there is no 'self 
.

If you want an context! to behave like an object!, convert the former 
to the latter

yes, that is very reasonable for me, as a clean solution

Andreas, agreed, the problem could be solved by having two types. 
But that's unnecessary, since we have a solution already that doesn't 
require another type. And the two-type solution wouldn't help with 
loops and closures unless BIND? returned an object type from words 
bound to the non-object type, because to do otherwise would break 
BIND.

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?