MERGE-PATHNAMES-DIRECTORY:EXTEND

[alarson@src.honeywell.com (Aaron Larson)]

I understand that there may be a proposal that deals with this topic under
discussion in Cleanup, if so I'm willing to retract this submission.

Issue:         MERGE-PATHNAMES-DIRECTORY
References:    MERGE-PATHNAMES (p415), MAKE-PATHNAME (p416),
	       PATHNAME-DIRECTORY (p417), DIRECTORY-NAMESTRING (p417)
Category:      CHANGE
Edit history:  03-Mar-89, Version 1 by ALarson

Problem description:

 Merging of pathname components currently only supports complete
 replacement.  While this is satisfactory for "simple" components such as
 type and version, the directory component on most modern operating systems
 must describe a hierarchical directory structure and as such could benefit
 from a more sophisticated merging policy.

 For example; many large software packages exist in a collection of
 directories that are related in a specific way starting at an arbitrary
 location in the directory hierarchy (e.g. the FOO package may be
 structured with ....foo/src, ....foo/bin, ....foo/doc, etc.  where "...."
 is some arbitrary directory path).  The current specification of
 MERGE-PATHNAMES does not permit the two parts of the directory component
 to be specified separately in an implementation independent manner such
 that MERGE-PATHNAMES could construct the entire directory path.


Proposal MERGE-PATHNAMES-DIRECTORY:EXTEND

 Introduce the concept of an "absolute" pathname and a "relative" pathname.
 An absolute pathname is one that starts at the beginning (or top) of the
 host file system, a relative pathname is one which starts at an
 unspecified location.  A relative pathname must be merged with a absolute
 pathname before it can be used to reference a file.

 Specify that when the PATHNAME (first) argument to MERGE-PATHNAMES is a
 relative pathname, the directory component of the DEFAULTS (second)
 argument will appear first in the directory component of the resulting
 pathname, followed by the directory component of the PATHNAME argument.
 If the PATHNAME argument is an absolute pathname, then the directory
 component of the resulting pathname will be the same as the directory
 component of the PATHNAME argument.

 Extend MAKE-PATHNAME: 

   The value specified for the :DIRECTORY keyword may be a list of keywords
   and strings that denote the directory components in the directory path.
   If the list begins with the keyword :ABSOLUTE the resulting pathname is
   absolute, if the list begins with the keyword :RELATIVE then the
   resulting pathname is relative.  The results are implementation defined
   if the list does not begin with one the keywords :RELATIVE or :ABSOLUTE.

   In addition to :ABSOLUTE and :RELATIVE, an implementation may permit
   additional keywords to appear in the directory list.  The following
   keywords, if they are accepted will have the following meaning; :WILD
   matches all directories at the given location in the directory path, :UP
   specifies that when MERGE-PATHNAMES is applied, one directory will be
   eliminated from the resulting directory path, and :WILD-INFERIORS
   which matches all directories below the point at which the
   :WILD-INFERIORS keyword appears in the directory path.

<<< There should be a way to deal with UNIX style pathnames where
    :UP is not strictly syntactic (i.e. it may depend on the file system.
    A keyword dealing with this sort of thing would have to be maintained
    until TRUENAME was gotten.  I don't have a good candidate name for it
    however. >>>

  Introduce a new function;

    PATHNAME-ABSOLUTE-P path

  Path should be pathname, PATHNAME-ABSOLUTE-P returns true if path is an
  absolute pathname, and false otherwise.

  Specify that PATHNAME-DIRECTORY returns a list of the directory
  componentsfor the given pathname.  If pathname is an absolute pathname,
  then the CAR of the list will be :ABSOLUTE, otherwise it will be
  :RELATIVE.  The results are undefined if the return value is modified.

Test Cases/Examples:

  (setq abs-1 (MAKE-PATHNAME :DIRECTORY '(:ABSOLUTE "a")))
  (setq abs-2 (MAKE-PATHNAME :DIRECTORY '(:ABSOLUTE "b")))
  (setq rel-1 (MAKE-PATHNAME :DIRECTORY '(:RELATIVE "c")))
  (setq rel-2 (MAKE-PATHNAME :DIRECTORY '(:RELATIVE "d"")))
  (PATHNAME-DIRECTORY (MERGE-PATHNAMES abs-1 abs-2)) => (:ABSOLUTE "a") 
  (PATHNAME-DIRECTORY (MERGE-PATHNAMES abs-1 rel-1)) => (:ABSOLUTE "a")
  (PATHNAME-DIRECTORY (MERGE-PATHNAMES rel-1 abs-1)) => (:ABSOLUTE "a" "c")
  (PATHNAME-DIRECTORY (MERGE-PATHNAMES rel-1 rel-2)) => (:RELATIVE "d" "c")
  (NOT (PATHNAME-ABSOLUTE-P abs-1)) => NIL
  (PATHNAME-ABSOLUTE-P rel-1) => NIL

Rationale:

Current practice:

Allegro ExCL uses the same representations as descrived in this proposal,
and lucid and Symbolics Genera (presumably TI lispm as well) are very
close.  Allegro CL and Symbolics Genera 7.2 already perform merging as
described in this proposal (which is clearly not legal CLtL).  KCL, VAXLISP
2.1 and LUCID v?? do pathname directory merging as described in CLtL.
Symbolics Genera, LUCID, KCL, and Allegro already return lists from
PATHNAME-DIRECTORY, VAXLISP returns a string.  Symbolics Genera currently
does pathname canonicalization for components specified in calls to
make-pathname, and reverses the canonicalization in the pathname-*
functions, but the intermediate pathname has the case of the components
inverted (at least for BSD 4.2 style pathnames).

			   PATHNAME-DIRECTORY results
			Absolute		Relative
  KCL (unix)		(:ROOT . strings)	(strings)
  Franz Allegro (unix)	(:ABSOLUTE . strings)	(:RELATIVE . strings)
  Symbolics (lispm)	(strings)		(:RELATIVE . strings)
  Lucid (unix)		(strings)		(:RELATIVE . strings)
  
Cost to Implementors:

Unknown, but not likely to be excessive.

Cost to Users:

Minimal.  This is an imcompatible change in that pathname merging will no
longer always en mass replace the directory component, however portable
programs can currently only be using absolute pathnames whose behaviour
remans unchanged.  The return value of PATHNAME-DIRECTORY is undefined now,
this proposal would make it defined.  Although this could break existing
programs, they are already not portable.

Cost of non-adoption:

Manipulation of structured directory components will continue to be 
difficult/implementation specific.

Benefits:

Manipulating structured directory components will be easier, and the
pathname functions will more accurately model existing file system
structure. 

Esthetics:

None.

Discussion: