World: r3wp

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.

I mean syntax like: #[context ...]

(which is "free" currently)

Not really, at least not for datatypes that depend on binding, like 
objects, functions and closures. REBOL's definitional binding model 
(I used to call it "applicative binding") makes that syntax not really 
work properly. Bindings are not restored by the MOLD/all serialized 
LOAD syntax. Regardless of whether there is a hidden 'self field 
or not, you need to create it with MAKE syntax in order to get the 
bindings restored properly.

Another datatype would work with MAKE syntax though. But it doesn't 
handle the most common case: People who need the 'self binding sometimes 
with a context, and don't need it other times with *the same context*. 
For that you need a BIND option.

One thing you shouldn't do with a programming language is assume 
that the programmer doesn't know what they want to do, so you try 
to second-guess them. That is always the worst approach because the 
programmer will always end up having to work around your guesses 
so that they can do what they actually want to do, *which only they 
can know for sure*.


It's a bad sign when the language designer talks about guessing what 
the programmer wants to do. It is much better to make a consistent, 
sensible default, then provide alternate behavior as explicitly chosen 
options. It is incredibly presumptuous for you to say that the programmer 
"didn't really want to do that", and then do something else. It is 
much better to make the behavior consistent *and documented* then 
assume the programmer *knows* what they want to do and has told you 
so.


It is not the job of a programming language or library to do what 
the programmer "wants" to do. It is the job of the programmer to 
determine what they want to do, and the job of the tool to do what 
the programmer *says* to do. And if the programmer makes a mistake, 
the tool should be as helpful as it can by throwing errors where 
it is unequivocally wrong, giving enough information to the programmer 
so they can figure out whether where they went wrong, and to behave 
consistently and predictably. Because (short of bugs) the tool is 
never at fault if it does what it's told to do. It might not be the 
right tool for the job though, but that means another tool should 
be used.

Programmers are a self-selecting lot, most of the time. It's not 
like they're end users. They should be treated as if they know what 
they're doing.

:Why 

cripple" all these contexts so, that Bind has to do unsolicited work?" 
- The behavior of BIND is documented, so it is presumptuous of you 
to say that its behavior is "unsolicited" when it is behaving as 
it is documented to behave. It is much better to use the word "unwanted" 
here. It is clear that *you* don't want BIND to do the 'self unhiding 
trick, and if there's no way to turn that off then it is a problem 
for you, as a user of the programming language. So there should be 
an option, and maybe your preferred behavior should be the default.


However, you as a language designer (this is a different you, btw) 
has to consider what other users want to do, and that won't necessarily 
be consistent with what you (as a user) would want to do. So you 
(the designer) make tradeoffs, balance concerns, look for the most 
common behavior, make sensible choices, and try not to mess up. And 
then finalize the behavior in a tool that only does what it's told 
to do, and document that tool's behavior (at least on the surface). 
Then you (as a user) can know that the tool is going to respond the 
way it is documented to do when you tell it to do something - for 
a tool, this is what it means to do what it is supposed to do :)

Besides, The 'self problem has easy workarounds. just by  passing 
the wrapping context in another variable than self.
And you don't mess your code or make it slower because of that.
Lot of fuss for nothing, to my mind :)

So does the self-not-bound problem have a workaround: BIND?. The 
question is which behavior is more common: Referring to outer contexts, 
or referring to the local context by reference? In the case of scripts, 
modules and objects it is more common to wnat to refer to the local 
script, module or object context by reference, and the outer context 
references are rare enough to make them use the workaround. In the 
case of loop or function contexts, referring to the local context 
by reference is rare, but the outer contexts are referred to all 
the time, so it makes sense to use the BIND? workaround for local 
and not override self.

And once the context is created and extends beyond the function of 
its initial creation, there is no standard for which is more common. 
Best to let the programmer decide.

Perhaps more logical to do so. But as I said, I can deal with this 
problem with no overhead.

When time will come  to polish Rebol we will manage it, but now there 
are still important missing features or bugs.
Just a matter of priorities.

This is core stuff, which will affect a *lot* of code. It's best 
to resolve this before too much of that code is written.

For instance, if BIND/self (#1544) is implemented, then I will have 
to add the /self option to every usage of BIND in DO, LOAD, IMPORT, 
DO-NEEDS, INTERN and MAKE-MODULE, and perhaps some other places in 
the mezzanine code as well. This is not a problem (really, it isn't) 
but it is better to do this now while the scope of the effects is 
still calculable.

well, you'll have to touch some internal code and some mezz.
Meaning, No impact for us. 
==> Postponed with no fear :)

No impact for end programmers because there isn't much written in 
R3 yet outside of the mezzanines. But it would impact the GUI code 
as well, so we should get this done before too much of that is written. 
And people are working on that now (mostly Henrik, but still). This 
is a really time-critical change: Whatever we choose, it should go 
into one of the next two R3 releases.

BIND is one of the most core functions in REBOL. Any change to its 
semantics would have big impact, so should be done sooner rather 
than later.

Ok, I'll put 2 or 3 words in your favor to Carl :)

I am starting to be in favor of BIND/self, mostly because BIND/no-self 
looks so stupid (I hate the name). YMMV :)

yep but it means more work and more potential regressions

Yeah, it's not R2 compatible either (which isn't necessarily a problem, 
but still).

Not really, at least not for datatypes that depend on binding, like 
objects, functions and closures. REBOL's definitional binding model 
(I used to call it 

applicative binding") makes that syntax not really work properly. 
Bindings are not restored by the MOLD/all serialized LOAD syntax. 
Regardless of whether there is a hidden 'self field or not, you need 
to create it with MAKE syntax in order to get the bindings restored 
properly." - this is a different, and quite interesting issue. As 
far as I can tell, this objection applies to any LOAD MOLD/ALL combination 
used, though.

Yup. But it only really affects objects, functions and closures. 
Most types aren't affected by binding issues, and the other main 
type that is - modules - can't be serialized in a restorable form 
at all.