Issue: PATHNAME-COMPONENT-CASE (Version 1)

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

Issue:        PATHNAME-COMPONENT-CASE
References:   Pathnames (pp410-413),
	      MAKE-PATHNAME (p416),
	      PATHNAME-HOST (p417),
	      PATHNAME-DEVICE (p417),
	      PATHNAME-DIRECTORY (p417),
	      PATHNAME-NAME (p417),
	      PATHNAME-TYPE (p417)
Category:     CHANGE
Edit history: 1-Jul-88, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  Issues of case in pathnames are a major source of problems.

  In some file systems, the canonical case is lowercase, in some
  uppercase, in some mixed.

  In some file systems, case matters, in others it does not.

  (NAMESTRING (MAKE-PATHNAME :NAME "FOO" :TYPE "LISP"))
  will produce an `ugly' file name like "FOO.LISP" in many (but not all)
  Common Lisp implementations talking to Unix, for example.

  (NAMESTRING (MAKE-PATHNAME :NAME "foo" :TYPE "lisp"))
  might produce an `ugly' file name like "â??Vfâ??Voâ??Vo.â??Vlâ??Viâ??Vsâ??Vp"
  in a Common Lisp implementation talking to a Tops-20.

  Problems like this make it difficult to use MAKE-PATHNAME for much of
  anything without corrective (non-portable) code.

  Other problems occur in merging because doing
   (NAMESTRING (MERGE-PATHNAMES (MAKE-PATHNAME :HOST "MY-TOPS-20" :NAME "FOO")
	                        (PARSE-NAMESTRING "MY-UNIX:x.lisp")))
  should probably return "MY-TOPS-20:FOO.LISP" but in fact might return
  "MY-TOPS-20:FOO.â??Vlâ??Viâ??Vsâ??Vp" in some implementations.

  Problems like this make it difficult to use any merging primitives for
  much of anything without corrective (non-portable code).

Proposal (PATHNAME-COMPONENT-CASE:CANONICALIZE):

  Designate a treatment for case in pathname components which is
  distinct from the treatment of case in the namestrings. The treatment
  should be invariant across operating systems.

  If a string given to MAKE-PATHNAME, or returned by any of the
  PATHNAME-xxx accessor operations, is all uppercase, it is said to
  designate a name in the system's "canonical case".

  If a string given to MAKE-PATHNAME, or returned by any of the
  PATHNAME-xxx accessor operations, is all lowercase, it is said to
  designate a name in the system's "anticanonical case".

  If a string given to MAKE-PATHNAME, or returned by any of the
  PATHNAME-xxx accessor operations, is mixed case, it is said
  designate a name in exactly the indicated case.

  Functions such as PARSE-NAMESTRING and NAMESTRING which convert
  from or to native host syntax will perform any necessary conversions
  from internal syntax.

  Note: In fact, this proposal does not require an implementation to
  change its internal representation. It only requires the CL-defined
  accessors to behave as if the internal representation had been changed.
  Whether the actual internal representation is changed is still up to an
  implementation. A consequence of this is that if pathnames print 
  in a way that shows the components individually (such as #S), they
  are not constrained to print the components in any particular case;
  they are constrained only to have definite syntax conventions and to
  be able to invert those conventions at the appropriate time. Any change
  to the way pathnames print is beyond the scope of this proposal.

Test Case:

  (PATHNAME-NAME (PARSE-NAMESTRING "MY-UNIX:/me/foo.lisp"))    => "FOO"
  (PATHNAME-NAME (PARSE-NAMESTRING "MY-TOPS-20:<ME>FOO.LISP")) => "FOO"

Rationale:

  This does not solve the whole pathname problem, but it does improve
  the situation for a clearly defined set of very common problems.

Current Practice:

  Symbolics Genera implements this behavior.

Cost to Implementors:

  While this proposal is compatible with CLtL, it may not be compatible with
  the implementations of CLtL which some implementations have chosen.

  It is possible to isolate the forced changes to the referenced functions
  (MAKE-PATHNAME and the PATHNAME-xxx accessors). Existing functions can be
  renamed, and new functions with the same name can be introduced which simply
  encapsulate case conversion. No further change is forced.

  It may, however, be desirable for an implementation to make a more complete
  overhaul of their representation. In implementations where the implementors
  feel a need to do this, the amount of work may be considerably greater.

Cost to Users:

  Technically, this change is upward compatible.

  In fact, since the existing CLtL spec is so poor, nearly everyone relies
  heavily on implementation-specific behavior since there is little other
  choice. As such, any change is almost certain to break lots of programs,
  in usually superficial but nevertheless important ways. However, if we
  really make the pathname facility more portable, the user community may be
  willing to bear the consequences of these changes.

Cost of Non-Adoption:

  We would be contributing to the perpetuation of the existing fiasco of a
  pathname system.

Benefits:

  The major costs of non-adoption would be avoided.

Aesthetics:

  More code is required, but the code supports a simpler user model.
  Anything that simplifies the user model of pathnames is going to be an
  improvement.

Discussion:

  Pitman suports PATHNAME-COMPONENT-CASE:CANONICALIZE.