| Would have been interesting to hear PG's thoughts on unifying characters, strings AND symbols... Here are my 2 cents': - A string would be either the empty string, or a non-empty sequence of strings of length 1. - A string would also have an _associated value_ (nil by default), that can be of any type (including functions, macros, special forms or other strings). A string would then also be a key-value pair, and a keyed hashtable could be treated conceptually as a collection of strings with no duplicates. - A non-whitespace, no-paren (alphanumeric?) string will return its associated value (= be evaluated) in an Arc expression if you _don't quote it_, making such unquoted strings convenient for using as variable or function names. In addition, if such an unquoted string immediately follows a left-paren in an Arc expression, its value will be treated as a function and applied. (All this is different for special forms and macros, of course.) - To quote a string, you would use double-quotes around it, to keep it from being evaluated, and returning itself rather than its associated value. Quoted strings are then string literals, and in this usage, the associated value will often be nil. String literals of length 1 are used as character literals. - A non-whitespace, no-paren (alphanumeric?) string can alternatively be quoted by prepending a single-quote, in the same manner that you quote a composite Arc expression by prepending a single-quote before the leading left-paren. If you intend to use the associated value of the string, this is the preferred way of quoting it (for clarity). - To return the associated value for a string that includes whitespace or parens (or non-alphanumeric parts?), you would have to do explicit evaluation by using eval with the double-quoted string. This would discourage (but not disallow) using such strings for variables and definitions. I'm guessing this proposal is inconsistent and unworkable, but I'm throwing it out there anyway... | 
