[Openmcl-devel] Re: [cclan-list] ASDF MCL or OpenMCL bug?

Gary Byers gb at clozure.com
Fri Aug 30 19:53:17 PDT 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.
>
> Best,
>
>
> John DeSoi, Ph.D.

Personally, I'd be very suspicious of anyone who didn't find logical
pathnames confusing.

>
>
> 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.)

>
> Cheers,
>
> Christophe
>
> ? (let ((*default-pathname-defaults* #p"CCL:FOO;")) (make-pathname
> :name "BAR"))
> #4P"CCL:BAR"
> ? (inspect *)
> [0]     #4P"CCL:BAR"
> [1]     Type: LOGICAL-PATHNAME
> [2]     Class: #<BUILT-IN-CLASS LOGICAL-PATHNAME>
> [3]     0: LOGICAL-PATHNAME
> [4]     1: (:ABSOLUTE)
> [5]     2: "BAR"
> [6]     3: NIL
> [7]     4: "CCL"
> [8]     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
something.


> 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
> http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel
>
>


_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel




More information about the Openmcl-devel mailing list