It occurs to me that if everything is allowed to carry a SIGIL!, then we will be getting $ on strings.
And the SIGIL!s have been pushed under CHAIN! and TUPLE! etc.
That means you should be able to write:
>> $"REN_C_DIR": "/home/hostilefork/ren-c/"
== "/home/hostilefork/ren-c/"
>> $"REN_C_DIR"
== "/home/hostilefork/ren-c/"
Since ENVIRONMENT! comes from an extension, I don't know exactly how this would get wired into the "RebindableSyntax" mechanism. SET-VAR-TEXT! wouldn't be a fundamental type... $"REN_C_DIR": is a CHAIN! with a VARFORM! (BINDFORM! ?) of a TEXT! in it followed by BLANK!.
But by hook or by crook, I want it. Environment variables are very important in many of the sorts of domains that Ren-C would be good in.
It's a little sad that environment variables don't have a mark on them as being LOAD-able syntax, e.g. strings don't have quotes on them to say they should be interpreted as text. If they did, we could round-trip types:
>> $"REN_C_DIR": %/home/hostilefork/ren-c/
== %/home/hostilefork/ren-c/
>> $"REN_C_DIR"
== %/home/hostilefork/ren-c/
>> $"BLOCKLIKE": [a <b> c]
== [a <b> c]
>> $"BLOCKLIKE"
== [a <b> c]
It may be worth having this be a higher-level layer that assumes environment variables starting with % are files, and starting with [ or ( or { are blocks/fences/groups. I don't know how far it should go. Maybe just the % as file trick is enough.