On Tuesday 29 March 2005 23:23, Raymond Toy wrote:
> >>>>> "Gareth" == Gareth McCaughan <[EMAIL PROTECTED]> writes:
>
> Gareth> I am, I'm sure, just about unique in feeling that I don't fully
> Gareth> grasp the Common Lisp pathname facility. So, what am I
>
> No, you're not. I ALWAYS have to read the spec to figure out what's
> supposed to happen.
I was employing the rhetorical device known as irony. :-)
> [snip]
>
> Gareth> (setf (logical-pathname-translations "cl-library")
> Gareth> '(("**;*.*.*" "/home/gjm11/u/lib/lisp/**/")))
>
> Shouldn't the translation to be
>
> '(("**;*.*.*" "/home/gjm11/u/lib/lisp/**/*.*"))
Possibly... As I say, my understanding of this stuff is
pretty much at the voodoo-chicken level. :-) What I have
seems to be pretty similar to the examples on the
LOGICAL-PATHNAME-TRANSLATIONS page of the
hyperspec. Is that wrong for CMU CL?
> Gareth> A more self-contained illustration of what confuses me:
> Gareth> * (merge-pathnames #p"foo.lisp" #p"cl-library:zog;")
> Gareth> #p"/zog/foo.lisp"
>
> Ok. I think this is right, or at least not totally wrong. First,
> (describe #p"foo.lisp") says:
...
> HOST: #<LISP::UNIX-HOST>.
...
> so the host is already set, so we can't use the host from the default
> pathname. The directory is not set, so we can use the (absolute)
> directory component from the default. The result should then be
> #p"/zog/foo.lisp".
Aargh. OK, now I understand. Well, I'm maybe one step
beyond the voodoo-chicken level now. I had been deeply
confused about when logical pathname translation happens,
and had been thinking that (in the presence of the translation
specified earlier) #p"cl-library:zog;" could be thought of as
an abbreviation for #p"/home/gjm11/u/lib/lisp/zog/"; but it
can't, and in particular it won't behave the same way with
respect to merging because logical pathnames basically
behave as if they're a completely separate filesystem (or
even a completely separate set of filesystems) that share
files with the rest of the universe only by coincidence. Damn.
I'd also been thinking that #p"foo.lisp" is (an external
representation of) a pathname that leaves only the name
and type (and maybe version) fields specified; but no,
somehow CMU CL deduces what host that file is supposed
to live on, and the only way to leave it unspecific is to
call MAKE-PATHNAME explicitly. (Is there some reason
why the specified behaviour is better than what I wrongly
expected, by the way?)
Hmm, but now I'm puzzled. If I'm reading the hyperspec
correctly, which I'm probably not, then CMU CL's behaviour
is nonconforming -- though the conforming behaviour wouldn't
suit me any better :-). So:
- #p"foo.lisp" is supposed to be the same as #.(parse-namestring "foo.lisp")
- If PARSE-NAMESTRING is not given a host (i.e., if the host argument is
NIL, which it will be by default here) and the string it's given is a
syntactically valid logical pathname without a host part, then it's
meant to yield a logical pathname whose host is the default.
- "foo.lisp" is a syntactically valid logical pathname without a host
part, no?
- So I think #p"foo.lisp" should be a logical pathname object. But
(see above) it's actually an object of type PATHNAME instead.
What am I missing here? (To repeat: the behaviour that I think
the spec asks for at this point is no nearer to what I'd have liked
than the actual behaviour, and in any case it's more likely that
I'm misunderstanding than that the CMU CL implementors
were.)
> To get what you want, I think you need
>
> (merge-pathnames (make-pathname :host nil :name "foo" :type "lisp")
> #p"cl-library:zog;")
>
> => #P"CL-LIBRARY:ZOG;FOO.LISP"
>
> But asdf doesn't do that, I think.
Well, actually the relevant bit of code here isn't in ASDF but in
Elephant's code, so changing it is a bit less scary. *sigh*
Thanks for the insights.
--
g
