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

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

I support the proposal (PATHNAME-COMPONENT-CASE:CANONICALIZE).  I think
current practice in the Symbolics Genera system (and I believe in the TI
Explorer system as well) has shown that this approach is very viable for
dealing portably with a wide range of file systems.  The choice of upper
rather than lower case as the canonical case is of course arbitrary; a
justification of upper case is for consistency with Common Lisp symbols.
I agree with Kent that if this situation is not straightened out, pathnames
are not very useful for portable programs, and that straightening out the
situation will be a big help in that respect.

I would also support a variant of this proposal that augmented the
portable pathname constructor and accessors with a native constructor
and accessors, either with different names or as additional arguments to
the same-named functions.  I assume Kent left the native constructor and
accessors out of his original proposal because he wanted to keep it lean
and omit unnecessary complications.  However, if Scott feels they should
be included, I'm happy to let them be included.  I agree with Kent that
in practice the portable operations are used much more commonly than the
native operations.  I believe this is because programs that work in
terms of native pathnames typically use namestrings and do not access
pathname components at all.

    Date: Wed, 20 Jul 88 19:13:13 BST
    From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
    
    I guess I don't understand this point, because I don't see that pathnames
    are all that portable.  Aren't the files usually in a different place on
    different machines....

I have to comment on this, because it's a common misconception.
Actually there are two points that have to be made.  First, we are not
talking about making pathnames portable, we are talking about making
pathname-manipulating programs portable.  That's a big difference!  The
point is to provide portable ways to perform the operations whose
details vary across file systems.  In fact that is the -only- point of
pathnames; if we didn't want to do that, we would just use strings and
manipulate them with string operations.  The pathname abstraction was
introduced solely to make pathname-manipulating programs portable.

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.  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 that implement the imaginary file system by mapping it into
a real file system.  Any namestring embedded in a program ought to be
a logical namestring if one expects that program to be at all portable.