Question on the role of :absolute and :relative directories and logical pathnames
Peter Van Eynde
I've bumped into a problem. What is the meaning of a :relative or
:absolute directory when one is talking about logical pathames?
I think that foo:;bar;source.lisp and foo:bar;source.lisp have a
different meaning, and that the second can legally be translated (on
some unix machine) to /bar/source.lisp. Irrespective of where the
logical pathname foo points to.
Am I completely wrong or what? The examples in the hyperspec often use
:absolute directories when I would suspect (from the text) that they
should use :relative one's...
Groetjes, Peter
--
It's logic Jim, but not as we know it. | pvan...@debian.org
"God, root, what is difference?" - Pitr|
"God is more forgiving." - Dave Aronson| http://cvs2.cons.org/~pvaneynd/
Martin ``rydis'' Rydstr|m
PVE> I've bumped into a problem. What is the meaning of a :relative or
PVE> :absolute directory when one is talking about logical pathames?
If I understood them correctly, :absolute means "absolute relative to the
base of the translation for the logical host", whereas :relative could vary
with working directories and so on.
PVE> I think that foo:;bar;source.lisp and foo:bar;source.lisp have a
PVE> different meaning, and that the second can legally be translated (on
PVE> some unix machine) to /bar/source.lisp. Irrespective of where the
PVE> logical pathname foo points to.
No, I don't think it could. Or, well, maybe it /could/, but that'd be a
rather extreme reading of a vague spec. (Based on what I have been able
to glance from the HyperSpec.)
You define the translation, both for relative and absolute logical
pathnames, and I see very little point in having the implementation not
care about the translation for the "absolute translation".
PVE> Am I completely wrong or what? The examples in the hyperspec often use
PVE> :absolute directories when I would suspect (from the text) that they
PVE> should use :relative one's...
Logical pathnames seem very interesting, but every time I try to really
understand, I get either very confused or very disappointed. They guarantee
very little. (I had as a minor idea for something to learn from to get
versions working with first Emacs-style ".~n~"-extensions, and possibly
extend that with RCS/CVS-aware handling. CMU CL wouldn't let me translate
stuff from ".~n~" to ".n" (because of the #\~, I guess) so it's on ice
right now.)
Regards,
'mr
--
Martin Rydstr|m, ry...@cd.chalmers.se ; rationalize till I'm blue in the face,
; you cannot lose if you throw the race.
Looking for a LispM to play with. Any and all offers/ideas appreciated.
Also - " - job - " - - " -
Erik Naggum
> I've bumped into a problem. What is the meaning of a :relative or
> :absolute directory when one is talking about logical pathames?
Whether they match one translation rule or another.
> I think that foo:;bar;source.lisp and foo:bar;source.lisp have a
> different meaning, and that the second can legally be translated (on some
> unix machine) to /bar/source.lisp. Irrespective of where the logical
> pathname foo points to.
That seems very, very dubious.
#:Erik
--
I found no peace in solitude.
I found no chaos in catastrophe.
-- :wumpscut:
Erik Naggum
> If I understood them correctly, :absolute means "absolute relative to the
> base of the translation for the logical host", whereas :relative could vary
> with working directories and so on.
Yes, it could, but it has nothing to with that.. :absolute or :relative
_only_ affect which translation rule applies. Any meaning you might
think of is relative to the value of logical-pathname-translations for
the relevant host, not an absolute.
> PVE> I think that foo:;bar;source.lisp and foo:bar;source.lisp have a
> PVE> different meaning, and that the second can legally be translated (on
> PVE> some unix machine) to /bar/source.lisp. Irrespective of where the
> PVE> logical pathname foo points to.
>
> No, I don't think it could. Or, well, maybe it /could/, but that'd be a
> rather extreme reading of a vague spec. (Based on what I have been able
> to glance from the HyperSpec.)
>
> You define the translation, both for relative and absolute logical
> pathnames, and I see very little point in having the implementation not
> care about the translation for the "absolute translation".
Well, actually, in a pathological translation rule, you _might_ get that
result, but then it would be intended by the programmer.
> Logical pathnames seem very interesting, but every time I try to really
> understand, I get either very confused or very disappointed.
The problem is probably that you don't view them sufficiently abstractly
but want to _do_ stuff with them. This generally fails. They are like
URLs: don't say squat about anything specific, but are just "locators"
and depend entirely on the translations for their meaning.
Kent M Pitman
> I've bumped into a problem. What is the meaning of a :relative or
> :absolute directory when one is talking about logical pathames?
Same as for any other pathname. Ignore the syntax and think of the object
structure. The meaning of a relative pathname is that if you do
(merge-pathnames p1 p2)
and p1 is relative, the directory part of p2 matters; otherwise (for
absolute pathnames), the directory part of p2 is ignored.
So...
(merge-pathnames (make-pathname :directory (cons :relative dirnames)
:name "FOO"
:type "LISP"
:case :common)
(make-pathname :directory dirspec
:name "BAR"
:type "TEXT"
:case :common))
yields the same as
(make-pathname :directory (append dirspec dirnames)
:name "FOO" :type "LISP" :case :common)
while
(merge-pathnames (make-pathname :directory (cons :absolute dirnames)
:name "FOO"
:type "LISP"
:case :common)
(make-pathname :directory dirspec
:name "BAR"
:type "TEXT"
:case :common))
yields the same as
(make-pathname :directory dirnames
:name "FOO" :type "LISP" :case :common)
The fact that it's a logical host or not is wholly irrelevant to the meaning
in any kind of abstract sense. What matters is the structure of the tokens.
This is what the whole pathname system is about--getting you out of worrying
about syntax, which is highly implementation-specific, and into worrying
about symbol manipulation, which is a lot less implementation-specific (one
might wish it were not at all implementation-specific, but that's a very
hard goal).
[Of course, if the first pathname has :directory NIL, then the dirspec
in the second pathname still matters. One might argue that a dirspec
of NIL was also a relative pathname, but I'm not going to make that case
here.]
It is true that if you were to try to take a relative pathname and merge
it against null defaults, you'd be stuck in an odd situation, but that isn't
the *purpose* of a relative pathname. A relative pathname is a lot like it
is in HTML files--a notation for moving up and down in a virtual hierarchy.
So, for example, in html it is good to do:
<a href="foo.html">stuff</a>
or
<img src="images/foo.gif" />
so that your page can be tested locally as C:/somedir/index.html and the
above references will resolve to C:/somedir/foo.html and
C:/somedir/images/foo.gif, but when you install this on
http://somehost/index.html
the identical references will refer to http://somehost/foo.html
and http://somehost/images/foo.gif.
In logical hosting in Lisp, you get two degrees of freedom, not just one,
so it may be more confusing. You can both make the root be relative to
the system and you can make pages relative to one another.
So if you had an application that used references to pages in an html-like
style, you could do
((A :HREF "FOO.HTML") ...)
or
((A :HREF ";IMAGES;FOO.GIF") ...)
and it would give you a relative pathname for using against wherever you
had put these pages in your logical host, and you could move a block of
those pages around in your logical host without injury to the block of pages,
while at the same time you could move the logical host itself around in the
physical tree without loss of meaning.
Peter Van Eynde
> Peter Van Eynde <pvan...@debian.org> writes:
>
> > I've bumped into a problem. What is the meaning of a :relative or
> > :absolute directory when one is talking about logical pathames?
>
> Same as for any other pathname. Ignore the syntax and think of the object
> structure. The meaning of a relative pathname is that if you do
> (merge-pathnames p1 p2)
> and p1 is relative, the directory part of p2 matters; otherwise (for
> absolute pathnames), the directory part of p2 is ignored.
In this case the logical pathname defined is the base of the
common-lisp-controller source hierarchy. So p2 will almost always be
just the name of a source file. I've got this strong urge that p1
should be :absolute....
It bothers me that cl-library:foo;bar.lisp will translate into
something very much :absolute while the logical pathname
representation is :relative. It makes the manipulation of the
pathnames more complex because now I cannot see if a pathname might
'go outside' the hierarchy.
> The fact that it's a logical host or not is wholly irrelevant to the meaning
> in any kind of abstract sense. What matters is the structure of the tokens.
> This is what the whole pathname system is about--getting you out of worrying
> about syntax, which is highly implementation-specific, and into worrying
> about symbol manipulation, which is a lot less implementation-specific (one
> might wish it were not at all implementation-specific, but that's a very
> hard goal).
*nod* I've only recently realized this. But now I've got make-pathname
all over the place where until now I have 'unportable' paths... At
least they are structures one can manipulate at will :-).
> In logical hosting in Lisp, you get two degrees of freedom, not just one,
> so it may be more confusing. You can both make the root be relative to
> the system and you can make pages relative to one another.
But what does it mean if you say 'I'm inside this hierarchy' followed
by 'and I'm at (:absolute "foo")'?
(It doesn't help that I always make mistakes because unix and Lisp
have opposing notations: foo /foo ;foo foo....)
All of this makes me feel that all pathnames should be :relative...
I fear it is more a religious debate then technical :-(
Peter Van Eynde
> * Martin ``rydis'' Rydstr|m <ry...@cd.chalmers.se>
> > If I understood them correctly, :absolute means "absolute relative to the
> > base of the translation for the logical host", whereas :relative could vary
> > with working directories and so on.
>
> Yes, it could, but it has nothing to with that.. :absolute or :relative
> _only_ affect which translation rule applies. Any meaning you might
> think of is relative to the value of logical-pathname-translations for
> the relevant host, not an absolute.
And is it not dubious to translate :absolute to :relative pathnames or
vice-versa? Anyone has practical experience with this?
> > Logical pathnames seem very interesting, but every time I try to really
> > understand, I get either very confused or very disappointed.
>
> The problem is probably that you don't view them sufficiently abstractly
> but want to _do_ stuff with them. This generally fails. They are like
> URLs: don't say squat about anything specific, but are just "locators"
> and depend entirely on the translations for their meaning.
I should at my Symbolics documentation I fear... If I understand
correctly pathnames now are a watered-down version of the Symbolics
version, not?
Kent M Pitman
> It bothers me that cl-library:foo;bar.lisp will translate into
> something very much :absolute while the logical pathname
> representation is :relative.
I don't understand. cl-library:foo;bar.lisp is absolute. what's relative?
> It makes the manipulation of the
> pathnames more complex because now I cannot see if a pathname might
> 'go outside' the hierarchy.
Merging done against other logical pathnames should never be able to go above
the root. It should bottom out at the root of the logical pathname. I
suppose the spec doesn't actually say that, but neither does it assign
meaning to going above.
...
> > In logical hosting in Lisp, you get two degrees of freedom, not just one,
> > so it may be more confusing. You can both make the root be relative to
> > the system and you can make pages relative to one another.
>
> But what does it mean if you say 'I'm inside this hierarchy' followed
> by 'and I'm at (:absolute "foo")'?
It means I know where I am relative to the root.
As opposed to, I know I'm inside the universe and I'm merely specifying
relative motion. Relative pathnames specify motion ("go forward 3 steps",
"go back 5 steps", "turn right", like in Logo). Absolute pathnames specify
where to go like a Star Trek transporter coordinates ("go to (1,3,5)").
Absolute pathnames require a coordinate system. Relative pathnames, in some
sense, don't, and so should work against any system. But you need them to
detect the edges, and also they are tightly bonded to the parsing system.
One could have made yet another syntax for relative pathnames, independent
of file systems, but we didn't. [It's a bug in the CL pathname design, IMO,
that we require a host in pathnames. Unhosted pathnames with relative
directories would be ideal in this case, but no one but me seemed to believe
in them at the time we tried to discuss them, so it didn't happen. Pity.
I implemented hostless pathnames in Symbolics Common Lisp Macsyma and they
are VERY useful. Force-hosted pathnames lead to a lot of conceptual problems
in the pathname system that you don't realize until you've worked without
them.]
> (It doesn't help that I always make mistakes because unix and Lisp
> have opposing notations: foo /foo ;foo foo....)
Yes.
> All of this makes me feel that all pathnames should be :relative...
No. It's rarely the case taht just because you feel pain in one direction
that going the other way will fix it. This is a kneejerk reaction.
There are two legitimate concepts here and you cannot squeeze one out
since neither subsumes the other.
> I fear it is more a religious debate then technical :-(
Only if you say "all x should be y".
It stays technical if you stick to making sure you don't eliminate
functionality for the sake of supposedly-simpler stories.
Kent M Pitman
> I should
[look?]
>at my Symbolics documentation I fear... If I understand
> correctly pathnames now are a watered-down version of the Symbolics
> version, not?
Yes, pretty much. As a rule, about half of the mechanism implemented in
the Symbolics system was adopted by CL, and my personal subjective opinion
was that the stuff left out was left out more because people just couldn't
believe so much mechanism was needed rather than that people thought it
was bad on a point-by-point thing. That is, they just wanted a smaller spec.
As a rule, the Symbolics system is very sound. Pity. The one design error
I insist they made was to insist that pathnames be hosted.
The rationale for this was that an unhosted pathname would not have a string
representation. I see no fatal problem with this at all. Such pathnames
are invaluable in making the merging algebra work, and could have been given
a #S syntax for printing. But because of a fear this would have led to
problems, we got all sorts of other strange problems instead... Bleah.
Martin ``rydis'' Rydstr|m
EN> * Martin ``rydis'' Rydstr|m <ry...@cd.chalmers.se>
>> Logical pathnames seem very interesting, but every time I try to really
>> understand, I get either very confused or very disappointed.
EN> The problem is probably that you don't view them sufficiently abstractly
EN> but want to _do_ stuff with them. This generally fails. They are like
EN> URLs: don't say squat about anything specific, but are just "locators"
EN> and depend entirely on the translations for their meaning.
Well, that is possibly a problem, but not really the major one. It's more
along the lines of permissible characters, how to translate certain things
CMU CL doesn't know about; stuff like that. What I thought would be really
easy, along the lines of
(setf (logical-host-translations "versions")
'(("*.*.newest" "/u/rydis/test/*.*")
("*.*.*" "/u/rydis/test/*.*.~*~")))
turned out to be somewhat more work, that I really don't know how to do.
Daniel Barlow
> As a rule, the Symbolics system is very sound. Pity. The one design error
> I insist they made was to insist that pathnames be hosted.
It's only after playing with this for a while that I realise just how
annoying it is. If
(parse-namestring "foo")
creates a pathname with a host, then
(merge-pathnames #p"foo" #p"scratch:bar;")
(where "scratch" names a known logical host) will create a pathname
whose host is the host of *default-pathname-defaults*, not a pathname
on "scratch". Not at all what I was expecting.
While we're here, anyone want to take a guess as to the meaning of
"... returns a logical pathname if and only if its first argument is a
logical pathname, or its first argument is a logical pathname
namestring with an explicit host, or its first argument does not
specify a host and the default-pathname is a logical pathname."
If a hostless pathname is impossible, does this mean that the third
case there can never happen anyway, or does it mean that
merge-pathnames treats a string differently from a pathname in the
first argument? It's a pathname designator, so I would find that
somewhat counterintuitive. Still, these are pathnames, nobody said
anything about it having to be intuitive.
For entertainment value, I asked people to try it out in various
implementations:
(setf (logical-pathname-translations "scratch")
'(("**;*.*.*" "/usr/local/doc/**/*")))
(pathname-host *default-pathname-defaults*)
SBCL: #<SB-IMPL::UNIX-HOST {28019B25}>
LW: NIL
ACL: NIL
So on two of three implementations we probably get an unspecified host
in #p"foo" anyway. Is this defined behvaiour?
(merge-pathnames #p"foo" "scratch:bar;")
SBCL: #P"/bar/foo"
ACL5: #p"scratch:bar;foo"
Lispworks: #P"SCRATCH:BAR;FOO"
In SBCL, pathname has a host, so don't merge the default.
In ACL5 and Lispworks, it doesn't (clever), so we do.
(merge-pathnames "foo" "scratch:bar;")
SBCL: #.(CL:LOGICAL-PATHNAME "SCRATCH:BAR;FOO")
ACL5: #p"scratch:bar;foo"
Lispworks: #P"SCRATCH:FOO"
OK, so Lispworks has parsed "foo" using LPN parsing rules there.
ACL hasn't.
(merge-pathnames ";foo" "scratch:bar;")
SBCL: #.(CL:LOGICAL-PATHNAME "SCRATCH:BAR;FOO")
ACL5: #p"scratch:bar;foo"
Lispworks: #P"SCRATCH:BAR;FOO"
I'm not sure what to conclude from this other than "don't do that,
then". Is anyone actually _using_ ANSI logical pathnames? In my
present annoyed and frustrated state, I'd be prepared to claim that it
seems like an appallingly large amount of stuff to learn for what on
most current platforms seems to provide little more useful
functionality than the moral equivalent of a $PREFIX environment
variable.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Kent M Pitman
> Kent M Pitman <pit...@world.std.com> writes:
>
> > As a rule, the Symbolics system is very sound. Pity. The one design error
> > I insist they made was to insist that pathnames be hosted.
>
> It's only after playing with this for a while that I realise just how
> annoying it is. [ example removed ] Not at all what I was expecting.
Right.
> While we're here, anyone want to take a guess as to the meaning of
>
> "... returns a logical pathname if and only if its first argument is a
> logical pathname, or its first argument is a logical pathname
> namestring with an explicit host, or its first argument does not
> specify a host and the default-pathname is a logical pathname."
This text would mean different things depending on where you took it from.
You don't happen to mention that. I'd comment if you did.
> [...]
> (pathname-host *default-pathname-defaults*)
> SBCL: #<SB-IMPL::UNIX-HOST {28019B25}>
> LW: NIL
> ACL: NIL
I seem to recall (though a quick check didn't find it) that there is a
restriction somewhere that says you can't use NIL as a representation
for the host component to represent localhost if there is any chance
that you could have any host value other than NIL. (A lot of
implementations had chosen NIL as their "host" because they had no
ability to talk to other hosts and we didn't want to break them.)
Probably that phrasing was written before the logical host text was
inserted and the contradiction not reconciled by the time we finished
the standard. I think in the presence of logical hosts, one can't
reasonably use NIL as the value for host because logical pathnames are
required and there is an unresolvable ambiguity in some of the cases
you later cite.
> So on two of three implementations we probably get an unspecified host
> in #p"foo" anyway. Is this defined behvaiour?
>
> (merge-pathnames #p"foo" "scratch:bar;")
>
> SBCL: #P"/bar/foo"
> ACL5: #p"scratch:bar;foo"
> Lispworks: #P"SCRATCH:BAR;FOO"
This has to do with the NIL host above. Implementations having no logical
hosts nor other external hosts would never see this bug because merging or
not merging NIL hosts would come out the same. But once there are two hosts
possible, NIL must not be a value.
> I'm not sure what to conclude from this other than "don't do that,
> then".
I'll omit the other examples. I think the choice of NIL to mean
"localhost" is the source of most of this confusion, but I've had too
little sleep to really check these thoroughly. See if that historical
information doesn't help you clear it up.
> Is anyone actually _using_ ANSI logical pathnames?
Sure, but I almost always do a merge of explicit pathnames where I control
the content and particularly where I copy the host from wherever I want
it to come from because I know about the design bug in the merging of hosts.
e.g.,
(merge-pathnames (make-pathname :host (pathname-host pathname2 :case :common)
:case :common :defaults pathname1)
pathname2)
That usually doesn't run into problems such as you're having. Of course,
you have to know at program-design time which pathname will be the one to
believe on the host. The alternative is to do like I did in Common Lisp
Macsyma for Symbolics and do:
(defstruct mpathname
pathname
host-component-empty-p)
and then write a set of operations that know how to tell when the host has
been legitimately supplied and when it should be treated as if NIL.
> In my
> present annoyed and frustrated state, I'd be prepared to claim that it
> seems like an appallingly large amount of stuff to learn for what on
> most current platforms seems to provide little more useful
> functionality than the moral equivalent of a $PREFIX environment
> variable.
No, it actually provides a huge amount of benefit. Just not in the case of
cross-host merging. The other thing you probably don't know you can do
is to pass a :defaults to MAKE-PATHNAME and a default to PARSE-NAMESTRING.
Between these two, you can assure that you never end up with namestrings that
aren't tightly bonded to an appropriate host.
Merging cross-host-type doesn't work well, but if you're working exclusively
with logical pathnames, then instead of (merge-pathnames "foo" ...) you can
do (merge-pathnames (parse-namestring "foo" *my-logical-host*) ...) or
(merge-pathnames (parse-namestring "foo" nil *my-logical-path*) ...).
In both of those cases, you'll get something that has the right host in it
so it won't lose when you merge it with other logical hosts.
Marco Antoniotti
Kent M Pitman <pit...@world.std.com> writes:
> Daniel Barlow <d...@telent.net> writes:
>
> > Kent M Pitman <pit...@world.std.com> writes:
> >
> > > As a rule, the Symbolics system is very sound. Pity. The one design error
> > > I insist they made was to insist that pathnames be hosted.
> >
...
> > "... returns a logical pathname if and only if its first argument is a
> > logical pathname, or its first argument is a logical pathname
> > namestring with an explicit host, or its first argument does not
> > specify a host and the default-pathname is a logical pathname."
>
> This text would mean different things depending on where you took it from.
> You don't happen to mention that. I'd comment if you did.
...
> > So on two of three implementations we probably get an unspecified host
> > in #p"foo" anyway. Is this defined behvaiour?
> >
> > (merge-pathnames #p"foo" "scratch:bar;")
> >
> > SBCL: #P"/bar/foo"
> > ACL5: #p"scratch:bar;foo"
> > Lispworks: #P"SCRATCH:BAR;FOO"
>
> This has to do with the NIL host above. Implementations having no logical
> hosts nor other external hosts would never see this bug because merging or
> not merging NIL hosts would come out the same. But once there are two hosts
> possible, NIL must not be a value.
Apart from the merging problem, (I do not have an ACL or a LW system
handy right now) what it the TYPE of the ACL and LW results? Are they
PATHNAMEs or LOGICAL-PATHNAMEs?
...
> with logical pathnames, then instead of (merge-pathnames "foo" ...) you can
> do (merge-pathnames (parse-namestring "foo" *my-logical-host*) ...) or
> (merge-pathnames (parse-namestring "foo" nil *my-logical-path*) ...).
> In both of those cases, you'll get something that has the right host in it
> so it won't lose when you merge it with other logical hosts.
Unfortunately you do not have this luxury many times. :(
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.