AltME groups: search

Now BIND/no-self is just a proposal to make *an internal option that 
BIND already has* usable by mezzanine code (like USE). And we know 
that BIND has that option because MAKE closure! already uses it. 
And we also want that internal option to be used by REPEAT, FOR, 
FOREACH, MAP-EACH and REMOVE-EACH, the same way that it is used by 
MAKE closure!..

''In the case of USE, REPEAT, FOR, FOREACH, MAP-EACH and REMOVE-EACH 
we don't want the hidden 'self to be bound to the code block, but 
we *do* want the hidden 'self to be there in the context." - yes 
some may want all Rebol contexts to be isomorphic with objects, erasing 
a (perceived by me as useful) information (whether the context is 
supposed to be handled using BIND or BIND/NO-SELF, when applied on 
a block), which is present in R2, where the simple usage of BIND 
always does the right thing. It surely is a matter of preferences, 
that is why I am asking other users, what is more natural for them.

''In the case of USE, REPEAT, FOR, FOREACH, MAP-EACH and REMOVE-EACH 
we don't want the hidden 'self to be bound to the code block, but 
we *do* want the hidden 'self to be there in the context." - yes 
some may want all Rebol contexts to be isomorphic with objects, erasing 
a (perceived by me as useful) information (whether the context is 
supposed to be handled using BIND or BIND/NO-SELF, when applied on 
a block), which is present in R2, where the simple usage of BIND 
always does the right thing. It surely is a matter of preferences, 
that is why I am asking other users, what is more natural for them.

sorry for the duplicity - a quirk

Ah, but that's the problem. When that context is used by FOR, I want 
'self to not be bound. However, if the context persists after the 
FOR returns then I want BIND to do the 'self trick with any subsequent 
use of that same context; this is what I mean by "like a normal object 
context". That inconsistency is "the right thing". Having BIND not 
do the 'self trick based on some hidden quality of the object is 
*bad*. It means that I can't predict the behavior of BIND unless 
I know the originator of the object, and in many cases that wold 
mean dataflow analysis.

I would prefer a name other than /no-self for the refinement, if 
it comes to pass.


Ladislav's example is good, and I would like to see a similar example 
for Brian's FOR example above. It's not that I don't see the need, 
just that I think coming up with a half dozen or so "gotcha" examples 
for the docs is a good place to start. It is a tricky hidden behavior.

When that context is used by FOR, I want 'self to not be bound. However, 
if the context persists after the FOR returns then I want BIND to 
do the 'self trick with any subsequent use of that same context; 
this is what I mean by "like a normal object context". - yes, and 
that is, where our POVs differ - similarly as Brian, I do not want 
one thing: I do not want Bind to behave differently when used twice, 
since it is not the right thing in my opinion - it means, that I 
cannot predict the behaviour of Bind unless I know the originator 
of the context. are there any other opinions, than mine and Brian's 
on this?

I changed my mind, self must absolutly remain in FOR loops (having 
context).
It allows rebolish tricky tricks in a nutshell.

See this one, I like it.

>> map-each [a b][1 2 3 4 5 6][copy self]
== [make object! [
        a: 1
        b: 2
    ] make object! [
        a: 3
        b: 4
    ] make object! [
        a: 5
        b: 6
    ]]

See, that is a counter-example :)

Steeve, put that in a comment in bug#1529. It's a good argument for 
keeping 'self binding for FOREACH, MAP-EACH and REMOVE-EACH, and 
then consistency would make us keep it in FOR and REPEAT as well.

Well, i think you will do a better explanation than me

Are there any other opinions

: I think this boils down to what you want SELF to be. And I think, 
once SELF is easy to explain, you have found a good trade-off.

Or perhaps he hates the idea of a hidden 'self field, and the corresponding 
BIND trick :)

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.

Buggy ? what a word to say between gentleman

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

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

...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?

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.

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.

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

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.

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

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.

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

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.

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

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.

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.

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.

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.

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.

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.

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?

to a context for instance

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

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

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

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.

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.

 - this is interesting, again. My note is, that if the context was 
 created to support e.g. the functionality of For, then any subsequent 
 binding is meaningful for me, only if the functionality remains supported. 
 I think this way, even when I am the one calling Bind and providing 
 the block, unfortunately, I may not know, which alternative mentioned 
 by you to use, not knowing the type of the context I obtained.


As opposed to that, when I see a context without 'self, I know, that 
the context was created so, that it is not meant to support 'self 
binding, and that is all I need to know. How would you do it obtaining 
a context of unknown origin, that would contain '"unsolicited" self? 
(of course, not knowing that information, since there is no way how 
you can find that out)

I meant the above as a contribution to the "predictability" issue 
- how can you predict, whether the block would behave as originally 
intended, not knowing, what the original intent was?

Generic functions that work on objects don't see the code that originated 
them. They can only tell how the objects are supposed to behave with 
their own code. Original intent was contextual (using the term correctly 
this time). Current behavior is a different context.

I provided above a specific example, that demonstratd clearly what 
I meant. The support for code like that is missing in R3 and remains 
missing, even if any of #1544 or #1543 will be accepted.

What you want is for objects created by loops and functions for their 
local variables, but persisting after their creators are finished 
with them, to *break* all other code that expects objects to behave 
like objects. Same as in R2. It was a bad idea in R2 (which we can't 
fix) and it's a bad idea in R3.

If you don't like the hidden 'self field in objects in R3, fine, 
but it was a fix to major problems in R2. Problems we don't want 
to come back.

Only the function! type creates other "contexts" than objects: It 
creates a stack-relative objects. All other contexts *are* objects, 
internally. Even those used by closures and loop functions. There 
is no difference.

Your car has a broken axle that makes it go left.
 "Oh, don't worry, I only want to go left anyways."

There should have been a :) in there somewhere I guess.

OK, playing with you: "my car has a broken axle that makes it go 
left, therefore, I can easily demonstrate, that the functional ability 
of my car to go left is not broken". how can I call a car, that does 
not have this functionality, i.e. it cannot go left?" - I call it 
broken

Sorry, i meant "go left only in a 20ft radius circle", I didn't mean 
something most people would want to do when they aren't showing off.

yes, that is very reasonable for me, as a clean solution

Andreas, agreed, the problem could be solved by having two types. 
But that's unnecessary, since we have a solution already that doesn't 
require another type. And the two-type solution wouldn't help with 
loops and closures unless BIND? returned an object type from words 
bound to the non-object type, because to do otherwise would break 
BIND.

Because even if we made BIND not do the 'self trick by default, we 
would still *need* to add the /self option, and that option would 
*need* to have a 'self field to do the trick with, *every time*.

You have to assume that the 'self trick needs to be able to work 
with every "context" that you pass to BIND, even if BIND doesn't 
do the trick by default. Because the trick is necessary for a lot 
of code. And leaked 'self references can be a security hole, allowing 
access to otherwise encapsulated code.

Make sure that DO-IN-CONTEXT uses BIND/self, depends on it, requires 
it. Then pass in a "context" created by a loop function.

It's all well and good to say that the current BIND does the 'self 
trick and you don't like that. But there is a lot of code that depends 
on that trick, so if you don't want to do it for your code, you better 
make that an option (perhaps the default one).

there is a lot of code that depends on that trick

 - Not R2 code of course. R2 breaks code that depends on 'self existing.

Btw, I felt uneasy when the first time I saw that code :

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]

Now i know why. It's a serpentine way for simply doing:
>> repeat i 1 block

Erf :)

Why would that be a problem? Simply don't accept context!s wherever 
you can't handle them?

It's a serpentine way for simply doing:

 - actually, it is not, just a hint: the code is perfectly OK, and 
 it works in my programs. The main difference between the code and 
 my production code is, that the A-FUNCTION and the DO-IN-CONTEXT 
 function are more complicated (actually doing useful things, the 
 code above is useful only for the demonstration purpose).

Don't you see, if BIND/self is the only way to see the 'self word 
at all, and that word is otherwise not visible, and BIND/self would 
require the existence of that word, then there is no point in having 
a separate datatype. The only code that could possible be affected 
by the existence or not of a 'self field could not possibly be used 
with that type, and all other code wouldn't be able to tell the difference.

so what Steeve, do you want to prove, that I did not use a real code 
and shorten it so, that the problem is still visible?

So what you are asking for is a separate datatype that is like object!, 
except indistinguishable from it is any code that would accept it.

The suggestion to add /self or /no-self to BIND is only a suggestion 
to make a proven, already existing, already used internal option 
externally visible.

The point is that we would have a clean way to refer to an environment 
which is not conflated with an object.

And it's not indistinguishable from all code accepting it; it makes 
a big difference to code that uses BIND.

And finally, you still don't see that this only makes sense as a 
combined proposal with adapting BIND to predicate behaviour on the 
type of context.

And if that all matters is a question about how you assume typical 
BIND code to look like. Ladislav's point (at least as far as I understand 
it, Ladislav please correct me if I'm mistaken) is that there are 
situation in which I as BIND user don't know whether I want to do 
BIND/self or BIND/no-self on the context.

The situation where the user of BIND doesn't know whether to use 
/self or not, is a case of a non-programmer trying to program. REBOL 
doesn't try to solve that problem.

Ok, this view is certainly a way to avoid the problem.

That problem can only be solved by the programmer reading the docs 
and making a decision.

Leaked references to 'self would cause security holes.

 - interesting, when checking the situation of Repeat, e.g., for me 
 the references to 'self are "leaked", are they a security problem?

In any case, adding a BIND/self refinement would certainly be an 
improvement over the current situation.

REPEAT et al doesn't need to have 'self be bound in its code block. 
But if a reference to the object created by REPEAT persists after 
the function ends, any subsequent use of that object would either 
need to use its 'self, or not see its 'self at all. REPEAT *can't* 
know which. If the object is used by any code that needs to see 'self 
(like BIND/self) then that 'self absolutely must be there, because 
the otherwise the 'self references in the code block would retain 
the bindings they had before, which will likely be encapsulated code 
in a module (this is R3, remember). If the object doesn't need to 
use 'self, *it can't*: The reflectors, the formatting code, and BIND 
without the 'self trick can't tell if there is a 'self there or not, 
so if it's not there it *would make no difference whatsoever*. So 
all you are proposing is to make a datatype that doesn't contain 
a hidden 'self field, but which can *only* be used in cases where 
there not being a hidden 'self field is something that doesn't affect 
it at all.

If you make the loops and closures create a non-object that doesn't 
have a 'self field, all that you have done is make those objects 
not usable where the existence of the hidden 'self field matters 
in the slightest. And for code that doesn't use the 'self field, 
it doesn't *see* the 'self field either, and can't tell that it is 
there or not. So you have added nothing, and taken away something 
that might be useful for no good reason. It's a bad idea.

You can do that now: The hidden 'self is overriden, and the 'self 
trick doesn't apply. Like this:
; Current behavior: 
>> a: construct [] 
== make object! [ 
] 
>> append a [self: 1] 
== make object! [ 
self: 1 
] 
>> do bind [self] a 
== 1 
>> protect/hide in a 'self 
== self 
>> do bind [self] a 
== make object! [ 
] 
>> same? a do bind [self] a 
== true

And if we BIND/no-self on a object with an overriden 'self field 
we can still see it. And if the override 'self is hidden, BIND/self 
doesn't unhide it, it inly unhides the original 'self.

I don't think you can unhide a field at all, let alone 'self.