[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
- To: CL-Cleanup@SAIL.STANFORD.EDU
- Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
- From: Scott.Fahlman@B.GP.CS.CMU.EDU
- Date: Thu, 21 Jul 88 16:00:02 EDT
- In-reply-to: Your message of Thu, 21 Jul 88 11:23:00 -0400. <19880721152341.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 21 Jul 88 01:06:44 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
....If we do it this way, we break no existing code....
You mean we break none of -your- existing code. The only way to break no
existing code is to retain the unsatisfactory status quo. Since CLtL is
not specific here, different implementations have resolved the ambiguity
in different ways, and if they are to be made all to work the same way,
some existing code will have to change.
Well, what I really meant was that we break no existing Common Lisp code,
where by "Common Lisp" code I mean code written according to any reasonably
straightforward interpretation of what is in the manual. It hadn't
occurred to me that you folks at Symbolics consider the system describeed
by KMP to be in compliance with CLtL and not an extension -- a worthwhile
extension and perhaps even a necessary extension, given the problems you
want to solve. KMP did label his proposal a "change" rather than a
"clarification", though I see that he claims in the discussion section that
it is technically in compliance with CLtL. I have some doubts about
that claim, but let's not argue about that.
So, as you say, some of us are going to have to fix some existing code if
we try to standardize this situation. If we have a way -- either a switch
or a separate set of functions -- to select either canonicalizing or
verbatim interpretations, whoever has to change his code can do so with a
simple editor macro.
So the only thing we're really fighting about is who gets the good function
names or the default version of switchable functions. I still think that
the princple of least astonishment suggests that these field names ought to
be used verbatim unless the user specifically asks for canonicalization of
case. We can make it easy to ask for the canonicalizing behavior (my
proposal 2 does that), but it shouldn't be the default.
One other suggestion: Whether we go with KMP's proposal or something like
my proposal 2, I think that we should use all-lower-case to indicate
canonical case, and all-upper to indicate anti-canonical case. As someone
pointed out in an earlier message, this choice is arbitrary. Other things
being equal, we may as well go with the arbitrary choice Symbolics made,
but other things are not equal. Unix, the herpes of operating systems, is
still spreading and is going to be the file system most Lisps have to deal
with for at least the next 5 years, and probably 10. Tops-20 is almost
dead, and I don't know of any other default-upper-case file systems that
are on the rise, at least in the communities to whom Lisp is important. So
let's make the choice that minimizes the number of people who have to type
things in a case that is the opposite from what they want. Of course, this
choice breaks some existing code, but we've already agreed that that is
necessary.
-- Scott