Re: Issue: PATHNAME-LOGICAL (Version 2)

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

> Is there really any need to allow integers for version numbers here?  My
> experience has been that anytime I've used logical pathnames in a place where I
> actually needed them (as opposed to just typing, so I don't have to keep
> worrying about different syntaxes), using explicit version numbers was a bad
> idea even when dealing with a file system that supported them.

So what's wrong with using logical pathnames for "just typing"?  I think
that inappropriate use of version numbers is an issue of good programming
practice that is no more related to logical pathnames than it is to
physical pathnames.

> Re: LOGICAL-PATHNAME type.  Why?  I think there may be a hidden assumption
> about implementation technique here, namely that pathnames for different file
> system types will be different subtypes of PATHNAME.  I don't see anything else
> in the proposal that needs this, since a "logical pathname" could also be
> defined as a pathname whose host is a logical pathname host.

It would permit methods specialized on LOGICAL-PATHNAME and PATHNAME to
distinguish whether a translation is needed, although I'm not sure that is
really useful since asking for a translation on a physical pathname
doesn't hurt.  You may be right that the standard doesn't need to specify
this. 

> There may be an ambiguity in the logical pathname description, namely is ".5" a
> pathname with version == 5 and everything else unspecified, or is the type ==
> "5" and everything else is unspecified.

I think that the way the brackets are nested in the syntax makes it
unambiguous that if there is only one dot, it is the type.  This could,
however, be confusing for humans.

> I was wondering why add a function like COMPILE-FILE-PATHNAME, rather than just
> defining another canonical type analogous to "LISP", like "BIN" or "FASL" or
> some other name.  I suppose it avoids arguments about what the 'right' name is,
> although I personally don't care about the precise name used.  The only reason
> I can think of is to allow COMPILE-FILE to generate a name that isn't just the
> result of something like
> 
>   (merge-pathnames output-file (make-pathname :type *compiled-file-type*
> 					      :defaults input-file))

You also need to be able to merge with an explicit :OUTPUT-FILE argument.
Then there is the question of version number:  is it always :NEWEST, or
the same as specified for the input, or the same as the truename of the
input file?  What if the input and output are on different hosts and one
supports versions and the other doesn't?  On the Explorer, there is a
special variable to control how versions are handled, and the code to
compute the output pathname for COMPILE-FILE is some 60 lines long.  So it
is not trivial.