World: r3wp

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

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.