Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)

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

To my knowledge, this was discussed (well, ok, one message was sent on
the subject) but never formally written up.

Actually, I took the writeup of PATHNAME-TYPE-UNSPECIFIC and expanded 
it slightly to accomodate other fields. I wrote it up and included the
issue PATHNAME-TYPE-UNSPECIFIC with it. If people seem happy with this
writeup, Larry can consider PATHNAME-TYPE-UNSPECIFIC withdrawn.
If this one runs into some hidden snag, I'll reactivate 
PATHNAME-TYPE-UNSPECIFIC.

Note that Larry's original message on PATHNAME-UNSPECIFIC-COMPONENT
deals with some things unrelated to the issue of unspecific components.
I haven't lost that information; it will appear in a different proposal,
soon to follow.
 -kmp

-----
Issue:        PATHNAME-UNSPECIFIC-COMPONENT
Forum:        Cleanup
References:   File System Interface (pp409-427)
Category:     CHANGE
Edit history: 27-Dec-88, Version 1 by Pitman
Status:       For Internal Discussion
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-TYPE-UNSPECIFIC:NEW-TOKEN):

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

  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.''