[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DEFAULT-CASE
- To: David A. Moon <franz!ucbarpa!STONY-BROOK.SCRC.Symbolics.COM!Moon>
- Subject: Re: DEFAULT-CASE
- From: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
- Date: Thu, 16 Mar 89 21:38:14 PST
- Cc: franz!sail.stanford.edu!CL-Cleanup
- In-reply-to: Your message of Thu, 16 Mar 89 18:15:00 EST. <19890316231500.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
I'm not trying to start a religious war. I'm not saying that
case-sensitive is better or worse than case-insensitive. I'm just
saying that there are large numbers of people who favor each position
and that Common Lisp should support both.
Regarding internal vrs external: The internal representation shows
through in a number of places. For example the functions symbol-name
and make-symbol let the user deal with the actual internal
representation of the names of symbols. The idea of having a
*print-case* value that inverts the case on output is interesting but
that would make things awkward: To make the symbol FooBar you
would have to (make-symbol "fOObAR"). Also examining the characters
of a print-name with aref would give confusing results.
>> I also claim that the choice of case in internal representation
>> is arbitrary and need not prejudice the external representation
>> at all.
For a case-insensitive Lisp I completely agree. For a case-sensitive
Lisp, as I've shown above, this just isn't true. Thus if the needs
of the case-sensitive Lisp are met, then the needs of both are met.
-john foderaro
[it might be interesting to explore the possiblity of explicitly
stating that the internal representation of print-names was undefined
with respect to case, and further providing two new functions: one
which took a string and converted it to the internal representation
just as the reader would do and the other which took a symbol-name
and converted it to a string just as the printer would do.
I suspect that this would lead to programs that worked on a few
Common Lisps but failed on others due to accidental reliance on the
actual case of the printnames. ]
- References:
- DEFAULT-CASE
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>