From: Edi Weitz
Subject: The mysteriously "hidden" section 19.2.3 of the HyperSpec
Date: 
Message-ID: <87oetw37hb.fsf@bird.agharta.de>
The CLHS has a section 19.2.3[1] entitled "Merging Pathnames" which,
judging from its number, should be linked from 19.2[2] but
isn't. Instead, it is linked from 19.2.2.4[3].

19.2.3 contains the sentence

   "Except as explicitly specified otherwise, for functions that
    manipulate or inquire about files in the file system, the pathname
    argument to such a function is merged with *DEFAULT-PATHNAME-DEFAULTS*
    before accessing the file system (as if by MERGE-PATHNAMES)."

On my machine, at least two CL implementations (CMUCL 18e and ECL
0.9c) get this wrong:

  * (setf *default-pathname-defaults* #p"/tmp/bar/")

  #p"/tmp/bar/"
  * (probe-file "fump")

  #p"/tmp/fump"

On a related note, I was wondering why several Lisps have a concept of
a "current working directory" which seems to exist in parallel (and
maybe even in an incompatible way) to *DEFAULT-PATHNAME-DEFAULTS*.
Some examples:

1. In LispWorks[4], CMUCL, and CLISP (and probably others) the initial
   value of *DEFAULT-PATHNAME-DEFAULTS* is always #p"" no matter where
   you started your Lisp image from although the HyperSpec gives the
   hint that the value should be "typically in the working directory
   that was current when Common Lisp was started up."

2. CMUCL (EXTENSIONS:DEFAULT-DIRECTORY), LispWorks (HCL:CHANGE-DIRECTORY
   and HCL:GET-WORKING-DIRECTORY), and AllegroCL (EXCL:CURRENT-DIRECTORY
   and EXCL:CHDIR) (and probably others) provide means to query and
   manipulate a pathname which is detached from
   *DEFAULT-PATHNAME-DEFAULTS*.

Is this because these functions existed before the ANSI standard was
finalized and backwards compatibility was deemed more important than a
consistent interface? I think this is a pity because (unless I'm
missing something) *DEFAULT-PATHNAME-DEFAULTS* would be a fine, Lisp-y
way to map the Unix/Windows concept of "the current directory" to CL.

Cheers,
Edi.

PS: Copies of this article have been sent to the CMUCL and ECL mailing
    list as well as to Xanalys support (as they seem to be the CLHS
    maintainers). My apologies if this has been fixed already.


[1] <http://www.lispworks.com/reference/HyperSpec/Body/19_bc.htm>
[2] <http://www.lispworks.com/reference/HyperSpec/Body/19_b.htm>
[3] <http://www.lispworks.com/reference/HyperSpec/Body/19_bbd.htm>
[4] However, although LispWorks seems to adher to 19.2.3, if the value
    of *DEFAULT-PATHNAME-DEFAULTS* is a relative directory, the result
    of merging a filespec with *DEFAULT-PATHNAME-DEFAULTS* will be
    merged again with LispWorks' "working directory."

From: Kent M Pitman
Subject: Re: The mysteriously "hidden" section 19.2.3 of the HyperSpec
Date: 
Message-ID: <sfwwu8j5lng.fsf@shell01.TheWorld.com>
Edi Weitz <···@agharta.de> writes:

> The CLHS has a section 19.2.3[1] entitled "Merging Pathnames" which,
> judging from its number, should be linked from 19.2[2] but
> isn't. Instead, it is linked from 19.2.2.4[3].

FYI, this is due to a difference in the implementation details between
real TeX and the hand-written processor for the TeX subset that I
wrote for CLHS.  TeX doesn't require \endxxxsection constructs for the
end of a section, but my tool did, and it had some bugs in the way it
numbered things if there was ever a section without a \end.  

The simple solution, since my TeX processor was not complete anyway,
and was a one-off just to do this task, was to add \endxxxsection
markers as needed, but I missed some in some cases.  (The problem was
actually really deep and fixing it correctly would have required a
major rearchitecting, which I even once started but never had occasion
to quite finish.)

Anyway, this implementation detail resulted in a discrepancy in
section numbering between CLHS and ANSI CL in one or two corners of
the spec (I think there are two such places, but I can't recall where
they are) which have been noted once or twice on c.l.l. but have not
seemed to practically inhibit anyone from getting work done.
From: Steven Elliot Harris
Subject: HyperSpec POSITION description (was: The mysteriously "hidden" section 19.2.3 of the HyperSpec)
Date: 
Message-ID: <83llovcrpc.fsf_-_@torus.sehlabs.com>
Kent M Pitman <······@nhplace.com> writes:

> Anyway, this implementation detail resulted in a discrepancy in
> section numbering between CLHS and ANSI CL in one or two corners of
> the spec (I think there are two such places, but I can't recall
> where they are) which have been noted once or twice on c.l.l. but
> have not seemed to practically inhibit anyone from getting work
> done.

Speaking of HyperSpec oddities, isn't the Description section for
POSITION backwards with respect to leftmost/rightmost in the face of
the from-end argument?�

,----[ Function POSITION, POSITION-IF, POSITION-IF-NOT ]
| The position returned is the index within sequence of the leftmost (if
| from-end is true) or of the rightmost (if from-end is false) element
| that satisfies the test; otherwise nil is returned. The index returned
| is relative to the left-hand end of the entire sequence, regardless of
| the value of start, end, or from-end.
`----

Shouldn't it say that if from-end is true, the position returned is
the rightmost?


Footnotes: 
� http://www.lispworks.com/reference/HyperSpec/Body/f_pos_p.htm

-- 
Steven E. Harris
From: Kent M Pitman
Subject: Re: HyperSpec POSITION description (was: The mysteriously "hidden" section 19.2.3 of the HyperSpec)
Date: 
Message-ID: <sfw1xqnyno0.fsf@shell01.TheWorld.com>
Steven Elliot Harris <········@raytheon.com> writes:

> Kent M Pitman <······@nhplace.com> writes:
> 
> > Anyway, this implementation detail resulted in a discrepancy in
> > section numbering between CLHS and ANSI CL in one or two corners of
> > the spec (I think there are two such places, but I can't recall
> > where they are) which have been noted once or twice on c.l.l. but
> > have not seemed to practically inhibit anyone from getting work
> > done.
> 
> Speaking of HyperSpec oddities, isn't the Description section for
> POSITION backwards with respect to leftmost/rightmost in the face of
> the from-end argument?�
> 
> ,----[ Function POSITION, POSITION-IF, POSITION-IF-NOT ]
> | The position returned is the index within sequence of the leftmost (if
> | from-end is true) or of the rightmost (if from-end is false) element
> | that satisfies the test; otherwise nil is returned. The index returned
> | is relative to the left-hand end of the entire sequence, regardless of
> | the value of start, end, or from-end.
> `----
> 
> Shouldn't it say that if from-end is true, the position returned is
> the rightmost?

Yes.  But this isn't a HyperSpec bug, it's an ANSI CL bug.
The HyperSpec contains no technically descriptive prose that was injected.
It's produced by automatic program from the ANSI CL sources.

Fortunately, I think all implementations agree that this is a typo and hence
everyone is treating it as non-controversial.  Just like the prog1/prog2
problem, which is also an ANSI CL issue.

> Footnotes: 
> � http://www.lispworks.com/reference/HyperSpec/Body/f_pos_p.htm