The Great THE Operator!

In Ren-C, THE is a really well-named choice for something that evaluates literally to its argument:

>> the word
== word

>> the (1 + 2)
== (1 + 2)

Historical Redbol called that "quote". But in Ren-C, QUOTE means something altogether different... it means add a generalized quoting level to the evaluated argument:

>> quote 10
== '10

>> x: 10

>> quote x
== '10

>> quote x + 20
== '30

>> quote quote x
== ''10

>> quote/depth [a block] 3
== '''[a block]

I can't think of a better name for that than QUOTE!

(Note: I had thought the name wouldn't matter that much since generic quoting would mean you'd nearly never use it. However, quoting has other effects which means we probably want to encourage people not to use evaluative quoting of GROUP!s/etc. unless they are sure they know what they're doing...)

For History Buffs: the Excruciating Long Path to Picking THE

In retrospect, THE seems great and short (and obvious?) for generating a literal value. But when QUOTE had been ruled out, it was actually a bumpy naming road across a bunch of not great options.

First there was LITERAL:

>> literal x
== x

But when you give an operation a noun name, then it competes with when you might want a variable to hold that. So if you have a list of "literals" you might say for-each literal literals [...]. I had an idea to work around this by calling it LITERALLY:

>> literally x
== x

But both LITERAL and LITERALLY feel too long, so it was abbreviated as LIT:

>> lit x
== x

The word JUST came up for another application, but its brevity made it feel like it might be a fit. But once THE came on the scene, it was the better choice...freeing up JUST for what it was meant to do in the first place!

2 Likes

I always look at lit as in the light, as in the room was nicely lit. Or it has been set on fire :thinking:.

As much as I like THE...

I've been looking at the roles of the three Sigil'd operators:

  • $ - we can now call this "the BIND operator", because BIND is arity-1... meaning "bind in this context"

  • ^ - we can now call this "the IDENTITY operator", because IDENTITY is a vanishable function (a property that only matters in sequential eval-steps...)

And then, there's:

  • @ - a shorthand for a literalizing operator, that gives you the following item "as-is" with no binding applied.

Something makes me uncomfortable about [BIND IDENTITY THE]

One of those things is not like the others.

So what I'm tempted to do here, is say that's [BIND IDENTITY LITERALLY]

>> append [a b c] literally d
== [a b c d]

I prefer LITERALLY to LITERAL.

>> append [a b c] literal d
== [a b c d]

Literal is nounish. "Pass a literal to that function".

I'm okay with LIT being a shorthand for LITERALLY, but wouldn't put LITERAL in the box:

>> append [a b c] lit d
== [a b c d]

And given what I've just said, there's an even shorter shorthand:

>> append [a b c] @ d
== [a b c d]

THE Can Stick around, as BIND LITERALLY

>> x: 10

>> get literally x
** PANIC: x not bound

>> get bind literally x
== 10

>> get bind lit x
== 10

>> get the x
== 10

And of course you could say get $ @ x if the occasion warranted it (API code uses @ heavily)