Much of Rebol's appeal lies in its diverse collection of parts. One of the parts that has been coveted for a while is @foo.
Questions have arisen on what to call this. AT! has been suggested, though this can get a bit confused with the AT operation in the language. (TO-AT also looks kind of strange).
Other concepts have been to retake HANDLE!, call it IDENTITY! or simply merge it with EMAIL!...which is what Red has done:
>> type? @foo == email! >> any-string? @foo == true
While simply seeing it as an extension of EMAIL! has come up as an option, other questions have been asked about whether it should be an ANY-WORD! and have binding. I liked the idea of it having binding, because I like it being able to be thought of as "pointing" at something. For instance, being used to implicate a parameter in a FAIL:
foo: func [bar [integer!]] [ if bar >= 1020 [fail @bar "Must be less than 1020"] ]
But now I think that @ may be able to serve a greater purpose for us as a modifier that is like GET-XXX! and SET-XXX!, in that you can apply it to WORD!, PATH!, GROUP!, and BLOCK!. It would fulfill some of the motivation of having another ANY-WORD! type without being mixed up with the things that made ISSUE! a bad ANY-WORD! (e.g. we knew #123-45 should be an ISSUE, while :123-45 wouldn't be a valid GET-WORD!)
And it can provide an otherwise missing ability: Irreducibility.
Irreduciblity: the missing link for enumerated types
There's a problem I have pointed out that shows up when you try and use a WORD! in an enumeration.
which: pick [foo baz bar] n do compose [ select data (which) ... ]
The words look nice, but they're just one evaluative step away from being looked up as variables. You can quote things--now anything you want. But that only delays the problem...once you evaluate the apostrophe vanishes, and now you're back to the same problem again. You're always trying to compensate for how many evaluations you are doing to line up the quoting levels.
If you imagine the AT-XXX! types not evaluating, they do something you couldn't do before, unless you used an ISSUE!. But as I say, the applications of ISSUE! don't really fit with WORD!s and symbol comparisons. And # is already overtaxed in the language for so many things, that if we suddenly became prescriptive about using it for symbolic enumerations then that would be a whole lot of #'s.
This would not only soften the blow of losing bindings in ISSUE!, but it would open doors to questions like what @(...) or @[...] could mean in dialects. The @(...) could be the instruction for getting an evaluative product to KEEP that's not reused as a rule (the way :(...) would be)
>> did parse [a a a] [collect data [ some [keep 'a keep @(reduce ["b" 1 + 2])]] end ] == true >> data == [a "b" 3 a "b" 3 a "b" 3]
I was using GET-BLOCK! for that, but I think this would probably be better.
In the main evaluator, AT-BLOCK! is a bit redundant, given that blocks don't evaluate in the first place. But who knows what uses they might have. For instance following the line of thinking with PARSE, keep @[...] could be used to mean keep literally that block's contents with no evaluations.
AT-PATH! could play a pivotal part in NewPath, because plain PATH!s are too "lively", and if you compose them places they will evaluate. Quoting is not enough. You need full-on-dead, and this does it.
It looks to be ticking several design boxes for this long-desired feature. Think I'm liking it. Anyone have thoughts?