Using Apostrophes in Names: What Happens When You Quote?

Apostrophes have been on the rise purposefully in names also throws. Not only is there isn't and didn'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''

2022 UPDATE: Terminal apostrophes in variable names is also a common practice now to indicate a variable holds a meta quantity.

Might There Be An Alternative Choice For QUOTED! ?

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. This is kind of slight:

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

But What About... the Neglected Backslash?

Backslash is currently unused. We've thrown around ideas for backslash from time to time. It was the original expression barrier concept, before | took that over.

Despite its common uses for escaping in other languages and mediums, it's never come up as the idea for being the generic literal escape. But, it actually seems pretty well-suited to it.

Looking at some options with unused characters:

UPDATE 2022: Uses for @ and ^ are now more or less "set in stone" (to the extent anything in Ren-C ever is)

if word = \isn't [...]
if word = 'isn't [...]
if word = ^isn't [...]
if word = @isn't [...]

if string = \"something" [...]
if string = '"something" [...]
if string = ^"something" [...]
if string = @"something" [...]

>> compose [(1 + 2) \(1 + 2) \\(1 + 2)]
== [3 (1 + 2) \(1 + 2)]

block: [a b c]
switch block [
    \[a b c] [print "literal match!"]


  • Doubled-up usage can't be visually confused with another symbol (like how two apostrophes look like quotes, or an apostrophe and quotes can look like quotes and an apostrophe)
  • It doesn't require shift to type on most keyboards (though a little bit of a pinky-reach)
  • Known usage for escaping in other languages

(Note: The benefit of it being used for escaping in other mediums also makes it a bit of a drawback, as when you're typing in code in some text or markdown environment and use a backslash it can trip it up...because it thinks you're trying to escape. Of course you run into that problem with any code... like typing * and having it think you're trying to bold something, etc. Still, backslashes can be one of the trickiest things to get these mediums to actually display how you want.)

Caret isn't bad-looking either. But the big problem with caret is that you don't want the escaping method used for weird characters in strings to interact with commonly-used characters in code. Because code is often carried in strings (or molded to it, etc.) It's best if caret occurrences are few and far-between, but literals would be a lot of places. You've got to diversify your escaping mechanisms, otherwise you have to escape your escapes more often.

Radical Brainstorm: Beginning And End For Quotes

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 "{".

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.

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.

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

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 bind, 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 rebQ()). 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 quoted WORD!s today. It puts more diversity in the source and helps hint that you aren't dereferencing.

@hostilefork +1 on your second post.

A post was merged into an existing topic: QUOTED! arrives (formerly known as "lit bit")

I've buried the hatchet, and stopped questioning apostrophe for quotes. I accept it for the purpose it was originally intended.

The acceptance is based on three premises.

First, accept apostrophe's slight appearance as a benefit

In @rgchris's words:

"I am a member of the apostrophe fan club--I think its inherent discretion is part of what makes Rebol a more elegant language."

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]

Secondly, use THE for literal forms in the source

 if word = the isn't [...]

It may be that even the quoted values could find an alternate how "^"" will be picked to render as {"} by molding. So perhaps 'isn't or ''double-quoted-double-primed'' could have some options too.

UPDATE 2022: Indeed, this is the case with weird WORD!s... you use vertical bars!

>> '|isn't|
== isn't

>> ''|double-quoted-double-primed''|
== '|double-quoted-double-primed''|

Thirdly, stop using WORD! for enumerations.

If you used something weightier like an ISSUE!, the fact that apostrophe is so skinny wouldn't come up.

 switch mode [
     'read [print "too skinny!"]
     #read [print "better..."]
     <read> [print "also better..."]
     %read [print "fine too."]
     @read [print "coming someday..."]

If you only use words when you need evaluation, you'll need escaping less. And you'll be doing yourself a favor in COMPOSE situations where you won't constantly have to be worrying about the word getting its quote knocked off and then evaluating in some other situation.

The full post announcing the "finalized" (cough) generic quoting mechanism is here:

1 Like

A post was split to a new topic: Should We Point The Blame in FAIL With "@"?