World: r3wp

and why this reserved word bother you ???
can't you just avoid to use it ?

Actually, I would like to see a real code where it appears to be 
a problem

What if you want to emulate another language's OOP model? Or not 
do OOP at all? Or use functions like FOR, FOREACH, MAP-EACH, REMOVE-EACH 
and REPEAT in functions that are defined in an object, module or 
script? (That means every single time, btw)

Bug#1529 in particular needs fixing; bug#1528 perhaps less so.

Again, i don't see your point, sorry. Can you just show me a snippet 
of what can't be done ?

If you are writing code in a script, module or object (which means 
all code) then the way that you refer to the script, module or object's 
context is with the word 'self. And if that word is overriden, you 
can't use it. And those context references are used often.

The use case for allowing 'self as a function argument is less pressing, 
but since the fix is easy (at least my fix is) there is little problem 
with fixing this. And it will save a lot of support headaches, or 
at least a FAQ entry: "Why can't I USE [self] [...]?"

ok i see now, but it's not a problem to my mind, I just use another 
word to pass the object to inner contexts.

context [
  this: self
  x: context [
     parent: this 
 ] 
]

I mean it's easy to bypass the problem, with "mediator" variables.

Ah, but that is when you are *expecting* to override the context. 
Only advanced users expect FOR and such to override the context. 
And I don't see the problem: It's an easy fix, as was proved when 
the exact same fix was applied to MAKE closure! in bug#447. There 
don't need to be any structural changes; just flip a flag in BIND.

if you say so :)

Can you show me a use case for doing the special treatment of 'self 
in FOR and such? Keep in mind that R2 doesn't do this, so it's only 
worth doing if it's a definite improvement in some significant way.

and sometimes i use this trick too.

context [
  a: construct reduce/no-set [
     parent: self
  ]
]

Does that work in R3? Interesting :)

there are two problems...

 - actually, not, there are more than these two problems, as you bind/no-self 
 proposal illustrates, that is what I wrote in my comment

re your question, Steeve: if you ask for the code to be evaluated 
by For, do you expect, that For binds some words in the block it 
evaluates in addition to the words you specify? I doubt it, and it 
makes a problem.

In case of the Context function you are in a different situation, 
since you expect it to bind the word 'self

this problem cannot be "cured" by bind/no-self, since it requires 
the user to always know, how he wants to bind the words in the block, 
while such an information is already "automatically available" (as 
can be proven in R2)

I just have a problem to see how huge is the burden you noticed. 
I would like to see some real use case at this point.

context [
    a: "OK"
    foreach a ["out of luck"] [print self/a]
]

this may be considered a real use case, compare the results in R2 
and R3

and, it is not a huge problem, I would call it just a gotcha, but 
do not like it

the problem is, that such a situation cannot be "hidden" by any number 
of hacks, but there is an easy and clean solution: just allow the 
majority of contexts to not contain the word 'self

(that principle was proven in R2 to work much better than any hack 
proposed/used in R3)

honestly , i would never do such thing (to be forced to use a path/var 
just to avoid name collisions) because i know paths are slower to 
evaluate than immediate words.
And I don't do that in R2 too for the same reason.

this does not have anything in common with paths, and it is a surprise 
for me, that you do not see it

I just used a path to illustrate the difference, but I can as well 
not use path, which I leave as an exercise for the reader

It's surprising me aswell you don't recognize a simple fact: self/a 
is a path! it's is a bad design to use them when you can avoid it

I certainly avoid that, when useful. In this case it was useful as 
a short example illustrating the problem

but there is no gain to illlustrate your point with something I would 
never do because simpler ways exist, no ?.

That''s why I asked for real use cases, because until now i'm not 
convinced by the benefits of such change.

Actually, not, the only problem is, that for you it is a "not real-world 
enough" code. In that case, feel free to find any example, which 
would be "real world enough" for you, I do not claim to know, what 
it is.

But, anyway, just in hope, that the path is really the only problem 
for you to see it as "real-world", here is another example:

c: context [
    a: "OK"
    foreach b ["out of luck"] [d: self]
]
same? c d

What's the point to have d: self in the foreach loop ?.

As a not bad connoisseur, I would apply the constant propagation 
rule and remove the d: setting from the loop.

Just arousing you, but honestly it's a worse example than the previous 
one.


It would not harm  to not have self anymore in FOR/REPEAT loops, 
I agree.

I simply doubt of the usefulness and the urge of such change, because 
i simply can't imagine use cases that outmatch the usual way of doing 
things.
(.And I think you neither until now)

This reminds me a good and funny local novel. Just to paraphrase:

S: "draw any triangle"
L: "here you are"
S: "this is not any triangle, it has a right angle!"
L: "here is another one"
S: "this is not any triangle, it is an isosceles triangle"
...etc, ad infinitum

as I said, I do not claim that I know, what is "real-world for you", 
and I do not see any point in your trying to convince me I am right

:)

this problem cannot be 

cured" by bind/no-self, since it requires the user to always know, 
how he wants to bind the words in the block, while such an information 
is already "automatically available" (as can be proven in R2)"


This is not true. In the case of USE, REPEAT, FOR, FOREACH, MAP-EACH 
and REMOVE-EACH we don't want the hidden 'self to be bound to the 
code block, but we *do* want the hidden 'self to be there in the 
context. In case the context persists beyond the execution of the 
function, it should be like a normal object context. The same goes 
for closures. Only for functions do the contexts not have indefinite 
extent (in R3) - they are stack-relative, so don't work beyond the 
return of the function.


However, in the case of your proposal to not have the 'self in some 
contexts, there is no way to specify that option in MAKE object! 
syntax, so the user can't tell whether it is the case or not. This 
is similar to the map! case-sensitivity option - we can't do it because 
we don't have the syntax. And we don't want to have anything that 
affects behavior on non-blackbox types that we can't see in MOLD 
or MOLD/all.

Now BIND/no-self is just a proposal to make *an internal option that 
BIND already has* usable by mezzanine code (like USE). And we know 
that BIND has that option because MAKE closure! already uses it. 
And we also want that internal option to be used by REPEAT, FOR, 
FOREACH, MAP-EACH and REMOVE-EACH, the same way that it is used by 
MAKE closure!..

''In the case of USE, REPEAT, FOR, FOREACH, MAP-EACH and REMOVE-EACH 
we don't want the hidden 'self to be bound to the code block, but 
we *do* want the hidden 'self to be there in the context." - yes 
some may want all Rebol contexts to be isomorphic with objects, erasing 
a (perceived by me as useful) information (whether the context is 
supposed to be handled using BIND or BIND/NO-SELF, when applied on 
a block), which is present in R2, where the simple usage of BIND 
always does the right thing. It surely is a matter of preferences, 
that is why I am asking other users, what is more natural for them.

''In the case of USE, REPEAT, FOR, FOREACH, MAP-EACH and REMOVE-EACH 
we don't want the hidden 'self to be bound to the code block, but 
we *do* want the hidden 'self to be there in the context." - yes 
some may want all Rebol contexts to be isomorphic with objects, erasing 
a (perceived by me as useful) information (whether the context is 
supposed to be handled using BIND or BIND/NO-SELF, when applied on 
a block), which is present in R2, where the simple usage of BIND 
always does the right thing. It surely is a matter of preferences, 
that is why I am asking other users, what is more natural for them.

sorry for the duplicity - a quirk

Ah, but that's the problem. When that context is used by FOR, I want 
'self to not be bound. However, if the context persists after the 
FOR returns then I want BIND to do the 'self trick with any subsequent 
use of that same context; this is what I mean by "like a normal object 
context". That inconsistency is "the right thing". Having BIND not 
do the 'self trick based on some hidden quality of the object is 
*bad*. It means that I can't predict the behavior of BIND unless 
I know the originator of the object, and in many cases that wold 
mean dataflow analysis.

This is another example of trying to make the interpreter second-guess 
the user and try to do they they "mean to do". That inevitably ends 
up in disaster. I don't want REBOL to do what I "mean to do", I want 
it to do what I *say* to do. I want its behavior to be utterly predictable 
given the same input (except deliberate indeterminacy functions like 
RANDOM). If it isn't then it's not as useful to programmers.

I don't want REBOL to guess whether I would want BIND or BIND/no-self 
to be used: I've already said so, do what I say to do :)

I would prefer a name other than /no-self for the refinement, if 
it comes to pass.


Ladislav's example is good, and I would like to see a similar example 
for Brian's FOR example above. It's not that I don't see the need, 
just that I think coming up with a half dozen or so "gotcha" examples 
for the docs is a good place to start. It is a tricky hidden behavior.

UNVIEW NONE to unview the last window opened imho is so counterintuitive! 
Why not just UNVIEW 'LAST, even more so because we have UNVIEW 'ALL 
too.

unview none: should be easy to change from what I can see in the 
sources.

When that context is used by FOR, I want 'self to not be bound. However, 
if the context persists after the FOR returns then I want BIND to 
do the 'self trick with any subsequent use of that same context; 
this is what I mean by "like a normal object context". - yes, and 
that is, where our POVs differ - similarly as Brian, I do not want 
one thing: I do not want Bind to behave differently when used twice, 
since it is not the right thing in my opinion - it means, that I 
cannot predict the behaviour of Bind unless I know the originator 
of the context. are there any other opinions, than mine and Brian's 
on this?

Brian does not want to Rebol to guess, but he actually forces it 
to do so - R3 now guesses, that you want to bind 'self, unless you 
say otherwise. In case of R2, that is not the case - Rebol does not 
guess, since it uses the context as defined by the user.

I changed my mind, self must absolutly remain in FOR loops (having 
context).
It allows rebolish tricky tricks in a nutshell.

See this one, I like it.

>> map-each [a b][1 2 3 4 5 6][copy self]
== [make object! [
        a: 1
        b: 2
    ] make object! [
        a: 3
        b: 4
    ] make object! [
        a: 5
        b: 6
    ]]