suppose "SYS" is a valid logical host.
what is the correct behavior:
(merge-pathnames "foo/bar/baz" (logical-pathname "SYS:"))
CLISP:
#S(logical-pathname :host "SYS" :device nil :directory
(:absolute "foo" "bar") :name "baz" :type nil :version :newest)
AllegroCL:
#S(logical-pathname :host "SYS" :device nil :directory
(:relative "foo" "bar") :name "baz" :type nil :version nil)
CMUCL, LispWorks: error
(merge-pathnames (pathname "foo/bar/baz") (logical-pathname "SYS:"))
CLISP: same as above
AllegroCL: ditto
LispWorks: same as CLISP (:absolute)
CMUCL: #p"foo/bar/baz"
Obviously, CMUCL is broken
if it returns, it must return a logical pathname (since "first
argument does not specify a host and the default-pathname is a logical
pathname.")
Obviously, LispWorks is the most compliant:
1. ANSI says (more or less) that
(merge-pathnames namestring pathname)
== (merge-pathnames
(etypecase pathname
(pathname (pathname namestring))
(logical-pathname (logical-pathname namestring)))
pathname)
2. (logical-pathname "foo/bar/baz") ==> error
since "foo/bar/baz" is not a logical pathname namestring.
Nevertheless, I think that CLISP has a nice piece of DWIM in its
insistence that
(merge-pathnames A B)
== (merge-pathnames (pathname A) B)
comments?
--
Sam Steingold (http://www.podval.org/~sds)
Keep Jerusalem united! <http://www.onejerusalem.org/Petition.asp>
Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/>
The paperless office will become a reality soon after the paperless toilet.
Sam Steingold <···@gnu.org> writes:
> suppose "SYS" is a valid logical host.
> what is the correct behavior:
>
> (merge-pathnames "foo/bar/baz" (logical-pathname "SYS:"))
>
> CLISP:
>
> #S(logical-pathname :host "SYS" :device nil :directory
> (:absolute "foo" "bar") :name "baz" :type nil :version :newest)
>
> AllegroCL:
>
> #S(logical-pathname :host "SYS" :device nil :directory
> (:relative "foo" "bar") :name "baz" :type nil :version nil)
>
> CMUCL, LispWorks: error
This one I think is underspecified in the CLHS, by my memory;
Personally, I could make a case for the error, but apart from that you
have to take a judgement call on what (logical-pathname "SYS:") should
return; namely, is the directory part NIL or (:ABSOLUTE)? If you look
at 19.3.1, you'll see that (namestring (make-pathname :host "SYS"
:directory NIL)) and (namestring (make-pathname :host "SYS"
:directory '(:absolute))) are the same.
> (merge-pathnames (pathname "foo/bar/baz") (logical-pathname "SYS:"))
>
> CLISP: same as above
> AllegroCL: ditto
> LispWorks: same as CLISP (:absolute)
> CMUCL: #p"foo/bar/baz"
>
> Obviously, CMUCL is broken
> if it returns, it must return a logical pathname (since "first
> argument does not specify a host and the default-pathname is a logical
> pathname.")
I don't believe that this is true, actually. (pathname "foo/bar/baz")
is perfectly allowed to return a pathname with a non-NIL host, as that
is how it represents unix pathnames. I don't see anything in the CLHS
to prevent this.
> comments?
I know this isn't what you're asking for, but maybe the lesson to
learn here is "don't use namestrings in code that you intend to be
portable"?
FWIW, I sympathise with your bit of DWIM, and I think you could
probably read fun_merge-pathnames.html in your CLHS to support your
view (that is, that
(merge-pathnames A B) and
(merge-pathnames (pathname A) B)
should be the same...). I hope others will pronounce on this issue...
Cheers,
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
Sam Steingold <···@gnu.org> writes:
> suppose "SYS" is a valid logical host.
> what is the correct behavior:
>
> (merge-pathnames "foo/bar/baz" (logical-pathname "SYS:"))
You are assuming that the host operating system thinks "/" is a directory
separator. The standard does not require this. On my Lisp machine, ">"
is the directory separator.
You are further assuming some things about pathname case of the file
system.
That's ok, though. We know what you meant. I just want to make clear
that the notion of "correct behavior" when dealing with namestrings is
not universal.
> CLISP:
>
> #S(logical-pathname :host "SYS" :device nil :directory
> (:absolute "foo" "bar") :name "baz" :type nil :version :newest)
>
> AllegroCL:
>
> #S(logical-pathname :host "SYS" :device nil :directory
> (:relative "foo" "bar") :name "baz" :type nil :version nil)
>
> CMUCL, LispWorks: error
>
> (merge-pathnames (pathname "foo/bar/baz") (logical-pathname "SYS:"))
>
> CLISP: same as above
> AllegroCL: ditto
> LispWorks: same as CLISP (:absolute)
> CMUCL: #p"foo/bar/baz"
>
> Obviously, CMUCL is broken
> if it returns, it must return a logical pathname (since "first
> argument does not specify a host and the default-pathname is a logical
> pathname.")
I don't think this is obvious at all.
Because the pathname argument is identified as a pathname designator,
you are generally to assume that in the description the coercion to a
pathname has already occurred. As a consequence, "foo/bar/baz" would
be converted to #P"foo/bar/baz" EXCEPT a host must be filled in during
that coercion. There is no such thing as an unhosted pathname. All
pathnames get a host, whether you supply one or not. (I have long
claimed this is a design error in CL, and I continue to remark on it
because it helps you to remember that if you think of it the way I
think it *should* be, permitting unhosted pathnames, you'll probably
get the result you want more often. But because of the design error,
you won't.)
There is no reference to a pathname designator here, so you don't have
any reason to suppose that the parsing of "foo/bar/baz" in the first
example, nor the explicit use of (pathname "foo/bar/baz") will be sensitive
to the logical host in default-pathname. The merging occurs as:
PATHNAME DEFAULT-PATHNAME RESULT
#<Host "LOCALHOST"> #<Logical-Host "SYS"> #<Host "LOCALHOST">
:UNSPECIFIC :UNSPECIFIC :UNSPECIFIC
(:RELATIVE "FOO" "BAR") NIL (:RELATIVE "FOO" "BAR")
"BAZ" NIL "BAZ"
NIL NIL NIL
NIL NIL :NEWEST (due to merge-pathnames)
> Obviously, LispWorks is the most compliant:
Not obvious to me.
> 1. ANSI says (more or less) that
> (merge-pathnames namestring pathname)
> == (merge-pathnames
> (etypecase pathname
> (pathname (pathname namestring))
> (logical-pathname (logical-pathname namestring)))
> pathname)
I don't see where it says this. Maybe I overlooked something.
> 2. (logical-pathname "foo/bar/baz") ==> error
> since "foo/bar/baz" is not a logical pathname namestring.
Yes, but not relevant.
> Nevertheless, I think that CLISP has a nice piece of DWIM in its
DWIM was rightly left behind in Interlisp. It is more important to be
predictable than end-user-correct. End-user-correctness is hard to assure
on a routine basis if the system is fighting you.
> insistence that
> (merge-pathnames A B)
> == (merge-pathnames (pathname A) B)
The definition in ANSI CL says this, by its use of pathname designators.
However, IMO, you have drawn some incorrect conclusions about what
happens when you do (pathname A), which is why you ended up falsely
concluding things beyond this point.
> comments?
My only other comment is that these are just my personal opinions, and
carry no more weight than anyone else's. Whatever is the right thing
here is determined by what the words say, not by what any of us thinks
would be cool. If you believe me, believe me for the arguments I've
made, not for the fact that I held the pen in writing this pathetically
bad chapter. I've said many times that this chapter was at the top of
my hate list for badly written chapters, and would have been the first
to be utterly overhauled had I had more time/money to keep working when
the final product freeze for the language came around. There is nothing
negative you could say about the wording here that would hurt my feelings.
I tried my best to untangle some of what was in CLTL, but I just didn't
have (or didn't leave myself) enough time to do it justice. So we're
all left dealing with the result as best we can.
Kent M Pitman <······@world.std.com> writes:
> Sam Steingold <···@gnu.org> writes:
>
> > insistence that
> > (merge-pathnames A B)
> > == (merge-pathnames (pathname A) B)
>
> The definition in ANSI CL says this, by its use of pathname designators.
>
> However, IMO, you have drawn some incorrect conclusions about what
> happens when you do (pathname A), which is why you ended up falsely
> concluding things beyond this point.
Yes, and just to add to the fun there are three interesting cases here:
(merge-pathnames "foo/bar/baz" (logical-pathname "SYS:"))
(merge-pathnames (pathname "foo/bar/baz") (logical-pathname "SYS:"))
(merge-pathnames #p"foo/bar/baz" (logical-pathname "SYS:"))
Kent argues that the first two should give the same always, and I
think I can agree with that. The amusing part is that the third can
give a wildly different answer, as it depends[1] on the value of the host
component of *default-pathname-defaults* at read-time rather than at
execution time.
Christophe
[1] At least, if PATHNAME uses PARSE-NAMESTRING to turn a string into
a pathname. It's not actually specified how pathname works, so I
should say that this is just my interpretation...
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
Sam Steingold <···@gnu.org> writes:
> suppose "SYS" is a valid logical host.
It may be appropriate to remark here that CLHS 19.3.1.1.1 says
"The logical pathname host name "SYS" is reserved for the
implementation. The existence and meaning of SYS: logical pathnames is
implementation-defined."
http://www.xanalys.com/software_tools/reference/HyperSpec/Body/sec_19-3-1-1-1.html
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Hello,
CLHS 19.2.2.2.1 writes:
> The value of any pathname component can be nil.
>
> When constructing a pathname, nil in the host component might mean a default host
> rather than an actual nil in some implementations.
So, should (pathname-host (make-pathname :host nil)) be NIL?
If not, is there a portable way to make pathname with an empty host?
Regards,
Alexey Dejneka
--
Greenspun's Tenth Rule of Programming as a reclame of Fortran
>>>>> On 07 Dec 2001 07:37:08 +0300, Alexey Dejneka ("Alexey") writes:
Alexey> CLHS 19.2.2.2.1 writes:
>> The value of any pathname component can be nil.
>> When constructing a pathname, nil in the host component might mean
>> a default host rather than an actual nil in some implementations.
Alexey> So, should (pathname-host (make-pathname :host nil)) be NIL?
Alexey> If not, is there a portable way to make pathname with an
Alexey> empty host?
MAKE-PATHNAME requires that the host be a valid physical pathname host,
which means it has to be a string, a list of strings, or :UNSPECIFIC.
The implementation might interpret NIL to mean some default host,
probably the local host. So if you want an "empty host", you're
supposed to say :UNSPECIFIC.
You won't be able to do file IO to such a host-unspecific pathname.
To do anything useful with it (beyond merging), I think you're supposed
to make a new pathname from it. Some implementations might implement
pathnames as different classes based on the specifed host.
Christopher Stacy <······@spacy.Boston.MA.US> writes:
> >>>>> On 07 Dec 2001 07:37:08 +0300, Alexey Dejneka ("Alexey") writes:
>
> Alexey> CLHS 19.2.2.2.1 writes:
> >> The value of any pathname component can be nil.
> >> When constructing a pathname, nil in the host component might mean
> >> a default host rather than an actual nil in some implementations.
>
> Alexey> So, should (pathname-host (make-pathname :host nil)) be NIL?
> Alexey> If not, is there a portable way to make pathname with an
> Alexey> empty host?
>
> MAKE-PATHNAME requires that the host be a valid physical pathname host,
> which means it has to be a string, a list of strings, or :UNSPECIFIC.
> The implementation might interpret NIL to mean some default host,
> probably the local host. So if you want an "empty host", you're
> supposed to say :UNSPECIFIC.
I think if you work through the language, you find that NIL is only
permitted to be recognized as localhost *if* doing so won't cause a
confusion with it being taken to represent "unsupplied". This was
possible under CLTL1 becuase there were no logical pathname hosts, so
it was possible for theri to be only one host (localhost) and for the
implementors to know that :host NIL and :host <localhost> were
effectively interchangeable.... an unsupplied host and a local host
reference must in such an implementation mean the same thing. But in
ANSI CL, one must not confuse :host NIL and :host <localhost> because
there are other possible hosts, logical hosts, so NIL is not a
permissible implementation of localhost because it will not have the
right properties under MERGE-PATHNAMES.
> You won't be able to do file IO to such a host-unspecific pathname.
> To do anything useful with it (beyond merging), I think you're supposed
> to make a new pathname from it. Some implementations might implement
> pathnames as different classes based on the specifed host.
>>>>> On Fri, 7 Dec 2001 08:03:30 GMT, Kent M Pitman ("Kent") writes:
Kent> Christopher Stacy <······@spacy.Boston.MA.US> writes:
>> >>>>> On 07 Dec 2001 07:37:08 +0300, Alexey Dejneka ("Alexey") writes:
>>
Alexey> CLHS 19.2.2.2.1 writes:
>> >> The value of any pathname component can be nil.
>> >> When constructing a pathname, nil in the host component might mean
>> >> a default host rather than an actual nil in some implementations.
>>
Alexey> So, should (pathname-host (make-pathname :host nil)) be NIL?
Alexey> If not, is there a portable way to make pathname with an
Alexey> empty host?
>>
>> MAKE-PATHNAME requires that the host be a valid physical pathname host,
>> which means it has to be a string, a list of strings, or :UNSPECIFIC.
>> The implementation might interpret NIL to mean some default host,
>> probably the local host. So if you want an "empty host", you're
>> supposed to say :UNSPECIFIC.
Kent> I think if you work through the language, you find that NIL is only
Kent> permitted to be recognized as localhost *if* doing so won't cause a
Kent> confusion with it being taken to represent "unsupplied".
I don't think it's legal at all for NIL to be used as a host in MAKE-PATHNAME.
You have to use a "valid physical pathname host", and NIL is not one
of those. NIL means unsupplied, not :UNSPECIFIC or "local host".
Unfrotunately, an implementation could hand you back a pathname that
has a host of NIL. Also, when HOST-PATHNAME returns NIL,
it has no portable meaning.
If you want a pathname with a host that's not "filled in",
I think you're supposed to represent that with :UNSPECIFIC.
Christopher Stacy <······@spacy.Boston.MA.US> writes:
> If you want a pathname with a host that's not "filled in",
> I think you're supposed to represent that with :UNSPECIFIC.
I think no.
CLHS 19.2.2.2.3.1:
| when merging a pathname with a set of defaults, only a nil value for
| a component will be replaced with the default for that component,
| while a value of :unspecific will be left alone as if the field were
| ``filled''
Regards,
Alexey Dejneka
--
Greenspun's Tenth Rule of Programming as a reclame of Fortran
Christopher Stacy <······@spacy.Boston.MA.US> writes:
> >>>>> On Fri, 7 Dec 2001 08:03:30 GMT, Kent M Pitman ("Kent") writes:
>
> Kent> Christopher Stacy <······@spacy.Boston.MA.US> writes:
> >> >>>>> On 07 Dec 2001 07:37:08 +0300, Alexey Dejneka ("Alexey") writes:
> >>
> Alexey> CLHS 19.2.2.2.1 writes:
> >> >> The value of any pathname component can be nil.
> >> >> When constructing a pathname, nil in the host component might mean
> >> >> a default host rather than an actual nil in some implementations.
> >>
> Alexey> So, should (pathname-host (make-pathname :host nil)) be NIL?
> Alexey> If not, is there a portable way to make pathname with an
> Alexey> empty host?
> >>
> >> MAKE-PATHNAME requires that the host be a valid physical pathname host,
> >> which means it has to be a string, a list of strings, or :UNSPECIFIC.
> >> The implementation might interpret NIL to mean some default host,
> >> probably the local host. So if you want an "empty host", you're
> >> supposed to say :UNSPECIFIC.
>
> Kent> I think if you work through the language, you find that NIL is only
> Kent> permitted to be recognized as localhost *if* doing so won't cause a
> Kent> confusion with it being taken to represent "unsupplied".
>
> I don't think it's legal at all for NIL to be used as a host in MAKE-PATHNAME.
> You have to use a "valid physical pathname host", and NIL is not one
> of those.
There's no information on how a pathname host was represented, so in
the CLTL1 situation, absent logical pathnames, if you knew that you
had only one possible host, you could have claimed NIL *was* the
representation of that one host, because confusing an unsupplied host
with the default host couldn't matter. But now that there's more than
one possible host, it matters to distinguish NIL, and so it's no
longer possible under ANSI CL.
> NIL means unsupplied, not :UNSPECIFIC or "local host".
Yes, but if unsupplied and unspecific and local host all meant the same
thing, as happened in numerous implementations under CLTL1, that was ok.
It only now isn't ok because for the first time, all implementations are
required to *do something* withthe host.
> Unfrotunately, an implementation could hand you back a pathname that
> has a host of NIL.
I don't think this is permitted, though I couldn't find a passage that
says so. I know it would be very hard to construct. I'm not sure it
could be constructed portably. What do you think might do this?
> Also, when HOST-PATHNAME returns NIL,
> it has no portable meaning.
PATHNAME-HOST ?
> If you want a pathname with a host that's not "filled in",
> I think you're supposed to represent that with :UNSPECIFIC.
I'm not sure what you're getting at here, but I would say it just
backwards: if you want something that IS filled in, you're supposed to
represent it with :UNSPECIFIC. :UNSPECIFIC'sS job is to be like NIL
(unsupplied) but to stay null when merging; that is, to behave as
filled, not unfilled. NIL, by contrast, behaves as unfilled, seeking
to be replaced with something non-null when merging. I don't think
it's portably valid to put :UNSPECIFIC anywhere; I think an
implementation defines where :UNSPECIFIC will be accepted.
>>>>> On Fri, 7 Dec 2001 22:40:29 GMT, Kent M Pitman ("Kent") writes:
Kent> Christopher Stacy <······@spacy.Boston.MA.US> writes:
>> >>>>> On Fri, 7 Dec 2001 08:03:30 GMT, Kent M Pitman ("Kent") writes:
>>
Kent> Christopher Stacy <······@spacy.Boston.MA.US> writes:
>> >> >>>>> On 07 Dec 2001 07:37:08 +0300, Alexey Dejneka ("Alexey") writes:
>> >>
Alexey> CLHS 19.2.2.2.1 writes:
>> >> >> The value of any pathname component can be nil.
>> >> >> When constructing a pathname, nil in the host component might mean
>> >> >> a default host rather than an actual nil in some implementations.
>> >>
Alexey> So, should (pathname-host (make-pathname :host nil)) be NIL?
Alexey> If not, is there a portable way to make pathname with an
Alexey> empty host?
>> >>
>> >> MAKE-PATHNAME requires that the host be a valid physical pathname host,
>> >> which means it has to be a string, a list of strings, or :UNSPECIFIC.
>> >> The implementation might interpret NIL to mean some default host,
>> >> probably the local host. So if you want an "empty host", you're
>> >> supposed to say :UNSPECIFIC.
>>
Kent> I think if you work through the language, you find that NIL is only
Kent> permitted to be recognized as localhost *if* doing so won't cause a
Kent> confusion with it being taken to represent "unsupplied".
>>
>> I don't think it's legal at all for NIL to be used as a host in MAKE-PATHNAME.
>> You have to use a "valid physical pathname host", and NIL is not one
>> of those.
Kent> There's no information on how a pathname host was represented, so in
Kent> the CLTL1 situation, absent logical pathnames, if you knew that you
Kent> had only one possible host, you could have claimed NIL *was* the
Kent> representation of that one host, because confusing an unsupplied host
Kent> with the default host couldn't matter. But now that there's more than
Kent> one possible host, it matters to distinguish NIL, and so it's no
Kent> longer possible under ANSI CL.
>> NIL means unsupplied, not :UNSPECIFIC or "local host".
Kent> Yes, but if unsupplied and unspecific and local host all meant the same
Kent> thing, as happened in numerous implementations under CLTL1, that was ok.
Kent> It only now isn't ok because for the first time, all implementations are
Kent> required to *do something* withthe host.
Yes, that's the problem, all right!
>> Unfrotunately, an implementation could hand you back a
>> pathname that has a host of NIL.
Kent> I don't think this is permitted, though I couldn't find a passage that
Kent> says so. I know it would be very hard to construct. I'm not sure it
Kent> could be constructed portably. What do you think might do this?
Because I didn't see anything that said it could not happen,
and it is what happens in Lispworks if you do, e.g.:
(PATHNAME-HOST (MAKE-PATHNAME :NAME "foo" :TYPE "BAR"))
In this case, the implementation represents "local host" with NIL.
(But the programmer can't rely on that meaning in portable code.)
>> If you want a pathname with a host that's not "filled in",
>> I think you're supposed to represent that with :UNSPECIFIC.
Kent> I'm not sure what you're getting at here, but I would say it just
Kent> backwards: if you want something that IS filled in, you're supposed to
Kent> represent it with :UNSPECIFIC. :UNSPECIFIC'sS job is to be like NIL
Kent> (unsupplied) but to stay null when merging; that is, to behave as
Kent> filled, not unfilled. NIL, by contrast, behaves as unfilled, seeking
Kent> to be replaced with something non-null when merging. I don't think
Kent> it's portably valid to put :UNSPECIFIC anywhere; I think an
Kent> implementation defines where :UNSPECIFIC will be accepted.
Yes, that is exactly what I trying to say.
Christopher Stacy <······@spacy.Boston.MA.US> writes:
> >> Unfrotunately, an implementation could hand you back a
> >> pathname that has a host of NIL.
>
> Kent> I don't think this is permitted, though I couldn't find a passage that
> Kent> says so. I know it would be very hard to construct. I'm not sure it
> Kent> could be constructed portably. What do you think might do this?
>
> Because I didn't see anything that said it could not happen,
> and it is what happens in Lispworks if you do, e.g.:
>
> (PATHNAME-HOST (MAKE-PATHNAME :NAME "foo" :TYPE "BAR"))
>
> In this case, the implementation represents "local host" with NIL.
> (But the programmer can't rely on that meaning in portable code.)
Nor even in their Lisp. NIL can't mean localhost because it means unfilled.
If the local host were there, it would inhibit merging into that slot.
NIL doesn't inhibit, or oughtn't, and so is different.
I like the idea that NIL might be a possible filler for host but I know
Moon really didn't want that to happen, and I thought he won. I have this
sneaking feeling there is a prohibition against hostless pathnames somewhere,
though maybe bad editing got rid of it...
Christopher Stacy <······@spacy.Boston.MA.US> writes:
> So if you want an "empty host", you're supposed to say :UNSPECIFIC.
Sorry, I used the wrong wording. I want to keep the host component of the
pathname unfilled--to fill it later with merging.
Regards,
Alexey Dejneka
--
Greenspun's Tenth Rule of Programming as a reclame of Fortran
Alexey Dejneka <········@comail.ru> writes:
> Christopher Stacy <······@spacy.Boston.MA.US> writes:
>
> > So if you want an "empty host", you're supposed to say :UNSPECIFIC.
>
> Sorry, I used the wrong wording. I want to keep the host component of the
> pathname unfilled--to fill it later with merging.
I'm sorry -- when I last looked at this, I came to the conclusion that
there was no way of portably making an unspecified host that would
later be filled in. If anyone knows different, please shout!
Cheers,
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
Alexey Dejneka <········@comail.ru> writes:
> Christopher Stacy <······@spacy.Boston.MA.US> writes:
>
> > So if you want an "empty host", you're supposed to say :UNSPECIFIC.
>
> Sorry, I used the wrong wording. I want to keep the host component of the
> pathname unfilled--to fill it later with merging.
Can't be done using CL pathnames.
The reason for this is that the design took its cue from the only extant
pathname implementation, which was Lisp Machines, and there the implementors
insisted that if you didn't know the host, you couldn't print the pathname
because you didn't know the pathname syntax. [I argued, unsucessfully,
that the pathname should print as #S(PATHNAME ...) in those cases.] They
also said you couldn't NAMESTRING it, and that it was critical to be able
to do that. [I argued it sufficed for this to be an error, since host NIL
pathnames are mostly used for merging and are not actually ocurring at a time
when namestring operations are needed.] [Since I had no implementation of
my own, my words didn't count as much. :( My relevant experience, though,
was with Macsyma on Symbolics Genera, which made full use of pathnames
spanning multiple hosts, plus a search-list capability that required constant
merging of Macsyma's pathnames with various componets on various hosts, and
we tripped over this problem every time. I invented a wrapper for Macsyma's
use that encapsulated pathnames inside another object with better merging
capabilities that called into the standard Lisp representation and merging
in most cases, except those involving hosts. Very sad, but it worked.]
Alexey Dejneka <········@comail.ru> writes:
> CLHS 19.2.2.2.1 writes:
>
> > The value of any pathname component can be nil.
> >
> > When constructing a pathname, nil in the host component might mean a default host
> > rather than an actual nil in some implementations.
>
> So, should (pathname-host (make-pathname :host nil)) be NIL?
> If not, is there a portable way to make pathname with an empty host?
IMO, it is not even permitted to create a pathname with host NIL.