From: Christophe Rhodes
Subject: Can PARSE-NAMESTRING create logical hosts?
Date: 
Message-ID: <sq4ri9gdre.fsf@lambda.jcn.srcf.net>
From the CLHS entry for PARSE-NAMESTRING:

  * If host is nil, default-pathname is a logical pathname, and thing
    is a syntactically valid logical pathname namestring without an
    explicit host, then it is parsed as a logical pathname namestring on
    the host that is the host component of default-pathname.

So, what should (parse-namestring "FOO:;BAR") return in a clean
invocation of a lisp (without a pre-defined "FOO" logical host)? One
view says it should return a logical pathname with host "FOO",
directory (:RELATIVE) and name "BAR", since it's a syntactically
valid logical pathname namestring; on the other hand, the implication
of 

  host is either the host component of a logical pathname or a string
  that has been defined as a logical pathname host name by setf of
  logical-pathname-translations.

(from the CLHS entry for LOGICAL-PATHNAME-TRANSLATIONS) is that
logical pathname hosts can only be created from 
(SETF LOGICAL-PATHNAME-TRANSLATIONS).

Opinions? Is it useful to be able to refer to logical pathnames before
they're defined? Given that it is possible to force physical pathname
parsing by doing

  (parse-namestring "FOO:;BAR" 
                    (pathname-host *default-pathname-defaults*))

where *default-pathname-defaults* is a physical pathname with a
non-NIL host[*], maybe the first interpretation is preferable; on the
other hand current practice seems divided on this issue :-/

Cheers,

Christophe

[*] see previous arguments on the legality of this on your favourite
comp.lang.lisp archive...
-- 
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)

From: Marco Antoniotti
Subject: Re: Can PARSE-NAMESTRING create logical hosts?
Date: 
Message-ID: <y6celhcdhm0.fsf@octagon.mrl.nyu.edu>
Christophe Rhodes <·····@cam.ac.uk> writes:

> From the CLHS entry for PARSE-NAMESTRING:
> 
>   * If host is nil, default-pathname is a logical pathname, and thing
>     is a syntactically valid logical pathname namestring without an
>     explicit host, then it is parsed as a logical pathname namestring on
>     the host that is the host component of default-pathname.
> 
> So, what should (parse-namestring "FOO:;BAR") return in a clean
> invocation of a lisp (without a pre-defined "FOO" logical host)? One
> view says it should return a logical pathname with host "FOO",
> directory (:RELATIVE) and name "BAR", since it's a syntactically
> valid logical pathname namestring; on the other hand, the implication
> of 

No.  I do not think you are allowed to do that at all.

IMHO PARSE-NAMESTRING has two possible behaviors here:
1 - it should check whether there is a logical HOST named "FOO".  If
    not signal an error
2 - parse the string in an implementation dependent way w.r.t. the
    conventions of the underlying file system

So the question is whether you want to signal an error if there is no
LP host "FOO" defined.  I do not think that you can construct a LP
host by side effect in this way.  It just messes things up considerably/

>   host is either the host component of a logical pathname or a string
>   that has been defined as a logical pathname host name by setf of
>   logical-pathname-translations.
> 
> (from the CLHS entry for LOGICAL-PATHNAME-TRANSLATIONS) is that
> logical pathname hosts can only be created from 
> (SETF LOGICAL-PATHNAME-TRANSLATIONS).

I agree that this is a problem in the ANSI spec.  A macro would have
helped a lot, and a better specification of when and where
implementation defined translations are kept is another thing that is
missing.  Another very sore issue is that there is no standard way to
check whether a logical host has been defined�. But these are other issues.

> 
> Opinions? Is it useful to be able to refer to logical pathnames before
> they're defined?

No, in the same way that you cannot execute functions before they are defined.

> Given that it is possible to force physical pathname
> parsing by doing
> 
>   (parse-namestring "FOO:;BAR" 
>                     (pathname-host *default-pathname-defaults*))
> 
> where *default-pathname-defaults* is a physical pathname with a
> non-NIL host[*], maybe the first interpretation is preferable; on the
> other hand current practice seems divided on this issue :-/

I agree with KMP on this one.  NIL hosts are useful only in
MERGE-PATHNAMES.  A pathname with a non null HOST is preferable.

Cheers

� Of course you can always define

        (defun logical-host-defined-p (h)
           (declare (type string h))
           (ignore-errors (logical-pathname-translations h)))

  or something similar.

-- 
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'.
From: Christophe Rhodes
Subject: Re: Can PARSE-NAMESTRING create logical hosts?
Date: 
Message-ID: <sqvgaogagw.fsf@lambda.jcn.srcf.net>
Marco Antoniotti <·······@cs.nyu.edu> writes:

> Christophe Rhodes <·····@cam.ac.uk> writes:
> 
> > Opinions? Is it useful to be able to refer to logical pathnames before
> > they're defined?
> 
> No, in the same way that you cannot execute functions before they are defined.

Ah, but you can have forward references for functions. Forward
references for logical pathnames would be much the same:

(defun foo (x)
  (bar x))

[ ... some time later ... ]

(defun bar (x)
  (1+ x))

(foo 3)

analagous to

(defun foo (x)
  (with-open-file (s #p"FOO:BAR;BAZ.LISP")
     ...))

(setf (logical-pathname-translations "FOO")
      '(("**;*.*.*" "/tmp/**/*.*")))

(foo 3)

> � Of course you can always define
> 
>         (defun logical-host-defined-p (h)
>            (declare (type string h))
>            (ignore-errors (logical-pathname-translations h)))

I believe that () is a valid logical-pathname-translations for a
logical host. :-/

I'm inclining towards believing that it's more useful to not do
side-effects from parse-namestring... but I'll carry on playing
devil's advocate until it all makes perfect sense :-)

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)
From: Marco Antoniotti
Subject: Re: Can PARSE-NAMESTRING create logical hosts?
Date: 
Message-ID: <y6cy9fkby6u.fsf@octagon.mrl.nyu.edu>
Christophe Rhodes <·····@cam.ac.uk> writes:

> Marco Antoniotti <·······@cs.nyu.edu> writes:
> 
> > Christophe Rhodes <·····@cam.ac.uk> writes:
> > 
> > > Opinions? Is it useful to be able to refer to logical pathnames before
> > > they're defined?
> > 
> > No, in the same way that you cannot execute functions before they are defined.
> 
> Ah, but you can have forward references for functions. Forward
> references for logical pathnames would be much the same:

No they would not. I explicitely used the term "execution" in my comment.

> (defun foo (x)
>   (bar x))
> 
> [ ... some time later ... ]
> 
> (defun bar (x)
>   (1+ x))
> 
> (foo 3)
> 
> analagous to
> 
> (defun foo (x)
>   (with-open-file (s #p"FOO:BAR;BAZ.LISP")
>      ...))
> 
> (setf (logical-pathname-translations "FOO")
>       '(("**;*.*.*" "/tmp/**/*.*")))
> 
> (foo 3)

Yes. I understood this.  However, for functions

(defun foo (x) (bar x))

(bar 3)

Unequivocally signals an error if BAR has not been defined.

(defun foo (x)
  (with-open-file (s (parse-namestring "FOO:BAR;BAZ.LISP"))
     ....))

when "FOO" is not a LP host, may or may not signal an error depending
on the state of your file system.

If you allow a side effect in this case you are further complicating
the issues. (Are you on UNIX? What if a UNIX file exists and/or is
created before or after either function call and/or logical pathname
translation setting?

> > � Of course you can always define
> > 
> >         (defun logical-host-defined-p (h)
> >            (declare (type string h))
> >            (ignore-errors (logical-pathname-translations h)))
> 
> I believe that () is a valid logical-pathname-translations for a
> logical host. :-/

Yep. You are right. The above does not take that into account.

> I'm inclining towards believing that it's more useful to not do
> side-effects from parse-namestring... but I'll carry on playing
> devil's advocate until it all makes perfect sense :-)

I do not think there is a way out lest an agreement is reached among
the implementors (as I said elsewhere).  The "Genera Rule" (everything
before the first `:' is a - quote - host - unquote - is almost ok in
this day and age, but maybe not enough.  Life would be much much
easier if the MacOS had not chosen `:' as a directory separator.

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'.
From: Kent M Pitman
Subject: Re: Can PARSE-NAMESTRING create logical hosts?
Date: 
Message-ID: <sfwy9fk4lv9.fsf@shell01.TheWorld.com>
Marco Antoniotti <·······@cs.nyu.edu> writes:

> I do not think there is a way out lest an agreement is reached among
> the implementors (as I said elsewhere).  The "Genera Rule" 

Genera calls its rule the "host colon rule", btw.

Bernie Greenberg (implement of one of several Lisp Machine File Systems,
LMFS, the one that Genera primarily uses), I think it was, joked that he
wanted to use a "chalice" character rather than a "colon", since it 
delimited the "host".  (The joke is a bit obscure.)  But Symbolics
didn't have a chalice character available.  I think they might have gone
with double-colon but for the fact that DEC had already done that, and only
triple colon was still free, so they just went with the easy approach.

> (everything
> before the first `:' is a - quote - host - unquote - is almost ok in
> this day and age, but maybe not enough.  Life would be much much
> easier if the MacOS had not chosen `:' as a directory separator.

MacOS doesn't really make a problem.  The thing to understand is that 
Genera's host colon rule means that, in general, one cannot rely on the
namestring to be a host-namestring.  A separate operation is needed to get
the host namestring.  Once you make this allowance, there is no trouble created
by either the MAC or DEC VAX nor ITS nor DOS nor NTFS use of : because those
uses are not competing with the host colon.  If you don't have a strict
rule, and you think you want to let people sometimes win by not providing a
host, then you just screw everyone because nothing seems reliable ever.
It's the desire of the vendors who have a near-sighted view that they will
only ever talk to one operating system type that create the problem, not
the vendors who have a broad view.  This has been a known issue for a VERY
long time, and vendors have simply resisted doing it the Symbolics way for
reasons that are to me indistinguishable from NIH syndrome.  (Maybe someone
can come up with a better reason.)  Vendors _should_, IMO, just implement a
host-namestring that does what they want and tell users of native code to
just always call that.  But they should not be trying to force #P"..." to print
in an unhosted way to support the bad illusion that there is only one file
system, and they should be trying to force NAMESTRING to be HOST-NAMESTRING
because it was never intended to be.

Just my opinion all of that, of course.

Genera can access Macintosh file systems in about five syntactic variations:

As a coprocessor plug-in card to the Mac, the Lisp Machine becomes what 
is called a MacIvory, and has application support to make the Mac screen
do its display as if it were an application, even though it has its own
processor, its own memory, and its own fixed place on the disk (with a 
protective Mac file system wrapper around it just to keep the Mac happy,
even though it doesn't use the MACFS interface).  A Macivory can talk to
its "mac host" file system by using the special host name "HOST".  So 
HOST:MAIN:FOO:BAR:BAZ  means "on the local Mac's file system, Volume MAIN,
folder FOO contains folder BAR contains file BAZ."

As a networked file server, a Macintosh named MACK that is directly
reachable via tcp can be named as "MACK:MAIN:FOO:BAR:BAZ"

If the host MACK is the default host, referencing the file system without
specifying the default host's name is done by ":MAIN:FOO:BAR:BAZ".

As a Macivory that is on the net, its companion local macintosh file system 
can be reached as "MACK|HOST:MAIN:FOO:BAR:BAZ".

If MACK is only known by its internet address, the syntax INTERNET|1.2.3.4
can be used to address the machine, so the name becomes
"INTERNET|1.2.3.4|HOST:MAIN:FOO:BAR:BAZ".

These could all five denote the same file on the same host, depending on where
you're coming in from and how you want to reach the system.
From: Kent M Pitman
Subject: Re: Can PARSE-NAMESTRING create logical hosts?
Date: 
Message-ID: <sfwsn5t3prt.fsf@shell01.TheWorld.com>
Christophe Rhodes <·····@cam.ac.uk> writes:

> From the CLHS entry for PARSE-NAMESTRING:
> 
>   * If host is nil, default-pathname is a logical pathname, and thing
>     is a syntactically valid logical pathname namestring without an
>     explicit host, then it is parsed as a logical pathname namestring on
>     the host that is the host component of default-pathname.
> 
> So, what should (parse-namestring "FOO:;BAR") return in a clean
> invocation of a lisp (without a pre-defined "FOO" logical host)? One
> view says it should return a logical pathname with host "FOO",
> directory (:RELATIVE) and name "BAR", since it's a syntactically
> valid logical pathname namestring;

Just my personal opinion, but:  NO.  DEFINITELY NOT.    (heh)

The pathname you cite is ALSO a valid Unix pathname (with host
unspecified and name "FOO:;BAR") and some implementations will let you
have a host FOO with file ";FOO" on several other operating systems.
It is a well-formed logical pathname namestring too, but IMO it would
be VERY BAD if you read the spec to require that it had to be.

> on the other hand, the implication of 
> 
>   host is either the host component of a logical pathname or a string
>   that has been defined as a logical pathname host name by setf of
>   logical-pathname-translations.
> 
> (from the CLHS entry for LOGICAL-PATHNAME-TRANSLATIONS) is that
> logical pathname hosts can only be created from 
> (SETF LOGICAL-PATHNAME-TRANSLATIONS).

(Well, or some system-dependent way of doing it.)

> Opinions? Is it useful to be able to refer to logical pathnames before
> they're defined?

Not "meaningfully useful".  People often wish that computers would
read minds, and that would be useful, if the mindreading worked reliably
and reproducibly.  Otherwise, it's just not worth it.

> Given that it is possible to force physical pathname
> parsing by doing
> 
>   (parse-namestring "FOO:;BAR" 
>                     (pathname-host *default-pathname-defaults*))
> 
> where *default-pathname-defaults* is a physical pathname with a
> non-NIL host[*], maybe the first interpretation is preferable; on the
> other hand current practice seems divided on this issue :-/

The rule Symbolics Genera uses which has never failed to do the right thing
for me is that if there is at least one ":", the first colon MUST be at the
end of a host name (real network host or logical host) and the part after must
be a local filename on that host. On Genera, you can do things like:
 (si:com-copy-file "some-unix.com:/pub/cl/README" 
                   "some-macintosh:foo:bar:README")
and things "just work".  The system understands various different syntaxes,
not just the common ones, and parses them with respect to declared host types.
(If it doesn't know the host type, it uses kind random-host, and mostly treats
the filename separators as name components, which supports ftp-like operations
on the exact named file, but no useful merging.)

Whether you believe the Genera rule or not, it seems clear to me that
any parsing that has a host syntax and doesn't validate the host is
going to lose in parsing the string with respect to the host.
From: Christophe Rhodes
Subject: Re: Can PARSE-NAMESTRING create logical hosts?
Date: 
Message-ID: <sqzo00gbah.fsf@lambda.jcn.srcf.net>
Kent M Pitman <······@world.std.com> writes:

> Christophe Rhodes <·····@cam.ac.uk> writes:
> 
> > From the CLHS entry for PARSE-NAMESTRING:
> > 
> >   * If host is nil, default-pathname is a logical pathname, and thing
> >     is a syntactically valid logical pathname namestring without an
> >     explicit host, then it is parsed as a logical pathname namestring on
> >     the host that is the host component of default-pathname.
> > 
> > So, what should (parse-namestring "FOO:;BAR") return in a clean
> > invocation of a lisp (without a pre-defined "FOO" logical host)? One
> > view says it should return a logical pathname with host "FOO",
> > directory (:RELATIVE) and name "BAR", since it's a syntactically
> > valid logical pathname namestring;
> 
> Just my personal opinion, but:  NO.  DEFINITELY NOT.    (heh)
> 
> The pathname you cite is ALSO a valid Unix pathname (with host
> unspecified and name "FOO:;BAR") and some implementations will let you
> have a host FOO with file ";FOO" on several other operating systems.
> It is a well-formed logical pathname namestring too, but IMO it would
> be VERY BAD if you read the spec to require that it had to be.

Heh. I hear you. :-)

I actually quoted the wrong paragraph above; the one I meant to quote
was:

  * If host is nil and thing is a syntactically valid logical pathname
    namestring containing an explicit host, then it is parsed as a
    logical pathname namestring.

and it was the potential nastiness of not being able to represent
physical pathnames that made me worry... :-)

Cheers,

Christophe

PS (to the fascinated onlooker): Try 
  (inspect (parse-namestring "FOO:BAR")) 
in your favourite Lisps. You might be surprised at the results...
-- 
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)