Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)

[Scott.Fahlman@B.GP.CS.CMU.EDU]

Dave,

I think that the problem here is that we see rather different classes of
programs and programmers.  At Symbolics and some of the big toolkit
vendors, most of the code that is written has to be portable to all known
file systems.  You people big, nasty portability problems to solve and you
want better tools for this.  If that means that lots of existing code has
to be broken and extremely counter-intuitive conventions have to be
adopted, well, that's a small price to pay.  And to you it seems obvious
that the case-hacking versions of of the pathname functions should get the
good names, since any code that is not portable to every known file system
is "second-class", to use KMP's label.

I see a different environment.  When I'm writing application code for my
own use, or for that of my colleagues at CMU, I want that code to be
portable across several different Common Lisp systems, but all of the file
systems around here are unix-like in their treatment of case.  In the
unlikely event that anyone wants to port this code to a TOPS-20 system,
they'll have to spend ten minutes fixing up a few pathname fields; I'm not
going to worry about that right now.  I'm not opposed to making things
portable across very different file systems, but I put a lower value on
this than the people who do it for a living.  I don't want to achieve this
goal in a way that breaks a lot of existing code and that uses syntactic
conventions that are going to confuse Lispers for generations to come.  I'm
not alone -- lots of people are working in environments where all the file
systems are similar in their treatment of case.

OK, let's accept that we need to solve this portable-case problem and see
if there is some less obnoxious way to do it.  Some ideas:

1. Nobody has responded to my suggestion that we add a :CANONICAL-CASE
keyword to MAKE-PATHNAME, which defaults to NIL.  If non-nil, this says
that all the field-name string are to be converted to canonical case.  If
we do it this way, we break no existing code.  New users and those writing
non-portable code would leave this off, and their field-name strings would
not change case in mysterious ways.  This would eliminate most of the
potential confusion I described in my previous note.

2. Same suggestion, but a non-nil :CANONICAL-CASE argument says to process
the fields the way KMP proposes: canonicalize, anti-canonicalize, or keep
the string as-is, depending on its case.  This gives us more flexibility
that option 1, though it is more complicated.  Again, this breaks no
existing code, and mysterious case-conversions don't happen until you ask
for them; at that point, you'd better have read the manual.  I suppose that
the accessor functions for pathname fields also need a keyword or optional
arg saying to do the hairy case conversions.

3. Make two sets of functions, one set handling the field names verbatim
and the other doing Symbolics-style case conversion.  But leave the good
names (the current ones) with the current non-converting definitions.
Again, we break no existing code and naive users are less likely to land in
the deep guano.  Sophisticated users writing ultra-portable code might have
to type a little more, but not a lot more, and such people are probably
clever enough to use word-abbrev mode.

I could live pretty happily with any of these three solutions; I'm still
pretty unhappy with the original proposal, despite the claim that Symbolics
and maybe TI users have learned to live with this system.  Have you
actually polled the people who get bug reports and who teach Lisp to your
new users to see if this convention is causing confusion?

-- Scott