"Binding Indirection"

[Brett]

@bradrn

@Brett

I think rebol needs some more sophisticated binding operations. I think @hostilefork noted something similar recently too. I wonder if there could be binding operations that allow a bit of indirection. Intuitively I feel that one should be able to define a binding scheme which can become an operator in your code. For example, with ctx.prop, CTX is a specific object. I might be delusional, but maybe CTX could be a binding scheme/function one can define which has access to a set of environments already encountered, that one may want to bind to?

Since I’m not familiar with Rebol 2, I don’t really understand this paragraph. Could you give an example of what you might consider a binding operation with indirection?

My hand wavy intuition is that that it could be useful if CTX we could define to be some binding function that can return the appropriate context/environment that "should" be bound to, given PROP. Where "should" is determined by some user defined scheme or policy. This function would have access to environments the interpreter knows about like the enclosing function or loop or something else interesting.

For example, this might allow one to simulate how scopes work in a language other than rebol, allowing the CTX.PROP notation to be used in that way, instead of Rebol's default method of words carrying their binding. Or maybe the policy would allow a novel module search for CTX.

I admit this intuitive idea is certainly not fully formed and is full of gaps, but might be interesting. Apologies

[hostilefork]

@Brett

For example, this might allow one to simulate how scopes work in a language other than rebol, allowing the CTX.PROP notation to be used in that way, instead of Rebol's default method of words carrying their binding. Or maybe the policy would allow a novel module search for CTX.

Perhaps what you are suggesting is being able to do things like:

>> x: 10

>> foo: func [x] [print ["local" x "super" super.x]]

>> foo 20
local 20 super 10

[Brett]

Yes.

Also, I don't know, maybe it would be useful if "super" is not a keyword but an instruction to invoke a specified binding policy. Perhaps other policies might be user specified and nameable.

[bradrn]

@hostilefork

Perhaps what you are suggesting is being able to do things like:

>> x: 10

>> foo: func [x] [print ["local" x "super" super.x]]

>> foo 20
local 20 super 10

If environments are first-class values (as I just suggested), then implementing this should become pretty easy, along the lines of:

foo: func [x] [
    env: get-current-environment
    super: parent env
    print ["local" x "super" super.x]
]

[hostilefork]

I'll mention my little pet idea, which is that I've wanted method members to be accessed via BLANK!-headed TUPLE!s.

Anywhere blanks occur in tuples and paths, they're just an invisible slot in the render:

>> for-each item '//a// [probe item]
_
_
a
_
_
== _

A blank headed tuple is, e.g.:

>> to tuple! [_ something]
== .something

There's also SET-TUPLE! and GET-TUPLE! variants and all of that.

>> to set-tuple! [_ something]
== .something:

So anyway, I've wondered what the evaluator behavior should be for these. And I've thought it would be nice if they would give you the kind of comprehensibility benefit that this->member or self.member offers. So when METHOD invocation patched the environment to the body invocation, it would somehow affect the environment in a way that said "don't put the instance in the main WORD!=>VALUE! mapping, put it in a secondary mapping you get to via .xxx access":

.WORD as Member Selection

It seems like it's becoming more feasible with this idea that the binding gets sticky and isn't removed after that. Because you could wind up carrying the .xxx over somewhere else where it wouldn't have that secondary mapping available but it didn't matter...because it would still look up so long as it got bound by evaluation in its original location.

It's a feature I'd like, because it can be near-incomprehensible trying to read code and not knowing whether something is an object member. Maintaining Rebmake is particularly miserable due to this.