[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)
- To: CL-Cleanup@SAIL.Stanford.EDU
- Subject: Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Mon, 27 Jun 88 15:37 EDT
References: Pathnames (pp410-413)
Edit history: 27-Jun-88, Version 1 by Pitman
Status: For Internal Discussion
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.
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
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")))
This is, by necessity, current practice in some implementations
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.
Some programs involving pathnames would be more portable.
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.
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.''