World: r3wp

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.

People who need the 'self binding sometimes with a context, and don't 
need it other times with *the same context*.

 - this is the issue in a crystal clear form. As far as I am concerned, 
 I need to bind every block supplied to the Bind function to be bound 
 the same way, when the same context is given, because I need the 
 code to behave consistently. Therefore, I dislike the state, when 
 I do not know, what "the same way" is. As opposed to that, you seem 
 to prefer to bind blocks differently, even when they are bound to 
 the same context, which seems to be necessary only in case, when 
 the usual contexts have to contain, as I call it "unsolicited" 'self.

I only need to bind blocks differently to the same context *when 
I tell it to do so* (aka, when solicited). This is so I can write 
code that expects 'self to be bound without having to check whether 
the object I am binding to has the hidden 'self field. If I had to 
check for that, I would have to do that check with every usage of 
BIND where I had a 'self reference and use different code blocks 
depending on the results of that check. It is much better for BIND 
to just do what I tell it to do.

Regarding the Steeve's point: as far as I am concerned, your suggestion 
*is* consistent. (I see it as more consistent, than the current state) 
The only problem with it is, that some users may find it uncomfortable, 
since they do not need to have 'self related to e.g. Repeat, or other 
cycle functions...

Ah, but that's a separate issue than the BIND/self vs. BIND/no-self 
thing. BIND already has the option, internally, accessible by native 
code, to not unhide and bind 'self. And the loop functions can already 
use that option, and should: They shouldn't override  'self bindings 
unless 'self has been overriden with another, unhidden 'self field.

I definitely agree with that one :)

People who need the 'self binding sometimes with a context, and don't 
need it other times with *the same context*.
 - please, exclude me from the set of People, then.

Sure. That's why we have options :)

too late Ladislav, your "self" is already bound

LOL

...nevertheless, I need not worry, since there is an option...

And note that the 'self trick only applies to the special hidden 
'self field. And overrides of that field aren't affected: They will 
be bound or not, normally, depending on whether they are themselves 
hidden. And BIND/self shouldn't show a overriden 'self field if it 
is hidden - it should show the original 'self. Does that make sense?

And overrides -> Any overrides

Hidden fields are weird.

Well Brian, Your words have no self meanings outside this discussion 
either

Very existential of you: self has no meaning :)

until it's bound to something

to a context for instance

I feel like that sometimes whenever I'm single.

too selfish :)

The funny part of all this is that if the "hidden 'self field" is 
mandatory and not modifiable, R3 doesn't necessarily have to have 
a physical field to store it: It could be implicit. It's just a matter 
of whether having the physical field there is more efficient to implement 
than an implicit field (which I suspect it is).

Oh, Ladislav, you're going to hate this worse that THROW not throwing: 
What we call "contexts" in REBOL aren't contextual :)

well in R2 it is explicit and modifiable

well in R2 it is explicit and modifiable
 And a security hole because of this.

(Did I just say that out loud? Stupid web-public groups.)

I must admit, I don't really understant that claim. Why is it a security 
hole ?

Because 'self is *used*, by code that expects it to refer to the 
same object that it is bound to. So if it is changed to refer to 
another object, that code fails. And if that change of referent is 
carefully done on purpose it can break the code in ways that it wouldn't 
detect. And that can be bad in some cases. Admittedly, it's not a 
big hole. BIND? doesn't have this problem: It doesn't return self, 
it returns the real context reference.

BIND? was originally added to R2 to deal with that security problem 
- we used to use 'self more often. And in R3 the 'self is protected, 
and not unprotectable by UNPROTECT in a special case. So it's not 
just BIND that special-cases '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.

 - actually, there is a standard, successfully used in R2: always 
 do the same, which is both consistent and "what is needed", since 
 that is, what the programmer asked for

Amen

Ah, but in R2 those contexts were broken when they extended beyond 
the life of the function that created them. The first field was treated 
like 'self, and hidden.

I like reading the scriptures.
The Gospel according to St. Ladislav.

And the programmer that matters when it comes to BIND is the one 
that is calling BIND, and providing the code block. Not the one that 
made the context. It's different with internal use of BIND, functions 
that make, use and discard a context. If the context persists then 
it needs to behave in a predictable matter. R2 is not a good example 
to cite when deciding what is good coding practices; we made the 
decision to change things in R3 for *many* good reasons.

If the context persists then it needs to behave in a predictable 
matter.

  - and I mean predictable by someone who didn't make the context in 
  the first place.