[Openmcl-devel] Re: [cclan-list] ASDF MCL or OpenMCL bug?
gb at clozure.com
Fri Aug 30 22:53:17 EDT 2002
On Fri, 30 Aug 2002, John DeSoi wrote:
> Thanks, Christophe.
> I'm also posting this to openmcl-dev to see if Gary might have some
> insight. I share your confusion about logical pathnames.
> John DeSoi, Ph.D.
Personally, I'd be very suspicious of anyone who didn't find logical
> On Fri, Aug 30, 2002 at 12:34:18PM -0400, John DeSoi wrote:
> > Under OpenMCL I'm getting a bad path returned from component-pathname
> > which merges the following:
> > component-parent-pathname - uffi:src;
> > component-relative-pathname - uffi:package.lisp
> > Under MCL the same code gives:
> > component-parent-pathname - uffi:src;
> > component-relative-pathname - package.lisp
> Hmm. OpenMCL's misbehaviour probably isn't in the fact that it's
> returned a pathname with a host, but rather that it has put (:ABSOLUTE)
> in the directory slot. I wonder why...
> > The issue comes from make-pathname here:
> > (defmethod component-relative-pathname ((component source-file))
> > (let ((*default-pathname-defaults* (component-parent-pathname component)))
> > (or (slot-value component 'relative-pathname)
> > (make-pathname :name (component-name component)
> > :type
> > (source-file-type component
> > (component-system component))))))
> > I had no problems with MCL, ACL, or LispWorks, but it seems that
> > OpenMCL might be doing the correct thing according to the specs:
> > defaults---a pathname designator. The default is a pathname whose
> > host component is the same as the host component of the value of
> > *default-pathname-defaults*, and whose other components are all nil.
> I would expect this make-pathname command to return something such that
> when merged against COMPONENT-PARENT-PATHNAME would give you back the
> pathname. OpenMCL breaks that expectation by giving us an '(:ABSOLUTE)
> pathname back. At first sight, I'd say that this was a bug in OpenMCL,
> but to be honest at times I'm so utterly confused by logical pathnames
> that I could be getting this wrong.
Glad to hear that this is confusing (see above.)
> ? (let ((*default-pathname-defaults* #p"CCL:FOO;")) (make-pathname
> :name "BAR"))
> ? (inspect *)
>  #4P"CCL:BAR"
>  Type: LOGICAL-PATHNAME
>  Class: #<BUILT-IN-CLASS LOGICAL-PATHNAME>
>  0: LOGICAL-PATHNAME
>  1: (:ABSOLUTE)
>  2: "BAR"
>  3: NIL
>  4: "CCL"
>  5: NIL
My own confusion in this case is perhaps a little greater than usual, but
I'd guess that you're questioning whether the PATHNAME-DIRECTORY of
the result above should be NIL instead of (:ABSOLUTE).
That seems to sort of devolve into the question of whether or not
(:ABSOLUTE) is an appropriate canonicalization of the directory component
in this case. (Note that the case of (MAKE-PATHNAME :directory nil ...)
yields different results.)
I believed (and generally still believe) that it was desirable for
MAKE-PATHNAME to behave consistently with PARSE-NAMESTRING, in the
cases where no :DIRECTORY argument was provided/no directory component
was present in a logical namestring. From what I recall, there was
considerable variance in the ways that implementations parsed namestrings:
? (pathname-directory (parse-namestring "CCL:FOO.LISP"))
returns (:ABSOLUTE) in analogous cases in some implementations
(including OpenMCL), NIL in others, and -may- have returned something
else entirely in others.
In PARSE-NAMESTRING's case, (:ABSOLUTE) seemed to be the best choice:
it prevented some unexpected and unintuitive behavior on the part of
MERGE-PATHNAMES and seemed to have minimal negative impact. As I said,
it seems intuitive (to me) that MAKE-PATHNAME and PARSE-NAMESTRING
should behave consistently.
Appropriateness and intuitiveness are mostly in the eye of the beholder;
I don't see anything in OpenMCL's behavior that contradicts what the
spec allows, but am certainly open to the possibility that I'm missing
> Jesus College, Cambridge, CB5 8BL +44 1223 510 299
> http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
> (str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
> (set-dispatch-macro-character #\! #\$ #'pling-dollar)
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
Openmcl-devel mailing list
Openmcl-devel at clozure.com
More information about the Openmcl-devel