From: Mike McDonald
Subject: spec question wrt PARSE-NAMESTRING and logical pthnames
Date: 
Message-ID: <wUBp6.7198$a3.13997@typhoon.aracnet.com>
  We're having a disagreement on the CMUCL mailing list about how to interpret
the spec when it comes to parse-namestring and logical pathnames. The argument
comes down to does the logical host have to be "defined" via '(setf
(logical-pathname-translations ...' before parse-namestring will parse a
namestring that has the syntax of a logical pathname as one? One sides claims
that "foo:bar;baz.lisp" should be parsed as a logical pathname irregardless of
whether or not a translation for "foo" has been defined. The other side feels
that if there is no translations for "foo" defined, then it should not be
parsed as a logical pathname.

  The portions of the spec in question are:

  	from parse-namestring:

* 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 from 19.3.1.1.1 The Host part of a Logical Pathname Namestring:

The host must have been defined as a logical pathname host; this can be done by using setf of
logical-pathname-translations. 

	and then there's issue iss258-writeup which seems to support the
latter interpretation.

  If "foo" hasn't been defined but there is a translation file for "foo", is
the system allowed to autoload it and then parse the namestring as a LPN?
(Autoloading is what started the whole discussion.)

  Any comments or insights would be appreciated.

  Mike McDonald
  ·······@mikemac.com

From: Duane Rettig
Subject: Re: spec question wrt PARSE-NAMESTRING and logical pthnames
Date: 
Message-ID: <4ofvclwg1.fsf@beta.franz.com>
·······@mikemac.com (Mike McDonald) writes:

>   We're having a disagreement on the CMUCL mailing list about how to interpret
> the spec when it comes to parse-namestring and logical pathnames. The argument
> comes down to does the logical host have to be "defined" via '(setf
> (logical-pathname-translations ...' before parse-namestring will parse a
> namestring that has the syntax of a logical pathname as one?

But even further, the argument comes down to the question of whether a (setf
 (logical-pathname-translations ...)) is nesessary before the inverse
(logical-pathname-translations ...) returns a translation.  At the very
bottom of the logical-pathname-translations page it says "Implementations can
define additional functions that operate on logical pathname hosts, for example
to specify additional translation rules or options."  If those additional rules
(e.g. autoloading rules) happened to be fired _within_ the definition of
logical-pathname-translations itself, I would imaging that the definedness
of the host would not be in question.

>  One sides claims
> that "foo:bar;baz.lisp" should be parsed as a logical pathname irregardless of
> whether or not a translation for "foo" has been defined. The other side feels
> that if there is no translations for "foo" defined, then it should not be
> parsed as a logical pathname.

The definition of make-pathname is clear on that; the translation for the
host must be defined.  The real question is when the definition is necessary.
In Allegro CL, we treat the autoloading of l-p-t databases as being a part
of the answer to the question of whether a host has a logical-pathname-translation.
The actual logical-pathname-translation function won't return without an
answer in this sense, so it is always consistent (modulo the availability
and location of the database, but isn't this really part of what
logical-pathnames are for?)

>   The portions of the spec in question are:
> 
>   	from parse-namestring:
> 
> * 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 from 19.3.1.1.1 The Host part of a Logical Pathname Namestring:
> 
> The host must have been defined as a logical pathname host; this can be done by using setf of
> logical-pathname-translations. 
> 
> 	and then there's issue iss258-writeup which seems to support the
> latter interpretation.
> 
>   If "foo" hasn't been defined but there is a translation file for "foo", is
> the system allowed to autoload it and then parse the namestring as a LPN?
> (Autoloading is what started the whole discussion.)

I would vote "yes", if it is done as part of the implementation of
logical-pathname-translation.

>   Any comments or insights would be appreciated.
> 
>   Mike McDonald
>   ·······@mikemac.com

-- 
Duane Rettig          Franz Inc.            http://www.franz.com/ (www)
1995 University Ave Suite 275  Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253   ·····@Franz.COM (internet)
From: Mike McDonald
Subject: Re: spec question wrt PARSE-NAMESTRING and logical pthnames
Date: 
Message-ID: <HvGp6.7215$a3.14270@typhoon.aracnet.com>
In article <·············@beta.franz.com>,
	Duane Rettig <·····@franz.com> writes:
> ·······@mikemac.com (Mike McDonald) writes:

> In Allegro CL, we treat the autoloading of l-p-t databases as being a part
> of the answer to the question of whether a host has a logical-pathname-translation.
> The actual logical-pathname-translation function won't return without an
> answer in this sense, so it is always consistent (modulo the availability
> and location of the database, but isn't this really part of what
> logical-pathnames are for?)

  Does the ACL logical-pathname-translations signal an error when given the
name of a non logical host? There's that "If host is incorrectly supplied, an
error of type type-error is signaled." clause in the spec for whatever
"incorrectly supplied" means. A non string? "Mary had a little lamb" is OK? Or
does ACL treat a returned value of NIL to mean that it's not a logical host?

  Mike McDonald
  ·······@mikemac.com
From: Duane Rettig
Subject: Re: spec question wrt PARSE-NAMESTRING and logical pthnames
Date: 
Message-ID: <43dcofbbu.fsf@beta.franz.com>
·······@mikemac.com (Mike McDonald) writes:

> In article <·············@beta.franz.com>,
> 	Duane Rettig <·····@franz.com> writes:
> > ·······@mikemac.com (Mike McDonald) writes:
> 
> > In Allegro CL, we treat the autoloading of l-p-t databases as being a part
> > of the answer to the question of whether a host has a logical-pathname-translation.
> > The actual logical-pathname-translation function won't return without an
> > answer in this sense, so it is always consistent (modulo the availability
> > and location of the database, but isn't this really part of what
> > logical-pathnames are for?)
> 
>   Does the ACL logical-pathname-translations signal an error when given the
> name of a non logical host? There's that "If host is incorrectly supplied, an
> error of type type-error is signaled." clause in the spec for whatever
> "incorrectly supplied" means. A non string? "Mary had a little lamb" is OK? Or
> does ACL treat a returned value of NIL to mean that it's not a logical host?

The answers are yes, yes, yes, no.  Examples below.

CL-USER(1): (logical-pathname-translations 'a)
Error: A is not a defined logical pathname host
  [condition type: TYPE-ERROR]

Restart actions (select using :continue):
 0: Return to Top Level (an "abort" restart)
 1: Abort #<PROCESS Initial Lisp Listener>
[1] CL-USER(2): :pop
CL-USER(3): (logical-pathname-translations "sys")
((#p";**;*.*" #p"/tmp_mnt/net/spot/acl/6.0/bin/tru64/"
  #S(EXCL::CACHED-TRANSLATION-INFO :HOST NIL :DEVICE NIL :DIRECTORY NIL
                                   :NAME NIL :TYPE NIL :VERSION NIL))
 (#p"**;*.*" #p"/tmp_mnt/net/spot/acl/6.0/bin/tru64/"
  #S(EXCL::CACHED-TRANSLATION-INFO :HOST NIL :DEVICE NIL :DIRECTORY NIL
                                   :NAME NIL :TYPE NIL :VERSION NIL)))
CL-USER(4): (logical-pathname-translations "Mary had a little lamb")
Error: Mary had a little lamb is not a defined logical pathname host
  [condition type: TYPE-ERROR]

Restart actions (select using :continue):
 0: Return to Top Level (an "abort" restart)
 1: Abort #<PROCESS Initial Lisp Listener>
[1] CL-USER(5): :pop
CL-USER(6): (setf (logical-pathname-translations "Mary had a little lamb")
                    (logical-pathname-translations "sys"))
((#p";**;*.*" #p"/tmp_mnt/net/spot/acl/6.0/bin/tru64/"
  #S(EXCL::CACHED-TRANSLATION-INFO :HOST NIL :DEVICE NIL :DIRECTORY NIL
                                   :NAME NIL :TYPE NIL :VERSION NIL))
 (#p"**;*.*" #p"/tmp_mnt/net/spot/acl/6.0/bin/tru64/"
  #S(EXCL::CACHED-TRANSLATION-INFO :HOST NIL :DEVICE NIL :DIRECTORY NIL
                                   :NAME NIL :TYPE NIL :VERSION NIL)))
CL-USER(7): (logical-pathname-translations "Mary had a little lamb")
((#p";**;*.*" #p"/tmp_mnt/net/spot/acl/6.0/bin/tru64/"
  #S(EXCL::CACHED-TRANSLATION-INFO :HOST NIL :DEVICE NIL :DIRECTORY NIL
                                   :NAME NIL :TYPE NIL :VERSION NIL))
 (#p"**;*.*" #p"/tmp_mnt/net/spot/acl/6.0/bin/tru64/"
  #S(EXCL::CACHED-TRANSLATION-INFO :HOST NIL :DEVICE NIL :DIRECTORY NIL
                                   :NAME NIL :TYPE NIL :VERSION NIL)))
CL-USER(8): 


Also note, that we define an internal function, logical-host-p, which
determines whether the host is defined at the current time.  We also
allow an extra keyword argument in logical-pathname-translations, called
autoload.  The value of this argument determines whether or not autoloading
will be done before rejecting the host.  (this was necessary to remove
infinite recursions, in case the situation exists where the database is
specified to be in a location named by a logical pathname whose host is
not yet defined)


CL-USER(8): (excl::logical-host-p "clx")
NIL
CL-USER(9): (logical-pathname-translations "clx")
Error: clx is not a defined logical pathname host
  [condition type: TYPE-ERROR]

Restart actions (select using :continue):
 0: Return to Top Level (an "abort" restart)
 1: Abort #<PROCESS Initial Lisp Listener>
[1] CL-USER(10): :pop
CL-USER(11): (logical-pathname-translations "clx" :autoload t)
((#p";**;*.*" #p"sys:;code;"
  #S(EXCL::CACHED-TRANSLATION-INFO :HOST NIL :DEVICE NIL :DIRECTORY NIL
                                   :NAME NIL :TYPE NIL :VERSION NIL)))
CL-USER(12): (excl::logical-host-p "clx")
T
CL-USER(13): 

-- 
Duane Rettig          Franz Inc.            http://www.franz.com/ (www)
1995 University Ave Suite 275  Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253   ·····@Franz.COM (internet)
From: Kent M Pitman
Subject: Re: spec question wrt PARSE-NAMESTRING and logical pthnames
Date: 
Message-ID: <sfwelw828n5.fsf@world.std.com>
·······@mikemac.com (Mike McDonald) writes:

> We're having a disagreement on the CMUCL mailing list about how to
> interpret the spec when it comes to parse-namestring and logical
> pathnames.

The pathname section is hands down one of the worst written in the manual.
In a slim defense of its present state, you should have seen earlier drafts.
But still, I apologize for not untangling it better.  I plead simple lack 
f time.

> The argument comes down to does the logical host have to
> be "defined" via '(setf (logical-pathname-translations ...' before
> parse-namestring will parse a namestring that has the syntax of a
> logical pathname as one? One sides claims that "foo:bar;baz.lisp"
> should be parsed as a logical pathname irregardless of whether or
> not a translation for "foo" has been defined.

I don't think this.  This would cause you not to be able to access the file
maed "bar;baz.lisp" on a file host named "foo" which allowed ";" as an 
ordinary alphabetic.

I can't say for sure what the spec implies, but simple rationality implies
this.

> The other side feels
> that if there is no translations for "foo" defined, then it should
> not be parsed as a logical pathname.

This is what I think.  I'm not sure if the spec really says.
 
>   The portions of the spec in question are:
> 
>   	from parse-namestring:
> 
> * 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.  

I think this means "explicit logical host", but I agree there's wiggle room
here.  I think this gives you the freedom to "do the right thing".

Note, btw, that PS:FOO.LISP is both a "syntactically valid logical pathname"
AND a "syntatically valid native pathname for many operating systems"
It would be awful to preclude the latter interpretation.

> 	and from 19.3.1.1.1 The Host part of a Logical Pathname Namestring:
> 
> The host must have been defined as a logical pathname host; 
> this can be done by using setf of logical-pathname-translations. 

This appears to repair the vaguery of the above text in parse-namestring.

> 	and then there's issue iss258-writeup which seems to support the
> latter interpretation.
> 
>   If "foo" hasn't been defined but there is a translation file for "foo", is
> the system allowed to autoload it and then parse the namestring as a LPN?
> (Autoloading is what started the whole discussion.)

I think so.  19.3.1.1.1 doesn't say definition can't be done "other ways".
Nor does it say that an autoloadable definition can't, by virtue of having
been declared to autoload, be considered to be "defined".  That is, autoloading
can be seen as a data-caching issue rather than a definition issue.
 
>   Any comments or insights would be appreciated.

Disclaimer: Just because I typed some of the text into the standard
doesn't mean I'm any more authority than anyone else, including you.
For better or worse, when we approved the standard, the words themselves
became "what was meant" and anything we think we wanted to achieve was
superseded by what we actually did.   So the above is just my opinion,
as muddied by the passage of time.
From: Mike McDonald
Subject: Re: spec question wrt PARSE-NAMESTRING and logical pthnames
Date: 
Message-ID: <DnGp6.7214$a3.14270@typhoon.aracnet.com>
In article <···············@world.std.com>,
	Kent M Pitman <······@world.std.com> writes:
> ·······@mikemac.com (Mike McDonald) writes:

> I don't think this.  This would cause you not to be able to access the file
> maed "bar;baz.lisp" on a file host named "foo" which allowed ";" as an 
> ordinary alphabetic.

  Ahh, good point! I had always been thinking of ";" as a separator not as a
constituent char. Duh! :-)

> Note, btw, that PS:FOO.LISP is both a "syntactically valid logical pathname"
> AND a "syntatically valid native pathname for many operating systems"
> It would be awful to preclude the latter interpretation.

  As long as they don't name one of their hosts SYS. :-)

  Thanks for the info.

  Mike McDonald
  ·······@mikemac.com