World: r3wp

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
    ]]

See, that is a counter-example :)

Steeve, put that in a comment in bug#1529. It's a good argument for 
keeping 'self binding for FOREACH, MAP-EACH and REMOVE-EACH, and 
then consistency would make us keep it in FOR and REPEAT as well.

Well, i think you will do a better explanation than me

Credit where credit is due. I can add an explanation later if you 
like. And I don't want it to seem like only Ladislav and I have opinions.

Are there any other opinions

: I think this boils down to what you want SELF to be. And I think, 
once SELF is easy to explain, you have found a good trade-off.

Ladislav, your suggestion to have some contexts not have the hidden 
'self in them at all is not what you think. You are suggesting that 
we create object! contexts (for that is what all contexts are except 
for function! contexts) that *can't* be specified by MAKE object! 
syntax, ever. And thus these objects will have an attribute that 
doesn't show up when you MOLD it (because MOLD generates MAKE object! 
syntax) that affects one of the core features of the BIND function. 
And that attribute wouldn't be serializable even if you added it 
to the MOLD/all syntax, because MOLD/all serialization of objects 
doesn't work: MOLD/all syntax for objects doesn't restore word bindings, 
only DO syntax does.

Posted, Brian

Thanks.

Brian, I think Ladislav wants objects and contexts to be separate 
things. This would most directly be modelled as two different datatypes, 
I guess: object! and context!. The former having the hidden 'self, 
the latter not.

Or perhaps he hates the idea of a hidden 'self field, and the corresponding 
BIND trick :)

Steeve, while this may be considered a nice trick, I don't think 
it's worth keeping the nasty self around.

map-each [a b] [1 2 3 4 5 6] [copy bind? 'a] does the same and is 
more explicit about what you want.

Andreas, you also make a good point. Please put that counter-counter-argument 
in a bug#1529 comment.

(The remark about increased readability of course only makes sense 
if you are accustomed to read bind? as "get-context" :)

yes but it's not an abstraction anymore.
if the words are changing, you must rewrite to action block

to -> the

Yes, but SELF shouldn't be there at all, it's only leaking through 
from the implementation.

Otherwise, SELF should also be there in all other contexts (pun intended)

I.e. I can make the same arguments regarding `apply closure [x] [self] 
[42]`, which behaves differently from the MAP-EACH example.

actually, it is everywhere.

I like the trick for conversion of records from fixed block spans 
to objects, both for Steeve's example and for passing along to functions 
that take object! records. However, as Andreas says we don't need 
the 'self binding trick to do it, we can use the bind? function.

(except in functions :)

Yep I agree, but mine is more Rebolish, that's all :)

It's not more rebolish if it is buggy.

It is rebolish, but the use case is more rare than regular usage 
of 'self to refer to the outer object context. And BIND? is also 
rebolish :)

Ignore that last remark, please.

Buggy ? what a word to say between gentleman

(My last remark, that is.)

lol

Actually, the BIND? trick works for all loop contexts but not for 
object contexts, which might have no fields. And it wouldn't work 
for closures with no parameters, but there is no point to those anyways 
so who cares :)

bind? is the new self :)

Except for objects, for the reason I mentioned above.

bind? 'self will work for objects, no :) ?

(Just kidding :)