Re: make-pathname vs merge-pathnames

I believe that the version of MAKE-PATHNAME now in CVS (in both the
0.13.x and 0.14 trees) fixes this without breaking anything else.
Thanks.


On Mon, 23 Jun 2003, Harald Hanche-Olsen wrote:

> Today I sent this to the cmucl-help mailing list:
>
> | The following passage in the HyperSpec (on make-pathname) ...
> |
> |   After the components supplied explicitly by host, device, directory,
> |   name, type, and version are filled in, the merging rules used by
> |   merge-pathnames are used to fill in any unsupplied components from
> |   the defaults supplied by defaults.
> |
> | ... led me to believe that these two expressions should be equivalent,
> | yet in CMUCL they are not:
> |
> | (merge-pathnames #P"foo/new" #P"/fee/fie/foe/name.type")
> | ==> #p"/fee/fie/foe/foo/new.type"
> |
> | (make-pathname :defaults #P"/fee/fie/foe/name.type"
> | 	       :directory '(:relative "foo")
> | 	       :name "new")
> | ==> #p"foo/new.type"
> |
> | Maybe I focussed too hard on the phrase "merging rules used by
> | merge-pathnames" where I should have noticed the phrase "unsupplied
> | components" instead?  Anyway, OpenMCL agrees with my interpretation,
> | producing the first result for both forms.  So who is in error, CMUCL
> | or OpenMCL (and I)?
>
> The answer I got back indicated that, indeed, OpenMCL is wrong (and so
> was I):
>
> + Daniel Barlow <[email protected]>:
>
> | This is kind of an FAQ, if "once every six months" counts as
> | "frequent".  KMP has replied to it a couple of times on c.l.l -
> |
> | http://groups.google.com/groups?q=pitman+merge-pathnames&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=sfwafd6p62k.fsf%40world.std.com&rnum=4
> |
> | http://groups.google.com/groups?q=pitman+merge-pathnames&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=sfw8zjvun7d.fsf%40world.std.com&rnum=10
> |
> | I know that Kent is not normative, but for what it's worth, in both
> | articles he agrees with the CMUCL interpretation.
>
> I looked at the referenced articles, and tend to agree with Kent here
> after thinking about it some more.  So I think that either the bug
> should be fixed in OpenMCL, or the maintainers should come out on
> comp.lang.lisp and tell Kent that he's wrong.  8-)
>
> (Please Cc me on any followups.  I am not on the list.)
>
> - Harald
>
> _______________________________________________
> bug-openmcl mailing list
> [email protected]
> http://clozure.com/cgi-bin/mailman/listinfo/bug-openmcl
>
>