Questions about OPEN

[Rob MacLachlan <RAM@CMU-CS-C.ARPA>]

    I concede those points, and was aware that, for example,
Rename-File has somewhat different semantics on a stream than it has
on the name.  I can deal with that, since all we have to do in Spice
Lisp to implement this is change the name we write the data out as
when we close the file.  You clarification, however, seems to assume
that there is some concept of file identity independent of the file
name.  This is not true in Sesame, and is probably not true in many
file systems.  There is no way to keep track of a file across
renamings and other operations.

    I guess we have several options here:
 1] We can leave the manual the way it is, with the semantics of use
of streams vis a vis pathnames largely unspecified.  This would permit
implementations to do arbitrarily whizzy things, but would make the
use of stream arguments difficult in portable code, and thus dubious
as a Common Lisp feature.
 2] We can try to define the semantics.  This course is fraught with
peril, since capabilities of operating systems differ wildly.
 3] We can punt and remove them.

    In many cases, the CLM seems to do 1, on the grounds that it would
be nice to have a standard way to say X, given that X is possible.  I
have mixed feelings about this.  In the case of the
:If-Exists/:If-Does-Not-Exist arguments to Open, it seems reasonable,
since even an inconceivably brain-damaged OS should be able to provide
some sort of reasonable default action, and the program will still
work.  In the case of Rename-File, though, the call will error out,
(or worse, simply quietly fail) if the capability to rename open files
doesn't exist.  A program counting on this feature would not work, and
thus would not be portable.

    I think that this business of streams-as-files is especially
problematical in our implementation, since there is no "file attached
to the stream", only a memory buffer area where you are building up a
file that you may write out when the stream is closed.  Sesame is in
fact a system such as you mentioned, in which it is impossible to
determine the truename of an "open" file, since the version number is
determined when the file is written.  It seems to me that this
argument could just as easily be used to support the position that the
feature should be flushed as being impossible to specify in a
implementation independent fashion.

    For us, the Probe-File and Truename functions are the most
annoying.  The Rename-File and Delete-File functions, which don't have
to work right according to the CLM, are easily implementable.
Currently, our implementation does not obey the
    (probe-file (open ...)) => t
invariant.  We could dummy it up so that it would return the pathname
that it thinks it is going to write the file out to, but that would
cause anomalous behavior such as:
    (probe-file stream) => <some pathname>
    (probe-file <some-pathname>) => nil

  Rob