Re: Issue: PATHNAME-LOGICAL (version 2)

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

I have a number of problems with this proposal...

I don't understand why there's any need for magic numbers (12 and 6)
and restrictions on what characters may appear in a logical pathname
component.  The rationale says this is an arbitrary decision, but
doesn't address the question of why restrictions are necessary at all. 

The proposal mentions that not all filesystems support versions and
that versions in logical pathnames can't be used portably.  More
generally, not all filesystems have notions of hosts, devices,
directories, and file types either.  (In other words, about the only
thing you can depend on a filename always having is a name.) Why treat
versions as a special case, but ignore all the other problems?

How are functions like OPEN supposed to map a logical pathname onto a real
pathname?  (Does it do it in the same way as TRANSLATE-LOGICAL-PATHNAME or 
can it use some other mapping?)

The dependence on issue PATHNAME-WILD (the functions PATHNAME-MATCH-P
and TRANSLATE-PATHNAME that are referenced in the description of
TRANSLATE-LOGICAL-PATHNAME) ought to be made more explicit.  What
happens if PATHNAME-WILD fails?

LOAD-LOGICAL-PATHNAME-TRANSLATIONS sounds suspiciously like REQUIRE --
I'm sure that's a bad sign... 

COMPILE-FILE-PATHNAME doesn't seem to have anything to do with the
rest of this proposal. 

In general, I don't really see what this proposal buys the user that
can't already be achieved using other mechanisms that are already part
of the language.  For example, when I have some files that live in
different places on different hosts, I usually put a pathname
containing the appropriate pathname for that place in a variable and
call MERGE-PATHNAMES to get the full pathnames of the individual
files.  Logical pathnames don't eliminate the necessity of having
literal, host-specific pathnames in a program; you still have to
supply them to DEFINE-LOGICAL-PATHNAME-TRANSLATIONS.

-Sandra
-------