[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Issue: PATHNAME-COMPONENT-VALUE (version 1)

This issue came up while reviewing section 2.2 of the draft standard.
Does anyone object if I mail this to X3J13 and bring it up at the
March meeting?  I couldn't find any sign that it has already been addressed.

Issue:         PATHNAME-COMPONENT-VALUE

Related Issues:PATHNAME-CANONICAL-TYPE,
               PATHNAME-SUBDIRECTORY-LIST,
               PATHNAME-UNSPECIFIC-COMPONENT,
               PATHNAME-WILD

References:    CLtL pp.410-3

Category:      CLARIFICATION and CHANGE

Edit history:  Version 1, 20-Mar-89, by Moon

Problem description:
  
  CLtL is overly restrictive on the possible values for pathname components.
  These restrictions are described in a funny way that makes it unclear
  whether they are requirements, guidelines, or just an example.
  
  The restrictions are not all written down in one place, but they appear
  to be as follows:

  Host		nil, :wild, string, or list of strings
  Device	nil, :wild, string, or something else ("structured")
  Directory	nil, :wild, string, or something else ("structured")
  Name		nil, :wild, string, or something else ("structured")
  Type		nil, :wild, or string
  Version	nil, :wild, :newest, positive integer, implementation
		dependent symbol, or implementation-dependent integer
		less than or equal to zero.  Suggestions include :oldest,
		:previous, :installed, 0, and -1.

  PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN allowed implementations to
  allow any component to be :UNSPECIFIC.  This has been voted in.

  PATHNAME-SUBDIRECTORY-LIST proposes a list of strings and keyword
  symbols for the directory component.

  PATHNAME-CANONICAL-TYPE proposes some new operations but does not
  change the possible values of the type component.

  PATHNAME-WILD proposes a portable way to test for implementation
  dependent component values that indicate wildcard matching.  It
  does not change the possible values of any component.

Proposal (PATHNAME-COMPONENT-VALUE:SPECIFY):

  The points of the proposal have been numbered to facilitate
  amendments to remove or modify individual points.

  When examining pathname components, conforming programs must be
  prepared to encounter any of the following values:

  1. Any component can be NIL, which means the component has not
  been specified.

  2. Any component can be :UNSPECIFIC, which means the component has
  no meaning in this particular pathname.

  3. Any component can be :WILD, which matches any component value.
  Wild pathnames can be used with DIRECTORY but not with OPEN.

  4. The host, device, directory, name, and type can be strings.

  5. The host and device can be a list, a structure, or a
  standard-object at the discretion of the implementation.

  6. The directory can be a list of strings and symbols as detailed in
  PATHNAME-SUBDIRECTORY-LIST (this assumes that it passes.)

  7. The version can be any symbol or any integer.  The symbol :NEWEST
  refers to the largest version number that already exists in the file
  system when reading, overwriting, appending, superseding, or directory
  listing an existing file, and refers to the smallest version number
  greater than any existing version number when creating a new file.

  When constructing a pathname from components, conforming programs
  must follow these rules:
  
  11. Any component can be NIL.  NIL in the host may mean a default host
  rather than an actual NIL in some implementations.

  12. Any component can be :WILD, which matches any component value.
  Wild pathnames can be used with DIRECTORY but not with OPEN.
  
  13. The host, device, directory, name, and type can be strings.

  14. The directory can be a list of strings and symbols as detailed in
  PATHNAME-SUBDIRECTORY-LIST (this assumes that it passes.)

  15. The version can be :NEWEST.

  16. Any component can be taken from the corresponding component
  of another pathname on the same host and device.

  17. An implementation might support other values for some
  components, but a portable program cannot use those values.  
  An implementation might allow values to be transferred between
  pathnames on different hosts or different devices, but a portable
  program cannot rely on that.
  A conforming program can use implementation-dependent values
  but this can make it non-portable, for example, it might work
  only with Unix file systems.

  18. It is suggested, but not required, that implementations use
  positive integers starting at 1 as version numbers, recognize
  the symbol :oldest to designate the smallest existing version
  number, and use keyword symbols for other special versions.

Consequences:

  The changes relative to CLtL plus PATHNAME-UNSPECIFIC-COMPONENT
  are as follows:

  The definition of "structured" component is restricted to lists,
  structures, and standard-objects, rather than allowing any object
  whatsoever.
  
  "Structured" hosts are allowed, a generalization of CLtL's list
  of strings.

  "Structured" directories are replaced by PATHNAME-SUBDIRECTORY-LIST.

  "Structured" names are forbidden.

  The difference between what component values a program can depend
  on being able to use, versus what component values a program must
  be prepared to encounter, is clarified.

Rationale:
  
  This should make it easier to write portable programs that deal with
  pathnames and make it easier for implementors by clarifying the
  framework into which they must fit.  Also it should make it easier
  to write the Common Lisp language specification by resolving some
  things that were unclear about the status quo.

  Adding "structured" hosts conforms to current practice.

  Substituting a default host for NIL conforms to current practice
  in implementations that require all pathnames to have a specific host.

  Removing "structured" names should improve portability without causing
  any harm, assuming no implementation uses structured names.  This will
  improve portability by allowing programs to do string manipulation on
  names, although such programs still have to be careful since the valid
  characters and maximum length of a name are implementation-dependent.

  Disallowing transferral of nonstandard component values between
  different hosts or different devices allows implementations to support
  multiple incompatible file systems.

Current practice:
  
  All versions of Symbolics Genera violate CLtL in the matter of hosts,
  since it uses standard-objects as the host component.  Genera deviates
  slightly from PATHNAME-SUBDIRECTORY-LIST, but otherwise conforms to
  PATHNAME-COMPONENT-VALUE:SPECIFY.

  Other implementations were not surveyed.

  This proposal assumes that no current or planned implementation
  uses structured names, not even for wildcards.

Cost to Implementors:

  Most implementations already conform, except for the changes required
  by PATHNAME-UNSPECIFIC-COMPONENT and PATHNAME-SUBDIRECTORY-LIST, so
  the cost of this proposal itself should be minimal.  It is conceivable
  that an implementation may exist that has to change its pathname
  representation, for example one that uses numbers as structured devices.

Cost to Users:

  None.

Cost of non-adoption:
  
  Pathnames will continue to be a poorly specified part of the language.

Performance impact:

  None of any significance.

Benefits/Esthetics:

  The boundary between the specified behavior of pathnames and the
  implementation-dependent behavior of pathnames will be more clear.

Discussion:

  None.