Sorry--in the heat of the cons battle, this got temporarily lost...
Didn't mean to ignore you...
This asks to take a given pathname and change specific components at
Erik Naggum <cle...
> I'm a little confused about the `defaults' arguments to `make-pathname'.
> naïvely, I had imagined that the following two forms would yield the same
> (make-pathname :directory '(:relative "foo")
> :name "bar"
> :defaults (user-homedir-pathname))
> => #p"foo/bar"
the structure level.
> (merge-pathnames (make-pathname :directory '(:relative "foo") This asks to semantically merge competing components from two pathnames.
> :name "bar")
> => #p"/home/erik/foo/bar"
Both kinds of operations need to be possible. One might argue that the
chosen mechanisms are not a perspicuous way to do the two operations
in question, but one definitely needs the ability two do either of two
distinguishable operations to get these two behaviors.
I consider the above examples "correct behavior" (although that doesn't
mean there can't be competing viewpoints :-)
> but this is not so in Allegro 4.3.1 for Unix or in CMUCL 17f, which agree I assume the "this is not so" means your personal intuitions were not
> on the values.
This means that in your example above, DIRECTORY and NAME are filled, and
> the specification for `make-pathname' reads (quoted from the HyperSpec):
> 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. [my emphasis]
only HOST, DEVICE, TYPE, and VERSION follow the MERGE-PATHNAMES protocol.
Yeah, unsupplied in this context means those with value NIL.
> standing by itself, this could be taken to support the implementation in
> ACL 4.3.1 and CMUCL 17f, but the specification for `merge-pathnames' reads:
> Constructs a pathname from PATHNAME by filling in any _unsupplied_
> components with the corresponding values from DEFAULT-PATHNAME and
> DEFAULT-VERSION. [my emphasis]
Note in the above, though you didn't give an example,
(make-pathname :name NIL :defaults #P"X:foo") => #P"X:"
That is, it treats "unsupplied" as referring to explicit args, and :name IS
;; assumes default host is "X"
(merge-pathnames (make-pathname) #P"X:foo") => #P"X:foo"
(merge-pathnames (make-pathname :name nil) #P"X:foo") => #P"X:foo"
That is, the :name slot is NIL in the component from the first pathname,
and that's treated as unsupplied,
so the compoment for the second pathname is used instead.
> which might be interpreted to mean that "unsupplied" in `make-pathname' and Well, I said you can create competing viewpoints. It's not the intended
> `merge-pathnames' are the same, and then defined only in `merge-pathnames',
viewpoint, though it's your right to disagree since the wording is what
counts. I just screwed up with the writing here--all the worse since this
issue came up before we froze the spec and I'd tried to repair it. I guess
I missed one. Sigh.
As a rule, if it helps, CLHS does not do what CLTL does of defining a
global term in a local place. It TRIES to migrate all global definitions
to the glossary and use local meanings of "unsupplied" only in a "lexical"
way. But that's nowhere expressed and can't be said to be a formal rule.
It's just something I tried informally to do because I hated that CLTL,
in textbook style, did otherwise.
Yep. I should have just picked another word, though.
> whose specification goes on to say:
> Pathname merging treats a relative directory specially. If
> (pathname-directory pathname) is a list whose car is :relative, and
> (pathname-directory default-pathname) is a list, then the merged
> directory is the value of
> (append (pathname-directory default-pathname)
> (cdr ;remove :relative from the front
> (pathname-directory pathname)))
> except [specification of :back processing].
> which is clearly intended to _override_ the meaning of "unsupplied" in
> entirely intuitive ways.
> my question is whether the special treatment of relative directories also Nope. It is my belief that it is definitely the intention of the
> overrides the "unsupplied" in `make-pathname' since it defers the handling
> of "unsupplied" arguments to `merge-pathnames'. I would tend to think it
> should. comments? (Kent?)
committee that MAKE-PATHNAME do what you observe. I think your real
gripe is with that dummy of an editor (oops, that's me) who screwed up
the wording and made it hard to read.
I'll mark it for further clarification in that distant day where we do such