Re: Issue: PATHNAME-LOGICAL (version 2)

[David N Gray <Gray@DSG.csc.ti.com>]

> I think these length limits were a mistake, and I propose to remove them in
> version 3 of the proposal.  It is always up to the person who writes the
> translation rules for a particular logical pathname host to a particular
> physical file system to make sure that the pathnames that are going to be
> used translate to valid pathnames for the particular file system.

That's true for logical directory names, but typically you would want to
specify translations just for the host and directory, and pass the file
names through.  If I'm trying to install a software package that came from
somewhere else, I wouldn't want to have to write a translation for every
individual file just because the author used abnormally long file names
and thought they were being portable.  Besides, I might not even know the
names of all the files that the program might generate internally.

>     >   There is no device, so the device component of a logical pathname is
>     >   always :UNSPECIFIC.  No other component can be :UNSPECIFIC.
> 
>     I presume you mean that the standard doesn't specify any portable
>     meaning for an :UNSPECIFIC component, and don't intend to rule out its
>     use in generic pathnames as an extension?
> 
> What's a generic pathname?

As returned by:   (SEND (PATHNAME ...) :GENERIC-PATHNAME)
[I don't expect that to be meaningful to anyone other than Lisp Machine
programmers.]  We use :UNSPECIFIC in the type and version slots of generic
pathnames; I see now that Symbolics uses NIL there instead.

> I think I meant what I said, which is that no component of a logical pathname
> other than the device can ever be :UNSPECIFIC.  If that's the wrong thing,
> okay, but let's hear an argument why it's wrong.

My concern is that the Explorer does have a use for :UNSPECIFIC type and
version in pathnames, including logical pathnames.  I won't argue that it
was a good idea to do it that way; it probably wasn't, but it would be
difficult to change now.  If the standard were to be interpreted
to mean that we can't do that, then we would need to have an internal
logical pathname type in addition to the standard one, which would be sure
to keep everyone confused.

All I'm asking for is to not put that restriction in language too strong;
I think we will be OK with anything less than "signals an error".

>     > 	...	To-wildcard must be a physical pathname or a 
>     >     coercible to a physical pathname. 
> 
>     Is there any reason to not permit this to be another logical pathname?
> 
> Yes, it's too complicated to define what it means	...

I just expected that TRANSLATE-LOGICAL-PATHNAME would repeat until it
produces a non-logical pathname.  I see now, though, that the second and
third values returned would be a problem.  Suppose we said that
DEFINE-LOGICAL-PATHNAME-TRANSLATIONS calls TRANSLATE-LOGICAL-PATHNAME on
each of the <to-wildcard> values to force them to be physical pathnames?

>	...	 and not obviously useful
> for anything (as far as I can see).

The point is that I should be able to use a pathname for nearly anything I
want without needing to know whether it is physical or logical.  If you
want an example, suppose the site administrator tells me that he has
created a directory "USERS:GRAY;" for me to use on some central name
server, and I then want to create a logical directory for some large
program of mine so that I can type "GIZMO:DATA;FOO" instead of
"USERS:GRAY;GIZMO;DATA;FOO".  Why should should I need to know or care
whether "USERS:" is a physical or logical host?  If you are thinking "but
logical pathnames have a different namestring syntax", that is not
necessarily true; on the Explorer, the local file system and logical
pathnames use the same syntax, which we find to be very convenient.

>     >     There are no keyword arguments specified by this standard, but any
>     >     implementation extensions are provided as keyword arguments or as
>     >     translations with more than two elements.
> 
>     An extension I would like to have is the ability to specify what syntax
>     will be used for parsing the name strings.  If I'm using logical
>     pathnames for my own convenience, rather than portability, then I would
>     like to be able to use whatever pathname syntax I like the most.
> 
> I don't understand, could you be more specific?

[This point is just an aside, not pertinent to the standard.  I mention it
because it is the only capability that I have wished to have in logical
pathnames that isn't covered by your proposal, so I'm pleased that it
could still be done as an extension.]

A logical host defines two things: 
 1. How to parse a namestring into a pathname object.
 2. How to translate a pathname into a physical pathname.
Why not be able to specify both parts instead of being stuck with a fixed
namestring syntax?  For example, I use a logical host to access my files
on the VAX just because I like the Explorer pathname syntax better than
the VMS syntax.  If someone else was a Unix fan, they might want to be
able to use Unix syntax for their logical namestrings.  Thus I would
envision being able to do something like 

  (define-logical-pathname-translations "mine"
     '(("mine:/data/*.*"  "vax:sys$user:[who.data]*.*"))
     :parser #'parse-unix-namestring)