CLHS: Issue PATHNAME-UNSPECIFIC-COMPONENT Writeup

#

## Issue PATHNAME-UNSPECIFIC-COMPONENT Writeup

    Status:	      Accepted, as amended, Jan 89 X3J13
    Forum:        Cleanup
    Issue:        PATHNAME-UNSPECIFIC-COMPONENT
    Forum:        Cleanup
    References:   File System Interface (pp409-427)
    Category:     CHANGE
    Edit history: 27-Dec-88, Version 1 by Pitman
    	      17-Mar-89, Version 2 by Masinter (as amended)
    Subsumes:     Issue PATHNAME-TYPE-UNSPECIFIC

    Problem Description:

      In some file systems, it is inappropriate to represent particular
      pathname components, either all the time or in some specialized
      circumstance.

       - Unix pathnames never have a version field.

       - In some file systems, specifying a device and a directory means
         something very different than specifying the device alone,
         particularly when the device is a "logical device" that may
         already imply a directory.

       - Some Unix pathnames have types and others do not. For example,
         it is possible to make files named "foo." and "foo" which are
         distinct. CLtL (p412) specifies that the type is ``always a
         string, NIL, or :WILD.'' This description is too restrictive
         to be practical in this case. One of these (usually the former)
         can get a type of "" but it is not clear how to represent the
         other. If NIL is used, merging primitives cannot detect that the
         field is filled and should not be merged against.

       - ITS pathnames have either a version or a type, but never both.
         "JOE;FILE 32" has a directory, a name, and a version.
         "JOE;FILE TEXT" has a directory, a name, and a type.
         "JOE;FILE TEXT 32" is not a possible ITS filename.

    Proposal (PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN):

      Permit :UNSPECIFIC as a value of any field of a pathname,
      including the HOST, DEVICE, DIRECTORY, NAME, TYPE, or
      VERSION field of a pathname, for file systems in which it makes sense.

      The results of supplying :UNSPECIFIC to a file system for which
      it does not make sense are undefined.

      When a pathname is converted to a namestring, NIL and :UNSPECIFIC
      are treated as if the field were empty. That is, they both cause the
      component not to appear in the string.

      When merging, however, only a NIL value for a component will be
      replaced with the default for that component, while :UNSPECIFIC
      will be left alone as if the field were filled.

      Portable programs should expect to find :UNSPECIFIC in the device,
      directory, type, or version field in some implementations.

      Portable programs should not explicitly place :UNSPECIFIC in any
      field, since that it might not be permitted in some situations,
      but portable programs may sometimes do so implicitly.

    Test Case:

      ;; #1: Non-portable code. This may signal an error in some
      ;;     implementations where an unspecific type makes no sense.

      (MAKE-PATHNAME :TYPE :UNSPECIFIC)	;not portable

      ;; #2: In this example, assume a Unix file system.

      (PATHNAME-TYPE (PARSE-NAMESTRING "foo."))
      => ""

      (PATHNAME-TYPE (PARSE-NAMESTRING "foo"))
      => :UNSPECIFIC

      (PATHNAME-TYPE (MERGE-PATHNAMES (PARSE-NAMESTRING "foo")
    				  (MAKE-PATHNAME :TYPE "BAR")))
      => :UNSPECIFIC

      ;; #3: In this example, assume an ITS file system.

      (LET ((P (PARSE-NAMESTRING "FOO 32")))
        (LIST (PATHNAME-TYPE P) (PATHNAME-VERSION P)))
      => (:UNSPECIFIC 32)

      (LET ((P (PARSE-NAMESTRING "FOO TEXT")))
        (LIST (PATHNAME-TYPE P) (PATHNAME-VERSION P)))
      => ("TEXT" :UNSPECIFIC)

      (LET ((P (MERGE-PATHNAMES (PARSE-NAMESTRING "FOO 32")
    			    (PARSE-NAMESTRING "FOO TEXT"))))
        (LIST (PATHNAME-TYPE P) (PATHNAME-VERSION P)))
      => (:UNSPECIFIC 32)

      ;; Note: It is not the intent of this proposal to actually legislate
      ;; the canonical representation of Unix pathnames "foo." and "foo",
      ;; nor of ITS pathnames "FOO 32" and "FOO TEXT". That should probably
      ;; be done, but under separate cover. The above examples are intended
      ;; only to demonstrate how this proposal will permit the representation
      ;; of pathnames not usefully representable under CLtL.

    Rationale:

      This is, by necessity, current practice in some implementations
      already.

    Current Practice:

      Symbolics Genera uses a file types and versions of :UNSPECIFIC on
      Unix and ITS file systems, for example.

    Cost to Implementors:

      None. No change to any implementation is forced.

      Some implementations which already do this are legitimized.

      Some implementations which use a non-standard token other than
      :UNSPECIFIC to implement this functionality would want to switch
      to use :UNSPECIFIC so that portable programs could expect it.

    Cost to Users:

      Some programs which manipulate pathnames should be updated to expect
      :UNSPECIFIC in the type fields in some situations.

      Any program which doesn't already expect :UNSPECIFIC is already not really
      portable, however, given that some implementations have been forced to
      go beyond the standard in order to represent all possible pathnames.

    Cost of Non-Adoption:

      Some implementations would be unable to both represent all possible
      pathnames in a rational way and at the same time to conform to the
      standard. Such an inability would seriously jeopardize the usefulness
      of Common Lisp in the design of serious programs.

    Benefits:

      Some programs involving pathnames would be more portable.

    Aesthetics:

      Sweeping a hairy situation under the rug doesn't make it go away.
      This change makes things appear less simple, but since in reality
      they were less simple, it is effectively a simplification of the
      correspondence between the CL model and reality.

    Discussion:

      Pitman and Moon support PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN.

      This feature existed (for types) in the Colander draft edition of
      CLtL, but was removed for the Laser edition. The following text is
      excerpted from the Colander edition, p259:

       ``??? Query: Is :unspecific really needed over and above nil?

       ``A component of a pathname can also be the keyword
         :UNSPECIFIC. This means that the component has been explicitly
         determined not to be there, as opposed to be missing. One way
         this can occur is with generic pathnames, which refer not to
         a file but to a whole family of files. The version, and usually
         the type, of a generic pathname are :unspecific. Another way
         :unspecific is used to represent components that are not simply
         supported by a file system. When a pathname is converted to a
         namestring, nil and :unspecific both cause the component not to
         appear in the string. When merging, however, a nil value for
         a component will be replaced with the default for that
         component, while :unspecific will be left alone.''

    "The stuff about generic pathnames in the discussion section
    was brain damage and may have lead to the confusion that caused
    :unspecific to be dropped from Common Lisp.  Only the stuff about
    components not supported by a file system makes sense."

Copyright 1996-2005, LispWorks Ltd. All rights reserved.