Subject: Re: Known inconsistencies or bugs in CLHS?
From: Erik Naggum <>
Date: Fri, 12 Apr 2002 16:44:39 GMT
Newsgroups: comp.lang.lisp
Message-ID: <>

* Sam Steingold <>
| #P"" is an ambiguous representation since #P".a.b" can mean either
|         #S(PATHNAME :NAME ".a" :TYPE "b")
| or      #S(PATHNAME :NAME ".a.b" :TYPE NIL)
| or      #S(PATHNAME :NAME NIL :TYPE "a.b")
| (if you think that the first version is "obviously correct", think again
| about ".foo"...)

  The mapping from namestrings to pathnames is implemention-specific.
  There is no ambiguity.  You make an implementation-specific choice, then
  stick to it and make it consistent enough for your implementation, or you
  implement a more general mechanism and provide your programmers with a
  "policy switch" or even access to the maestring parser internals.  None
  of this makes the _specification_ ambiguous.  Ambiguous would mean that
  the _implementation_ had so low quality and was so poorly done that it
  could produce the same namestring for different pathnames.  If so, you
  cannot blame the standard for this form of ambiguity.

  E.g., /foo/bar/../zot may interpret the .. as :back or as :up.  Under
  Unix, no programmer would think about this, thus creating an ambiguity
  and a messy interpretation for pathnames with .. components, but Common
  Lisp has both :back and :up as distinct components, so you have to make a
  choice and a policy decision, thus _diambiguating_ the messy situation in
  Unix.  (Of course, the Unix kernel specification has one policy, but the
  existence of symbolic links make it very hard to look at the components
  one by one without consulting the file system.)
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

  Post with compassion: