World: r3wp

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)

However, we *can* make it an option of BIND. It's already a binding 
option for natives, we just can't see it from REBOL code.

It's not a matter of interests. In order to make one object have 
a hidden 'self field, and another not, we need to have more than 
one object type. This isn't a matter of preference, it's inherent 
in the syntax of MAKE.

Now when it comes to our interests, they are aligned. I agree that 
loop functions shouldn't bind 'self (#1529), and that functions should 
allow self in their argument lists (#1528), and that people should 
be able to bind a block without binding 'self if they don't want 
to (#1543). I also agree that /no-self is a dumb name and don't have 
a better one that isn't taken.

By "conflict of interests" I mean:


1) the interest to have seamlessly working loops, functions, closures, 
Use, etc. By "seamlessly" I understand "working without ever doing 
unsolicited 'self binding.

2) the interest to have a simple syntax for Mold/Load to describe 
these contexts


As far as I am concerned, 1) is a priority for me, therefore I prefer 
to have a different syntax for this type of contexts. Another possible 
option, which *might* be considered as an alternative is, to have 
a /self refinement for Bind as in BIND/SELF, since that variant covers 
the minority of use cases (just objects and modules), but I doubt 
it cold be called "functionally clean" anyway, thus, probably still 
violating 1)

But we agree on those things.

just objects and modules

 *and scripts* - 'self is bound in script code too. It affects all 
 REBOL code.

And it's not unsolicited there either, it's an intentional feature.

If you want the 'self trick to be an option, you must realize that 
almost all R3 code will be processed *with* that option. LOAD, DO, 
INTERN, MAKE-MODULE, DO-NEEDS and IMPORT will all need to use that 
option, so that means that most code will have 'self bound.

even adding scripts (I consider the usage of 'self quite rare in 
scripts anyway) we get a minority, since one script typically defines 
many functions/Use/closures/loops, etc.

even adding scripts (I consider the usage of 'self quite rare in 
scripts anyway) we get a minority, since one script typically defines 
many functions/Use/closures/loops, etc.

It's not so rare anymore in scripts: self is the new system/words.

currently, I am having a problem to say, that "AltMe works here", 
it is just awful

:(

OK, still just one to many: one script to many functions, loops, 
etc.

Make a counter proposal then, like I did with APPLY/only vs. RAPPLY. 
It's real simple: We both want the option, but disagree on the default. 
I already made a proposal for BIND/no-self. Make a counter proposal 
for BIND/self in CureCode. One will be chosen, the other dismissed.

You can even copy the text of #1543. Or I can do it.

OK, makes sense, I already expressed my opinion in #1529, but this 
looks like deserving its own ticket

It's a separate issue - that's why I submitted #1543.

The third choice, making it an option at object creation time, won't 
work. We can't add refinements to MAKE.

And the block spec of MAKE object! is free-form. It's the same with 
MAKE map! and the case-sensitive option.

Done: bug#1544.

The third choice, making it an option at object creation time, won't 
work. We can't add refinements to MAKE.

As I mentioned before, this third choice is perfectly viable by introducing 
an additional datatype: object! vs context!, for example.

Yes, Andreas, my point of view is the same. This solution is clean 
and working.

(Why "cripple" all these contexts so, that Bind has to do unsolicited 
work?)

Especially when, as demonstrated, the acceptance of #1543 does not 
solve all the issues. (neither the acceptance of #1544 can)

Another variant, even simpler, may be to not use a different datatype, 
just use another syntax variant for Mold and Mold/all, if the context 
does not contain 'self - variant syntaxes for other datatypes are 
supported even now, as far as I know.