Are GET-WORD!s Too Ugly? :FOO vs. $FOO

Development Datatypes
1

When looking at bash, you can see it doing things that look nice and light:

# bash code
echo "Installed Version: $ANDROID_NDK_VERSION for the NDK"

Rebol isn't terrible:

; Rebol version
print ["Installed Version:" ANDROID_NDK_VERSION "for the NDK"]

But I'm becoming a believer that we should be thinking about offering versions that start by taking the words you write at face value, and marking the substitutions. That would suggest perhaps offering an echo like:

; A Rebol Echo with literal tendencies
echo [Installed Version: (ANDROID_NDK_VERSION) for the NDK]

But I've mentioned that even GROUP!s might want to be literal in such contexts for the default case (I often use parentheses in writing English, as I'm doing here). So perhaps a GET-WORD! would be more appropriate:

echo [Installed Version: :ANDROID_NDK_VERSION for the NDK]

That looks a bit unsatisfying. Beyond looking bad, it doesn't really call your attention to the escaping.
But it raises to my attention something that's just sort of generally true as a whole... GET-WORD! is unsatisfiying.

Leading colon, I've never liked you...

I've never liked the way x: :y looks. It doesn't have a good vibe...especially when you put a get right after a set like that.

We don't put colons in front of things in English, like, ever. While there's some amount of abstract symmetry to "colon in back means set, colon in front means get", we don't have to be a slave to that. If pure symbolic reversal were the way to invert meanings we'd use SET to set and TES to get. :-/

Is there a truly good reason not to use $FOO, $FOO/BAR, and $(FOO) for the "get" versions of things? It would still be a GET-WORD!, and could still be called that.

>> test: does [10]

>> type of first [$test]
== #[datatype! get-word!]

>> type of test
== #[datatype! integer!]

>> type of $test
== #[datatype! action!]

And for compatibility, we could make :foo load as $foo for the foreseeable future.

But as a dialecting component, I think it would be something a lot more people would want to use.

echo [Installed Version: $ANDROID_NDK_VERSION for the NDK]

And I think it actually looks better than the bash, with the brackets instead of quotes:

echo "Installed Version: $ANDROID_NDK_VERSION for the NDK"

Breaks One Experiment: The Shell Dialect

This would break one idea I had, which was to let a lone $ be a WORD!, so we could use it for shell commands.

print "Writing normal code here"
$ ls -alF  ; processes to end of line by default
print "Done calling out to shell

But $ couldn't be a WORD!, as $/foo would be ambiguous. You can't tell if that's a GET-PATH! of the path /foo, or a plain PATH! of the word $ with foo picked out of it. :frowning:

I can't think of any particular tricks here.

Now That I See It, I Can't Un-See It

Leading colon on words is ugly.

I've always found myself underwhelmed by the idea of using it in dialects.

The simple change of using dollar sign for this seems to give a tool for standing up against the likes of bash. Once we're past a compatibility period, maybe :foo could be another text type. Or maybe just a URL! with no scheme?

Thoughts?

2

We put dollar signs before numbers in English, not before words, at least I thought so.
:wink:

And should it be &foo not $foo ?

3

If we were to go with the idea of $ for get, then it would mean that & would be taken for binaries.

I had been favoring ${decafbad} for binary, but if $ was used for GET-XXX that would be too much of an overload.

It's still a "before" thing. I think it looks better, and especially juxtaposed against a SET-WORD!, as I point out.

It would be less subtle, in situations like an APPLY:

append-stuff: specialize $append [value: [some stuff]]

Maybe what we actually want here is yet-another-sigil, and have both. ?

foo: -> SET-WORD!
:foo -> GET-WORD!
@foo -> (SYM-WORD!, LIT-WORD!, ???)
$foo -> (ENV-WORD!, ???)

But if this new word type meant anything other than what GET-WORD! does, I don't know what it would do.

Maybe it could be particular in guaranteeing that the thing it got was not a function? This would make it a replacement for what I was proposing that foo. would do in tuples. And it might go along well with the idea of substituting variables in these kinds of expressions.

Or maybe it would implicitly turn whatever it had into TEXT! That might be interesting.

4

I've always liked the sigil # for interpolating variables in text/markup.

print ["Installed Version:" #ANDROID_NDK_VERSION "for the NDK"]

Both # and @ seem natural to me for variable forms, and they stand out easily in what are typically "noisy" surroundings.

I suppose if you come from a *nix or Perl background, the $ will be more familiar, but this is one of those cases where your opinion will be influenced by whichever language/OS you learned first.

5

I've gone in on the # for characters and issues, which is consistent with history. They can't have bindings at the moment, because of the illegal variable names they'd make...like #":". So they're not a good fit for variables.

@ is a symbolic type. It was defaulting to carrying a binding and being inert, but dialects are certainly changing that.

We might argue that dialects like CALL and ===, and FORM, and SHELL... (?) are all cases where they'd mean "get the variable".

echo [Installed Version: @ANDROID_NDK_VERSION for the NDK]

I'd already suggested in PARSE that @ means "get the variable and match it as is". So @block wouldn't mean "use the block as a rule", it would mean match this to a BLOCK! that is equal in the input. That's precedence for meaning "fetch" and being get-like, just with a different spin in the dialect.

One advantage of leaving $ alone is that it would make it more obvious when you were slipping into bash territory.

One way or another, the current GET-WORD! is unsuitable for this purpose of escaping raw words/paths/commas when they're acting as inert display elements.

Maybe we can try @ out for starters and see what comes out of it.

6

I don't have a problem with $, by the way. I'm sure it would be old-hat within no time. The only thing that gives me (slight) pause is that it's a departure from more standard rebol syntax. Well that and the possible newbie confusion with MONEY!, but when you look at it it's not all that confusing.

7

I propose things just to see how they sound, it's a start of a line of argumentation and you see where it goes. As in things like the comment discussion, it usually leads to some sort of observation... like "hey, space comments off of things by two spaces instead of one, and that fixes it".

While I don't like the pattern x: :y, you can write a lot of ugly things in Rebol. Maybe you should say x: get 'y instead if that juxtaposition bothers you.

I do somewhat like the subtlety of specialize :foo [...] as opposed to specialize $foo [...].

It might be worth it to have a $xxx $(yyy) $zzz/zzz $[qqq] types in the menagerie, maybe in addition to the GET-SET-SYM