make-pathname vs merge-pathnames

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