Questions about OPEN

[Kent M Pitman <KMP @ MIT-MC>]

Everyone has spoken about what they think the published word says will
happen, but no one has really said anything about what users might in 
fact need.

If I'm writing code that works on an open file and wants to know
the truename, it is generally so I can either record information
somewhere (eg, type "Script file PS:<JDOE>FOO.TEXT.7 opened." on the
console) or so I can use the information in some formal operation 
(such as producing a new pathname from the truename to put next to
it in a directory). If I care about matching version numbers for some
reason (eg, I want "FOO.OUTPUT.7" to accompany "FOO.INPUT.7"), then
it may then be important to me that I get back #<Path "FOO.TEXT.7">
from truename and not #<Path "FOO.TEXT.newest"> and it's a pain to
have to write the code that probes FOO.TEXT for numberness (or zeroness,
in the case of Twenex, or...).

I agree with Moon that functions that can't fulfill their contract due
to OS limitations should err, but I know that I have always been willing
to use heuristic information in this particular area and I think that
in some cases relaxing the definitions a little could work pretty well.
Eg, TRUENAME might return two values, a pathname and a boolean saying
whether that pathname was really the truename or just a good guess.
This, I think, would provide the user with all the information that either
kind of operating system could provide without being too obtrusive.
If someone thinks this would occasionally do the wrong thing, it could
be safeguarded by taking an optional arg ERROR-P, default T, which if
true would signal an error before returning a second value of NIL, so
the person would have to do (TRUENAME obj NIL) to get back two values.

I would tend to oppose solutions to these issues which will hide useful
information for the sake of generality, preferring to support solutions
which present all the known data to the user in a flexible way and leave
him to decide about how to handle the problem.

By the way, I believe that the decision to have TRUENAME err rather than
return multiple values is partly influenced by the fact that the LispM
now has a sophisticated condition-handling system which can make use
of complicated information conveyed in error objects. Since Common-Lisp
error handling primitives are not so sophisticated -- good grief, I just
checked the manual and there's not even an ERRSET primitive; let me ammend
that -- since Common-Lisp error handling primitives are quite literally
non-existent, there is no way a user can even do:
  (OR (IGNORE-ERRORS (TRUENAME ...)) (PATHNAME ...))
right now if he expects a problem. But certainly if we expect this to be
a common case, allowing something like the above-proposed
(TRUENAME ... NIL) would be more concise and informative.
-kmp