"Binding 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 :slight_smile:

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
1 Like


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.

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]

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