Re: Issue: PATHNAME-LOGICAL (version 2)

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

Just a few short comments:

> I think these length limits were a mistake, and I propose to remove them
> in version 3 of the proposal.

Sounds good.  Actually, I think that a logical pathname should permit any
values that are hypothetically valid (under PATHNAME-COMPONENT-VALUE) as
components.

> However, the typical
> use of versions is such that on a file system without versions, people
> would rather just store one version, and not specify translations that
> will preserve the version information by encoding it in the name.  This
> is different from the typical use of types or directories, where the
> files with different values in those components are truly distinct and
> everything would break if you only kept one of them.

This makes sense to me, but probably ought to be included somewhere in
the proposal as a rationale.

> I thought it said somewhere that PATHNAME-LOGICAL cannot pass if
> PATHNAME-WILD fails.

It does, but it's way down in the discussion section.  (It happened
that I originally read this writeup before the one for PATHNAME-WILD
and I was very confused by the references to TRANSLATE-PATHNAME and
PATHNAME-MATCH-P until I recognized that they were from another issue
I hadn't seen yet.)  As you've noted yourself in connection with some
other issues, a lot of people don't make it to the end of the writeup. 

> I could have proposed that logical pathnames always use a specific naming
> convention for compiled files, as I did for source files, but for compiled
> files it seemed better to let the implementation control the name.  Do
> you think a different approach should have been taken, or did you just
> want to see this proposal split into parts?

If there is going to be a convention for the name of source files, I
would rather see a similar convention adopted for the name of compiled
files.

Perhaps I should add a little here about how we handled pathnames
while working on porting PSL to various machines, including the
infamous Cray.  First, we used variables as I outlined in my previous
message to keep track of "places" and "file types" to look for library
files, instead of using literal namestrings all over the place.  The
variables were initialized in a separate configuration file.  Second,
we had the file open function do its own translation to take care of
mapping pathnames onto namestrings that were recognizable to the host
file system; this is where the namestring got mangled to account for
case canonicalization and truncation appropriate to that host, if
there wasn't a specific mapping for that filename known.  In effect,
we treated all pathnames as logical pathnames!  Over time, PSL has
gravitated towards using Unix filename syntax for "logical"
namestrings.

-Sandra
-------