Re: portability of pathnames

[NGALL@G.BBN.COM]

    Date: Sun, 22 Jun 1986  20:30 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
    To:   SANDRA <LOOSEMORE@UTAH-20.ARPA>
    Subject: portability of pathnames
    In-Reply-To: Msg of 29 May 1986  22:20-EDT from SANDRA <LOOSEMORE at UTAH-20.ARPA>
    Message-ID: <FAHLMAN.12216964464.BABYL@C.CS.CMU.EDU>
    
    
    I'm going through old mail to make a list of issues we need to settle,
    or at least work on.  I came across your complaint about portability of
    pathnames and the problems with make-pathname.  I was just wondering if
    you had anything specific to propose.  If not, I'll just add this to the
    agenda of things we collectively need to think about, but I'm not sure
    there's a good solution to be had.
    
    -- Scott
    
	      --------------------
		
I don't remeber what Sandra's suggestion was, but I have one:

On page 409 of CLtL it says, "names can be fit into a certain
canonical, implementation-independent form called a pathname."
But on page 412 it says, "What values are allowed for components of a
pathname depends, in genneral, on the pathname's host."  Given this
latter statement, it seems that the only implementation-independent
thing about the form of a pathname is that it has 6 components! (Even
this isn't totally true, since some implementations that don't support
versions may not allow assignment of anything to the version component!)

CLtL does state that there are conventions for the components.  What I
would like is for these conventions to be required.  For example, in
every implementation, one may give MAKE-PATHNAME a :type argument that
is either a string (and CLtL should specify that there are no pathname
specific restrictions on the length of the string) of NIL or :WILD
(such is currently the TYPE convention).

The host convention also makes sense.  When I say that all
implementations must accept a string of any length or, in the case of
a host, accept a list of strings, I do not mean that such a pathname
must be convertable into a legal namestring.  I merely mean that an
application should should be able to generate pathnames as it sees fit
and delay the 'legality' check until it actually wants to interface to
the file system.

For example, my application uses names that are <= 10 chars.  If I
move to a CL that supports names only <= 8 chars, I have to go through
a lot of work to port.  But if I can stuff the longer names into a
pathname legally, then a can merely wrap my file-system interface
(e.g., a call to open) with code that would convert my pathname into a
pathname that this system could handle (e.g., by using some of thje
chars avail for the TYPE).

The point I am trying to make is that pathnames really should be 100%
implementation independent, including the contents of each of the
components.  There should be no limitations on the components (e.g.,
length of strings, length of lists, whether a list is allowed in this
impl.) other than the conventions on pg. 412.  It is the conversion of
a pathname to a namestring (and vice versa) that should impose the
limitations.  And the standard should state that all pathnames are
implicity converted to host-dependent namestings before actually being
used in a file-system operation.

The one significant change to the pathname conventions will have to be
to the wording in the description of the conventions of the device,
directory, and name: "...can each be a string (with host dependent
rules on allowed characters and length) or possibly some other Common
Lisp data structure)..."  This would have to be changed to remove the
wording about "host dependent rules" (remember, these rules should
only come into play when converting to a namestring) and to flush the
legality of "some other CL data structure".  Whats wrong with just
allowing strings, lists of strings, :wild, and nil?  Does nayone use
anything else already?  Would it be that hard to switch to lists?

Finally, it should be stated that what you assign to a pathname
component is what you get back when you reference it, no implicit
conversion or copying.

This pretty much turns pathnames into merely organizers of
information, they don't process what is assigned to them, they just
store it.  It is the process of converting to a namestring that
processes the info, based on implementation independent info.

	-- Nick