We have a number of "things" in the language: function names, a literal false value, user-defined symbols... the question is, does it make sense to use one representation for these, or to create several disjoint types?
Part of the power of Lisp is the ease of treating programs as data, to create, generate, and manipulate code with code, making Lisp as they say a "programmable programming language".
Representing all the tokens of the language as symbols simplifies manipulating code since we don't need separately recognize symbols vs. booleans.
Someone who feels that well defined, disjoint types are important to correctly reasoning about programs might prefer to have separate symbol and boolean types. But I would ask, "how does this help me actually write shorter programs?"
I don't have a problem with nil being a symbol, but speaking of writing shorter programs, I can't think of a single time I've actually needed to coerce nil/null to a string in any language except when printing it out for debugging purposes, and even then, in Arc:
(is "nil" (tostring pr.nil)) ; because 'nil is sent to MzScheme's 'display
So when...
(is "" string.nil) ; because 'coerce special-cases 'nil to do this
...I'm taken by surprise, and I'm not sure where this discrepancy would pay off in brevity.
I suppose string-returning procedures that need to be convenient in boolean contexts can return nil instead of "" and expect anyone who calls them to wrap them up as string:foo in string contexts... but even so, I can't think of any practical examples of when doing that would be shorter than having the procedures return only strings and wrapping them up as ~empty:foo in boolean contexts.
Is there some brilliant use of (is "" string.nil) I'm not thinking of?
