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

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

    Can you elaborate on the kind of ``confusion and paralysis of truly
    awsome proportions'' you expect?
    
Sure.  I expect to see several hundred spurious bug reports of the form "I
told Lisp to replace the extension of this file with `foo' and for some
unknown reason it insisted on producing `filename.FOO'.  That's the form
the spurious report would take for people on lower-case systems like Unix
-- others would have a slightly different problem.

I agree that it would be nice if everyone read the manual, but if a feature
of the language is sufficiently non-intuitive, people are going to be
burned even if there's a warning in red letters -- they'll just refuse to
believe that the language designers could have been so perverse.  Suppose
we decided that it would be useful to represent positive integers as "-n"
and negative integers as "+n".  Do you think that documenting this decision
would turn it into good language design?  I think not, but you are
proposing to tell Unix-based users, and lots of others, that for them "FOO"
means you want lower case in the filename and "foo" means you want upper
case.

As you point out, this would an effectively incompatible change in a part
of the language that is used moderately heavily, though usually for rather
simple tasks.  A lot of users regard most of the pathname stuff as bizarre
nonsense that they really don't want to understand, but they have learned
to do a few simple things (e.g. moving files between directories and
changing file extensions) by rote.  Only a few sophisticated users are
concerned with writing code that works across many systems with radically
different file-naming conventions.  If we can give these sophisticated
users a better way in which to do their job, fine, but I don't think we
should accomplish this by screwing the people who have existing code that
solves their little file problems within, say, an all-Unix environment and
who never plan to export their code to Tenex.  (I hope you aren't going to
reply that such people deserve to be screwed, since they should not be
writing nasty non-portable code.)

    Can you also give a couple examples of what you consider portable
    uses of the current paradigm which do not involve the use of READ-LINE
    in order to obtain a namestring in the first place?
    
No.  I think that the existing pathname stuff is pretty much a dead loss
for this purpose due to the problem you describe and several others.  If it
were up to me, we'd toss this pathname mess out and start over, but it's
too late for that.  If we can patch over the worst of these problems, fine,
that's useful.  I'm not arguing with your goals.  I just don't think we
have to do this in a way that breaks existing code and that will stand
forever as a textbook example of counter-intuitive language design.

Aside from my distaste for a system in which "foo" means "FOO" and
vice-versa, I do have one technical objection to your proposal: unless I've
missed something, there's no way to specify that you want some string to be
used verbatim, regardless of the target system, unless that string happens
to be of mixed case.  I guess in unix the "canonical" case is lower, but
sometimes you want to specify a file whose name is something like
"foo.BAR".  So if we overload the field-value strings to signal
case-canonicalization, we need some way to quote these strings and say
"this is really what I want, so leave it alone".

Would it suffice to add a :CANONICALIZE-CASE keyword to MAKE-PATHNAME for
those few users who really are trying to write code that will run on all
known systems?  That would be an upward compatible change.  If we need
field-by-field control of case-canonicalization, I think that the
CANONICALIZE-CASE function I proposed earlier does the job quite well, even
if it is a bit verbose.  I'd rather have a form that states that this
canonicalization is going on than to surprise naive users by doing it when
they are not expecting it.  Alternatively we could try to work out the
syntax for a new function or macro, MAKE-PORTABLE-PATHNAME, that
accompanies each field specifier with a flag of some sort indicating how
the case is to be treated.

    The pathname
    system from which I took the idea for this proposal is one of very few I
    know of which has tried this approach and demonstrated it to be workable in
    the face of numerous operating systems. Frankly, the only comments I've ever
    heard numerous users of the Symbolics pathname system were ones of astonishment
    at how well that aspect of the lisp machine pathname system works. So it
    seems to me that the facts are in direct opposition to your ``doom and gloom''
    prediction. Do you contest this claim or practical experience to the contrary
    which you would like to share?
    
No, I'm just flaming, based on instrospection and my rough model of how
naive users are likely to think; I haven't run any experiments.  If you
tell me that Symbolics already uses the system that you propose and that
the users are unanimous in their praise of it, I guess I'll have to accept
that, surprising as it may be.  I know that I personally would find it
confusing to write "foo" when I mean "FOO" and vice versa, but then I've
always been kind of slow at catching onto these advanced programming
concepts.  Maybe I'm the only one with this hangup, or maybe I'm typical
and the Symbolics user community has learned not to complain about things
that seem overly complex and counter-intuitive.

Some other views would be useful at this point.  If the rest of you think
that KMP's proposed change is the most intutive way to handle this case
problem, I'll shut up -- I no longer have formal voting rights in any case.

-- Scott