Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)

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

Issue:        PATHNAME-TYPE-UNSPECIFIC
References:   Pathnames (pp410-413)
Category:     CHANGE
Edit history: 27-Jun-88, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  CLtL (p412) specifies that the type is ``always a string, NIL,
  or :WILD.'' This description is too restrictive to be practical.

  In file systems which have no first-class notion of a name/type
  distinction, it is possible to make files named "foo." and "foo"
  which are distinct. 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.

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

  Permit :UNSPECIFIC as a value of the type field of a pathname for
  operating systems in which it makes sense.

  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.

Test Case:

  For file systems where :UNSPECIFIC makes sense...

  (PATHNAME-TYPE (MAKE-PATHNAME :TYPE :UNSPECIFIC)) => :UNSPECIFIC

  (PATHNAME-TYPE (MERGE-PATHNAMES (MAKE-PATHNAME :TYPE :UNSPECIFIC)
				  (MAKE-PATHNAME :TYPE "FOO")))

Rationale:

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

Current Practice:

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

Cost to Implementors:

  None. No change to any implementation is forced.

  Some implementations which use a non-standard token other than :UNSPECIFIC
  to implement this functionality might 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.

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 supports PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN.

  This feature existed 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.''