The Thought that Won't Go Away: @ acting as LIT-WORD! acts?


#1

Today it’s not legal to write @foo or @foo/bar in code. But people want it, and it’s legal in Red. This brings us to the question of what the evaluator behavior of such a thing will be in Ren-C.

Something I haven’t been able to shake since the beginning of seeing the usage of apostrophe for LIT-WORD! is that it is too slight for something as important as it is. There’s a big difference between foo and 'foo but it’s rather hard to see.

The rise of the idea of using apostrophes purposefully in names also throws in a wrench. Not only is there isn't coming very soon to wide use, but I do kind of like the mathematical convention of ticking apostrophes on the tail of things to make “derived” versions of them (f, f', f'')

block: [isn't "Hello"]
switch first block [
    'isn't [print "This runs"]
]

foo': specialize 'f [arg1: 10]
foo'': specialize 'f' [arg2: 20]
action: get 'f''

What if the evaluator treated @ like it treats apostrophes today?

block: [isn't "Hello"]
switch first block [
    @isn't [print "This runs"]
]

f': specialize @f [arg1: 10]
f'': specialize @f' [arg2: 20]
action: get @f''

While it is “blocky”, I feel there’s something more “solid” about it.

@foo has to be “wordlike” anyway, for FAIL

The idea of “follow this link, to a word” being the meaning of @ is something I am eager to use with <skip>-able parameters for FAIL, to say where an error should be reported. (so indicate the callsite, instead of where the fail is).

Today:

foo: function [number] [
    if number > 1020 [fail/where "Value is too large" 'number]
]

Soon:

foo: function [number] [
    if number > 1020 [fail @number "Value is too large"]
]

This would rule out EMAIL! unification

The evaluator goes by type, so the quirky-and-not-completely-figured out unified handle! proposal would have to be scrapped. @foo would be a LIT-WORD!, @foo/bar would be a LIT-PATH!.

It would also help with things like LIT-GROUP!s

If you look at something like:

code: '(
    #foo [baz bar]
    whole bunch of stuff ...
)

That super-lightweight apostrophe is easy to miss. Compare with:

code: @(
    #foo [baz bar]
    whole bunch of stuff ...
)

It is slightly more labor to enter on most keyboards

I’m not sure how much of a concern it is, in the sense of I don’t know how many LIT-WORD!s people have to enter (compared to +, or { or other shifted characters in various hard to reach places). They’re used often, but not that often.

Leading apostrophe compatibility would be needed for redbol

I’m fairly aware there’s going to need to be some kind of runtime switches to enable wider redbol compatibility. Continuing to treat leading apostrophes as LIT-WORD!s would be a part of that.

But in the near term, there’d not be any specific pressure to retake 'foo and 'foo/bar. I’m not sure exactly what they’d be used for once degrading to a normal word character:

'foo: chain [foo | function [x] [x + 1]]
''foo: specialize @'foo [arg2: 20]

But whatever they’re used for “meatier” at symbol makes it viable, and helps differentiate from ''foo being a lit-word whose spelling is 'foo :-/

My other idea variant was FAR more radical

The other thought I had when first questioning ' was what if double quotes weren’t used for strings, but for quoting arbitrary material literally:

block: [isn't {Hello}]

switch first block [
    "isn't" [print {This runs}]
]

It would look better when quoting SET-WORD!s as "foo:", and provide clearer and more visible delimiting on GROUP!s:

code: "(
    #foo [baz bar]
    whole bunch of stuff ...
)"

Because it would be part of a paired delimiter, you wouldn’t have to worry about nested quoted material.

While this is sort of “interesting” it’s completely incompatible. It makes you type two delimiters when a common case only required one. And from my experiments trying using only braced-strings to see if quotes could be freed up for something else, I found the braces were far too heavy when used for every string.
Plus the presence of two styles letting you conveniently have things like a string with a single brace "{".

So I dropped that one, but have kept the @ idea consistently in mind. I’m feeling pretty serious about trying it. Any thoughts?


#2

This may be an unhelpful, half-baked reply. I usually pronounce the @ symbol in my head as “at”, so I’m not in love with the idea of using it to represent a lit-word. It’s not a big deal, I’d get over it. :slight_smile:
I’ve sometimes thought that the @ symbol could be used as a glyph for anything that can be addressed, including the location of source-data. The @ could be at the beginning of a URL, email, port, etc.

I don’t have much reasoning behind this, but could the # symbol be used to denote a lit-word? It’s very eye-grabbing.


#3

I brought it up just because it’s an idea that I have whenever I get frustrated with ' and look at a particular case where it falls down. The recent frustration triggering the thought was having a variable d' and then quoting it and getting 'd' and thinking how bad that looked, as if it were a string or character literal. This then ties into the fears of letting apostrophe-words become common, like isn't, and how that’s going to play.

But when you look at a lot of average-case code, the near-equivalence of 'foo and foo becomes a feature instead of a bug:

parse [apple banana banana] ['apple some 'banana]
parse [apple banana banana] [@apple some @banana]

Maybe so long as you make sure QUOTE is always available as an option to fall back on, it’s not so bad. 'd' is terrible, but quote d' is legible. Escaping is a hard general problem, that pops up everywhere…you can write http://http.http//http.http.

Anyway, reason I bring it up is mostly that when you give some of these ideas a try you notice things that lead to thinking that creates the “real” better answer. Or at least you find the disproof that makes you settle on holding your peace.

Whatever comes of @, I am eager to see it used for “pointing at”:

 func [param] [fail "An error which indicates this line"]
 func [param] [fail @param "An error which indicates the callsite"]

So it needs to have a binding.

could the # symbol be used to denote a lit-word? It’s very eye-grabbing.

I’ve become a big fan of using #issues in places that do not intend to look up places, because the fact that they don’t decay in the evaluator increases their usability for that purpose.

Consider something like in ZeroMQ, where a type constant is passed by WORD!. The consequence of that is that when you splice it into code, you have to take pains to unevaluate it (done there with rebUneval(), which is a fancier-shaped tool than quote for API use). But if it had been an ISSUE!, you wouldn’t have to worry as it would be completely reduced.

Similarly, I feel TAG! should be picked up in a lot of places people casually use LIT-WORD!s today. It puts more diversity in the source and helps hint that you aren’t dereferencing.

If @foo is in the same family as foo@bar, then it would be inert, and give another one of these categories. It’s probably the right thing to do. But I had to get the thought of using it for quoting out in the open, even if just to shoot it down.


#4

@hostilefork +1 on your second post.