Issue: PATHNAME-LOGICAL (Version 2)

[Kim Barrett <IIM@ECLA.USC.EDU>]

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.

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.

I'm somewhat concerned about mapping logical pathnames into real file systems
which don't support some or all of the capabilities of logical pathnames.  I'm
not too concerned about file systems which don't support heirarchical
directories, having not had the misfortune to encounter such a beast in a long
time.  Just out of curiosity, are there any such in common use above the micro
level (I've heard rumors of old IBM mainframe OS'es)?  As far as version
numbers, see above.

The main point I'm concerned about is the definition of a word.

1. Hyphens: I think hyphens can be dealt with fairly easily by translating them
into some non-alphanumeric supported by the file system, underscore being a
likely candidate.  Basically, the solution here is documentation.

2. Wild cards: Some file systems don't have very general support for wild
cards.  For example, MS-DOS effectively ignores anything following the first
"*" in a file name, limiting matches to a prefix plus wild-card suffix.  Of
course, a Common Lisp implementation could add a layer of filtering on top of
this, so I don't think this is so bad.

3. 12 character names: This is the main point I have trouble with.  There are a
lot of file systems out there which don't support 12 character names.  MS-DOS
has a limit of 8, except the type which is limited to 3.  I believe ITS is
limited to 6.

The problem is that the translation algorithm must be easy to use by people,
not just computers (specifically the Lisp implementation).

Part of the solution here may again be documentation.  As a suggestion, for
each of the system types described under PATHNAME-SYSTEM-TYPE (see that issue)
in the standard, the logical pathname mapping algorithm could also be
specified.  (Of course, this requires that people be able to agree to such).
Alternatively, add some verbiage to the description of logical pathnames saying
that some file systems are limited in the actual length of their logical
pathname words, and names should be chosen appropriately.  It may be safe to
"require" that at least 6 characters will be used, and treat these like
function and variable names in some languages which allow you to have long
names but which ignore all but the first n characters.  I'm actually somewhat
inclined toward the latter solution, since people seem to be able to live with
it in programming languages (though perhaps not being ecstatic about it) and it
frequently avoids the need to have to count characters, and if the number is
small (like 6) it is easier to "eyeball" whether you are over the limit than if
it is a larger number (like 12) (see the note on the examples below).

I suppose if you have PATHNAME-SYSTEM-TYPE you can always conditionalize your
pathnames somewhat depending on the file system type (ugly, and somewhat
defeats the point of this proposal).

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 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))

As a note, "A more complex example" contains a violation of the 12 character
limit:  "DOCUMENTATION" is 13 characters long.