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 PARSE to match things literally:

>> block: [some "a"]

>> parse [[some "a"] [some "a"]] [some @block]

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.

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?

I like it too. I'll be curious to see what @rgchris thinks.

1 Like

Probably likes ISSUE!s coming back as ANY-STRING!, probably likes the concept, may not like the name.

AT doesn't sound very meaningful. And :foo and foo: are not COLON-WORD! and WORD-COLON! respectively. Putting AT in the name might be too much in the vein of PAREN!.

Having @foo be "SYMBOL!" or something like that would be a more appealing name, but it needs to connote its membership in its family. Needs to be short. SYM- for "symbolic"? (SYM-WORD! SYM-BLOCK!...) LINK, to be that it's pointing to something? LINK-WORD!, LINK-BLOCK!...

Weirder: DEAD-WORD!, DEAD-BLOCK! :-/

I feel kind of like maybe going long and calling them SYMBOL-WORD!, SYMBOL-BLOCK!, ... might be all right. It's not that long in the scheme of things, remember REFINEMENT? Just one more character for symbol, zero more for inert:


What I don't like about INERT is that it says too much about what the thing does, and that's really up to the dialect. SYMBOL-WORD! doesn't really say anything about behavior.

We should have ways to define shorthands, so if people wanted to in their own code abbreivate it they could, perhaps to just SYMBOL!. But I'd like the official name to keep it squarely in the WORD! class (or whatever class it's attached to).

For visibility, I wonder if @(...) makes more sense for PARSE rule splicing than the more slight **:(...)

parse ["a" @(either mode = <bmode> '[some "b"] '[any "c"]) "d"]

parse ["a" :(either mode = <bmode> '[some "b"] '[any "c"]) "d"]

Especially when things are broken up across multiple lines, I think the colon could be easy to overlook.

Also: since @(...) would have no meaning other than "inert group" in the evaluator, this isn't competing with an existing definition the way a GET-GROUP! would be, as being associated directly with a GET operation.

As with most such things, probably best to just make it and see what happens. Shouldn't be too hard, slight variation on code that already exists for GET-GROUP! and GET-BLOCK!

Sounds good. Namingwise I like symbol-foo best so far. (or sym-...)

1 Like

IIRC you thought about removing "." from valid word characters. I think having @ domain could be a frequent wish, e.g. @hostilefork.com .

At the risk of causing mass hysteria...I actually kind of like the names LIT-WORD!, LIT-BLOCK!, LIT-PATH!, and LIT-GROUP!. It's not just that I want a different letter than S (SYM/SET). But it's also that. :slight_smile:

I'm admittedly partial to the 'HANDLE!' usage of @, so I'd mourn that as a loss. My initial superficial reaction is a little queasiness at an additional symbol kicking around and adding that cognitive load, but I would need to think about what it adds to the language and where it'd produce some wins before settling on that as a judgement.

It's not clear what this is in reference to...you mean you are partial to the name HANDLE! ?

My initial superficial reaction is a little queasiness at an additional symbol kicking around and adding that cognitive load

I'd be more worried if it weren't providing a clear mechanical purpose. All in all I think the load is actually going down.

Not the name 'HANDLE!' for sure, just the notation primarily referencing the @123abc user name convention.

If then you mean it not being an ANY-STRING! thus limiting the range of legal names to valid formations of ANY-WORD!...you'd have some workarounds e.g. @["123abc"]

This points the way toward saying that to text! @["123abc"] needs to be 123abc, perhaps FORM-ing as @123abc I think we can push the shape around a bit to make this stuff easier for real-world scenarios.

So...a year later...the SYM has never quite settled for me. I still have an aversion to the SET/SYM both being S, and beyond it... I just... don't like it.

I notice that Red has chosen to call @foo a REF!

red>> type? @foo
== ref!

So another possibility would be to say that these are REF-WORD!, REF-PATH!, REF-GROUP!, and REF-BLOCK!.

The GET, SET, REF have a rhythm (shared E) that is comparable in pleasing-ness to GET SET LIT (shared T).

but REF has an unfortunate overlap with REFINEMENT which is still a word in play (though as a type constraint on paths, not as an independent type).

I dunno. LIT really still feels like it was the right word for the wrong datatype.

Usages seem to strongly favor LIT, though not necessarily in the way originally conceived.

Originally I thought the important thing about @word was that it was inert in the evaluator.

>> @foo
== @foo

But a lot of the time, that isn't what's happening with it. Enough so to question if having it ever act like that is a good idea.

Instead, it's being used many places to mean do an evaluation (or lookup), where the product of the evaluation (or lookup) should be taken more literally.


>> block: [some "a"]

>> parse [[some "a"] [some "a"]] [2 block]
; null   (tried to apply block as a rule)

>> parse [[some "a"] [some "a"]] [2 @block]
== [[some "a"] [some "a"]]  ; matched literally
1 Like

On the Unisys mainframe the AT symbol @ was called 'masterspace'. Could call something like @block thus 'masterblock'.

There's a new option, which would be THE-WORD!, THE-BLOCK!, THE-GROUP!, THE-PATH!, THE-TUPLE!, and perhaps even @ as plain old THE!

This would go along with the idea that THE is the operation which means "as is"

>> the x
== x

>> @ x
== x

>> @x
== @x

>> type of @x
== the-word!

>> type of @
== the!

It's three letters and a complete word. It fits into the overall idea of inertness.

There is also DATA-WORD!, DATA-BLOCK!, etc. but then we don't want to call @ a DATA!... and it's kind of a puzzle as to what you mean by DATA (isn't everything data?)

1 Like