[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DEFAULT-CASE
- To: John Foderaro <franz!frisky!jkf@ucbarpa.Berkeley.EDU>
- Subject: Re: DEFAULT-CASE
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Fri, 17 Mar 89 11:44 EST
- Cc: CL-Cleanup@sail.stanford.edu
- In-reply-to: <8903170538.AA09727@frisky>
Date: Thu, 16 Mar 89 21:38:14 PST
From: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
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.
Agreed. I'm trying to help you not start a religious war.
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.
The internal representation is accessible to programs, but I don't think
it's particularly important. You seem to disagree. It might be that we
have different experience with how often these primitives are used in
portable programs. I don't think they are used enough that having an
internal representation in the opposite case from the external one would
cause bugs, but I do think they are used often enough that an incompatible
change would cause bugs in the medium term.
>> 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.
True, but if the discussion gets side-tracked by flaming controversy over
the relatively unimportant issue of internal representation, I suspect
that the only outcome will be that everyone will give up on reaching a
concensus and we will be stuck with the status quo. On the other hand,
if you compromise and keep the internal representation compatible, I
predict that you can very easily get what you really want, at the cost
of having a language 0.01% more inelegant than it would otherwise be.