World: r3wp

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 :)

Please bring up the BIND? trick in a comment to bug#1529.

These conversations in AltME are fun, but unless they are in blog 
comments, chat or CureCode they have no effect.

Yeah, I'll add a remark later on, but I gotta run now. Take care.

Carl is Altmeproof

There's too much here. He can't afford to read all of this crap. 
He needs someone to summarize for him, and to put it somewhere that 
won't scroll off the screen.

Ok, Andreas, I'll add it for you and attribute it to you. I'm working 
on this stuff now :)

Steeve, I couldn't find your comment in CureCode bug#1529. Where 
did you post it?

Sorry, i posted it on the blog

wrong place it seems

Yeah, we've played out the conversation there. Too many comments 
there already.

All right, fine, I'll post your code in CureCode and attribute it 
to you. And Andreas' code too.

...I cannot predict the behaviour of Bind unless I know the originator 
of the context.

 This seems like a core question to me. And while Steeve's example 
 is really neat, I wouldn't say it is REBOLish per se. BIND? doesn't 
 say a whole lot more, so I don't think either example is something 
 to hold up as a best practice. :-)


Is it by design? If so, how is it intended to be used, and how should 
it *not* be used? If not, what warnings do we need to include in 
docs?

Well, when you consider that MAKE closure! also originally did the 
'self trick and now doesn't, it appears to be accidental.

Comments from Steeve and Andreas posted to CureCode #1529.

Thanks Brian

And look at #1543 as well.

bind/trick ? :)

That's the default behavior :)

Usually we use /only to mean /no-tricks, but /only is already used 
by BIND for something else.

so, bind/neat :)

I used /no-self because it's similar to the /no-copy used elsewhere. 
Any other practical suggestions?

CONSTRUCT's /only means /no-tricks, for instance.

So does INSERT and APPEND /only, the trick being inlining block values.

But BIND is using /only to mean /shallow right now.

one more example in hope, that it will be understandable enough. 
First, the description in words: we define a function obtaining a 
block of code, which uses e.g. a Repeat loop. During the loop, the 
Block argument shall be executed too, but bound to the loop context, 
to be able to use the loop variable (s). The code looks as follows:

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]


I hope, that everyone understands, that this may well be a part of 
a real-world application, but my example is minimized to contain 
only the constructs that illustrate the problem. Now, in R2 the block 
will be executed "in the right context", being able to use the cycle 
variable 'i. In R3, the block is executed "in the wrong context", 
since the 'self variable will be bound, which was unsolicited.

And "since the 'self variable will be bound, which was unsolicited" 
is the key. Binding the hidden 'self field is the bad thing here.

But that is contextual (in the real sense of the term, not the REBOL 
term). In this case it's the fact that this is a loop function, and 
we don't expect or want 'self to be overriden by a loop function.

Generally, I consider 'self binding as unsolicited for purposes like: 
loop constructs, functions, closures, use, etc. For a similar opinion, 
see also CureCode bug #447.

Agreed :)

But, as the above example illustrates, once we have an "obligatory 
self" in every context, unsolicited binding *will happen*

Nope. As #447 demonstrated, it's optional.

That does not mean, that I do not understand the reasons, why BrianH 
proposed the "obligatory 'self" variant, it just means, that I have 
different priorities

The loop functions just aren't using that option yet. And we can't 
see the option since it's internal.

#447 does not illustrate that it is optional, it just illustrates, 
that the problem can be circumvented, but only in special cases

as demonstrated above, the general case "cannot be circumvented"

So I propose that the loop functions use that option (#1529). And 
I *separately* propose that the option be made visible to users (#1543).

What we *can't* do is to make the hidden 'self field not there at 
all, since there's no syntax that would support that as an option.

By "general case" I mean the case of the Do-in-context function.

So it's either always there, or never there. It can't be an option 
of object creation - the syntax won't support it. We already went 
through this with case-sensitive maps.

(so, we have a situation of conflicting interests here)