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

[Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>]

Scott's porposals (1 and 2) for a :canonical-case keyword seem worth
considering, but whether 1 or 2 is better is less clear.  I'm still
not sure what anti-canonical accomplishes.  On a system that accpts
only one case, it can do nothing; on a system that accepts any case,
why change case at all?  Why not use whatever the user provides?  Some
case will be more common, but if we're trying to ignore the details of
the FS do we care?  OK, anti-canonical matters so I can still get that
case if I want it, and pathnames need to be able to represent such
namestrings.  2 then?

I do think this goes back to a question of exactly what portibility
gain is involved.  I can see that the Symbolics system does a number
of useful things, but I'm not sure how much each individual thing
does in isolation.

Moreover, pathnames are not useless without this change.  They are a
more sturctured representation than namestrings, and save one from
parsing.  Code that does not aspire to complete portability might
nonetheless use them.  There may also be code that wants to be
portable to different Unix systems, say, where the case problem will
not arise, or between different common lisps that parse namestrings
differently or single lisps that refuse to parse them "correctly"
(Unix names like ".lisprc", say, want to be merge-pathname'd as names
not types.)

> Date: Wed, 20 Jul 88 18:32 EDT
> From: "David A. Moon" <Moon@arpa.scrc-stony-brook>

> The second comment is that it is in fact both possible and useful to
> make pathnames themselves portable.  That would be the subject of a
> separate proposal.  Again, this has been current practice in both
> Symbolics and TI systems since before Common Lisp even existed, and
> works quite well.  The interested reader can consult the documentation
> of "logical pathnames" for either of those systems.

Done.

> Basically the idea is to have an imaginary file system that behaves in
> the same way everywhere, and that puts files in the same place
> everywhere.  Then at each location one defines a set of translations

Isn't this independent of pathnames per se?  (I.e., couldn't it be
done just by having a convention for namestrings?)

And I still have difficulty imagining interesting things portable
programs can do without such a convention (apart from the things
pathnames already provide, such as parsing).  Or, perhaps I should say
I have difficulty imagining interesting things made possible by the
canonical case proposal.  I can easily see the virtues of canonical
types.  But the gain from having the case made magically right seems
small.

-- Jeff