Occasionally I've thought that "BIND" could be an arity-1 operation that pastes the currently running environment onto its argument:
>> x: 1000
>> code: bind '[print [x + 20]]
>> eval code
1020
But arity-1 seems wasteful for something so inflexible to be given a word so short like BIND (especially when $ exists as a shorthand for this).
So how about HERE being a function that gives you the current context in the evaluator, so you can pass it to arity-2 BIND?
>> x: 1000
>> code: bind here '[print [x + 20]]
>> eval code
1020
That seems very literate. BIND-HERE could be an intrinsic (intrinsic dispatch only works on arity-1, no frame! unless debug mode). That could be used by people seeking to optimize.
(I feel like @bradrn suggested something like this--maybe even exactly this--at a time when I was reluctant to make functions that were callsite-sensitive. I'm still definitely reluctant to see too many things take on this property... making them harder to abstract, specialize-with, or reason about. Which is why HERE being a rare exception helps limit the need to give that property to too many things.)
This is competitive with how <here> is used in PARSE as a combinator to get the current position. I'd sort of rather move that out of the way:
-
<position>(shorthand as<pos>?) -
<at>or maybe<@>?
Actually, the combinators all take a parameter called INPUT which is understood to be the input at the current position. So <input> would make sense in that regard, more than how I've been using it to mean "synthesize the input to the original parse call".
That may be more an indictment of the name of the argument to combinators than it is a suggestion that <input> is a great name for the current position. Perhaps the parsers should get POSITION or POS.
Anyway, point is that if HERE is going to take on this environment-based meaning, then PARSE should probably not have a competing meaning for the word...since it's going to have to speak about binding environments too.