Symbol WORD!s for Things Like $ or $$

I had solid reasons for why I didn't want the slash character (/) to be a WORD!, which I think are panning out pretty well. Its properties of being a PATH! with a blank on the left and a blank on the right help it merge into the general logic of path handling. The trick that lets it act like a WORD! when used in evaluative contexts is holding up fairly well.

But I've suggested a very powerful argument for % and %%. And there's not really the same reason for why something like $ or $$ can't be a WORD!. These aren't in conflict with an array delimiter the way slash was, so they simply aren't in the same problem space.

As with my proposed use of %%, the combinatorics of being able to operate on an arbitrary structure gives tremendous power. You can define all the dialected variations, and with quoting you can get tight representations like $ WORD and $ (GR O UP) and $ [BL O CK]

One application I was thinking of for plain $ was to look up environment variables. This would be of tremendous use in shell scripting.

 >> $ HOME
 == "/home/hostilefork"

 >> $ (fourth [NO PLACE LIKE HOME])
 == "/home/hostilefork"

You could even imagine it being a variadic, letting you set the environment as well:

 >> $ CLEVEREST_INTERPRETER: "/home/hostilefork/ren-c"
 == "/home/hostilefork/ren-c"

 >> $ CLEVEREST_INTERPRETER
 == "/home/hostilefork/ren-c"

Of course if you're not shell scripting, you might want to define it for something else. But that just seems like too much of a killer example to not have available.

It could get even more fun than that. Remember the most vexing evaluation? How about letting the left-quote of lambda override the right escapable quote, and saying that you can pass $ a function which enumerates over all the environment variables...

 >> $ [key value] -> [  ; should lambda allow `key/value -> [...]` ?
          print [key "=>" mold value]
      ]
 HOME => "/home/hostilefork"
 CLEVEREST_INTERPRETER => "/home/hostilefork/ren-c"

How Many Symbols Should We Take?

This is where things start to get fuzzy.

I feel like a$b is asking for trouble. But if $$ and %% are legal, should $% be legal? %$ should be a file.

We can even ask if taking %% is too aggressive, as files beginning with % might be common when unicode escaping is taken into account. But I think the tradeoff of having to say %"%" is worth it, and perhaps all files with % in them should need to be in quotes.

I've been wanting @ for a datatype so that modal parameters can be used at callsites without a GROUP. That would preclude its usage as a WORD! operator.

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

There's discussion in Red gitter at the moment about caret (^), and if it looks better for exponentiation than **. I agree ** is poor for exponentiation and it has other better uses. But if caret is used for escaping, you don't want it to become an operator that people use in commonplace code.

So when I look at the keyboard, this really does seem to be about $, $$, and %, %%.

I've wondered if the allowance of vertical bar in mid-word is misguided, since a|b makes a fairly bad "word!". If it were restricted to arrow-words like |> and | and ||| that might be wise. It could even leave room for a notation of "words with spaces", which we have discussed:

 >> word? '|word with spaces|
 == #[true]

We'd have to get comfortable with the idea that || would be a word spelled "||" and not a word with no content, but that doesn't seem to be something all that hard to get around...compared with the general larger issues surrounding what allowing words-with-spaces would mean (and what sort of confusion and bad habits it would cause).

Conservatively, I'd say we should rule out vertical bars in non-arrow words for now.

Any thoughts? (besides "wow that environment variable operator sounds awesome!")

2 Likes

wow that environment variable operator sounds awesome!

:slight_smile:

On my keyboard i have & and paragraph symbol very exposed as well, though the last one not on my phone as I notice right now.

Yes great thing that environment variable!

:smiley:

And besides that I feel that Dollar(sign) will be replaced by the Euro (sign) soon, money type will be representing Euro.