ME was introduced as a tool for replacing the likes of ++.
So instead of ++ variable you could write variable: me + 1. This had the nice advantage of generalizing to other operators and parameters...as well as making it clearer that an assigment to variable was taking place.
Unfortunately, with the one-unit-of-lookahead workings, you could not write variable: next me. Even if it could work, moving away from being right next to the SET-WORD! makes it even less obvious what that means.
So MY was an attempt to do a similar thing for functions that were not enfix. You could rewrite block: next block as block: my next
That's pretty cool. Though as binding gets hammered through, I got to wondering if it had a higher calling in binding...for letting you propagate bindings on SET-WORD!s on the left to blocks and functions. That gave me the idea for my func being a general replacement for METHOD, and things like x: my block would act like x: in (binding of x) block
But these are two completely different things. So they can't have the same name...
Alternatives For "Old MY"
Let's look back at it:
block: ??? next -> block: next block
We could ignore the linguistic problem and say ME just works with anything. block: me next It's kind of incohrent, though consistent.
There's block: be next. Strange, and kind of works there ("hey block. be (your) next value") I don't know quite how it generalizes across other words you might use it with. block: be append 10
I'm fairly used to MY for this, and the closeness to ME makes it feel right. Looking at it more closely, it seems unwise to change it.
Alternatives For "New MY"
If old MY was hard to understand, the new MY is even weirder...saying that it's going to swipe the binding off the SET-WORD! on the left, and move it over to the right.
There's HAS...
obj: make/bind-set-words-only object! [ ; imagine something like this exists
x: 10
block: has [x + 1]
action: has func [y] [x + y]
]
It's strange. But when you're talking about trying to communicate bindings at a mechanical level, the options are limited.
Also unclear is how this would work on PATH!. ME and old MY were only interested in the value, and there's a way to get that out of a path. But if you have something like x/y/z and Y is an object, how do you extract that object? :-/
I've hypothesized a bit about quoting vs. JUST being a way of ducking the virtual bind.
x: 20
obj: make object! [ ; imagine something like this exists
x: 10
block1: '[x + 1] ; escaped, would get the x=20 binding
block2: just [x + 1] ; no quote hence no escape, gets x=10 binding
action: func [y] '[x + y] ; you could exempt bodies from binding here
]
Soft-quoted branching and other constructs that subvert the evaluator mix this up a bit. But if you're having to worry about '(a + b) vs. just (a + b) being different meanings for binding, then you'd just have to kick in that awareness and not use if true '[a] if you wanted the binding, and use if true [[a]] instead.
The HAS could still fit in, where has func replaces the derived binding mechanics of METHOD.
Um...
I think all I've really done here is talk myself into leaving MY as-is, realized that the variant (which I'll call HAS for now) which gets bindings from the left would need new mechanics for PATH!... and I've gotten myself thinking more about the "quoting subverts virtual binding idea."