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

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: 18 Jul 88 20:31:02 PDT
    From: masinter.pa@Xerox.COM

    My general goal is to try to standardize current practice, and reduce needless
    divergence. As far as I can tell, there are lots of both case sensitive and case
    insensitive file systems around. We might be lucky if we can 

    a) standardize how pathnames work when talking to various kinds of operating
    systems (e.g., all Unix Common Lisps should use file names the same way) and

    b) give users some guidelines on how to write portable code given that there are
    inevitable differences.

Speaking now with my user's hat on, I must say that I think this is a
complete whimp-out.

The plain fact is that programmers need MUCH more than a&b, and we are capable
of providing it. Current practice is that there are at least some implementations
which deal exceedingly well with a lot of kinds of operating systems in the
same environment. If we cannot select and standardize on one of those models, it
seems clear to me that the reasons are political and not technical.

    Certainly a proposal that mandates an "unnatural" interface between Lisp and the
    host operating system will be rejected by the operating system vendors.

I can't tell if this remark about unnaturalness alludes to my proposal,
but I'll assume it does and reply on that premise...

I don't intend to propose an "unnatural" interface between Lisp and the
host operating system. In fact, I don't see the functions I'm proposing changing
as part of the interface between Lisp and the operating system. I see them as
an interface to an abstract operating system.

The purpose of the pathname system seems to me to have been to abstract away
 from operating systems a bit and provide a portable file system model which
was device independent.

For example, we typically parse out `type' information where there
really is none on Unix. That idea is in some sense unnatural to Unix, but it
is not unnatural to the idea of a file system, and CL programmers thought it
would be useful. So we created a model and users seem happy with it because
it provides them something of value.

Issues of case are completely non-trivial to writers of portable code. The
proposed solution does not intend to slight any host operating system. The
idea is to say that there is a partition in the file system interface:

A pathname is an abstract representation of a filename. It contains
information in its slots which ties it to a particular host file system,
but it is designed in such a way that it can be manipulated with minimum
regard for the particular characteristics of the host operating system. 
The MAKE-PATHNAME operation creates pathnames.
    
PATHNAME-HOST, PATHNAME-DEVICE, etc. access the abstract representation.

A namestring is a concrete representation of a filename. Since
namestrings are not portable, a namestring is rarely part of a program
and is more commonly the result of user typein or of an operation such
as NAMESTRING which coerces a pathname to its native string
representation.

An Idea

In some ways this smells of the FIXNUM issue. Perhaps the problem is
partly just that you have interesting functionality that you don't want
to lose and I can talk you into just `saying what you mean.' Currently
there are two arguably desirable pieces of functionality, and only one
name. Maybe if there were two names, we could make one name refer to what
Scott wants and one name refer to what I want.

In Genera, you can do (SEND pathname :RAW-NAME), etc. to see the
host-specific values, but hardly anyone ever does this in any code I've
ever seen. I would be willing to extend the proposal in any of the
following ways if it would make it more palatable to anyone:

 (a) Add functions PATHNAME-RAW-DEVICE, PATHNAME-RAW-DIRECTORY, 
     PATHNAME-RAW-NAME, PATHNAME-RAW-TYPE, PATHNAME-RAW-VERSION.
     [We could use "NATIVE" instead of "RAW" if people found that more
      appealing. It is longer, though.]

 (b) Add an optional NATIVE-P argument which controlled case translation
     and such in the PATHNAME-xxx accessors. For the sake of portability,
     I would definitely want this argument to default to NIL (meaning that
     the default was to return a canonicalized value, but that it could
     be overridden to inhibit this behavior by people that wanted it).

There are also a couple of interesting variants of (a) which we could
even play with:

 (a1) Make functions FILENAME-HOST, FILENAME-DEVICE, etc. which were like
     PATHNAME-HOST, etc. except:
	- They would accept any argument that was coerceable to a
	  pathname.
	- They would return the argument in native form.
     eg, (FILENAME-NAME "/foo/bar.lisp") => "bar" on Unix

 (a2) Extend the set of functions like FILE-NAMESTRING to include
      NAME-NAMESTRING, TYPE-NAMESTRING, and VERSION-NAMESTRING so that
      it would be more easily possible to pick apart namestrings.

These latter two, especially a1, have the version of making the -raw-
things feel perhaps less like second-class citizens. [Personally, I don't
really care if they are second-class citizens because in my view they
really are. CL is supposed to be a portable language, and I'm content to
provide non-portable features only to the extent that it doesn't get in
the way of providing portable ones. In this case, the names PATHNAME-NAME,
etc. have a right (I feel) to the portable semantics. As long as we don't
muck with that, I'm content to provide whatever else is necessary to
make others happy.]

Aside to Fahlman: I don't think voting rights have much to do with
anything in this forum, so I wouldn't worry about that. I'm happy to
hear your opinion when you're willing (as you were) to elaborate on
your fears enough that we can have a technical discussion.