Questions about OPEN

["David A. Moon" <Moon@SCRC-RIVERSIDE.ARPA>]

    Date: Fri, 5 Oct 1984  02:46 EDT
    From: 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.

Is there really such a big issue here?  All the functions in section
23.3 are allowed already to have implementation-dependent variations
(note at the head of the section).  OPEN is allowed similar freedom
(note on page 421).  All the other functions, other than TRUENAME, when
given a stream simply convert it into a pathname.  In fact I can find
nothing in the manual that says how this is done!  But I'm sure the
intention is that PATHNAME when applied to a stream simply returns the
argument that was given to OPEN to create that stream (coerced to a
pathname of course).  So I think the only function with a real problem
is TRUENAME.  I believe that the note at the front of section 23.3 ought
to be applied to TRUENAME as well, word for word.

	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.

The CLM doesn't say this, but I would hope that these functions are guaranteed
either to do what the manual says or to signal an error, not to quietly ignore
the request or anything like that.  This can be pernicious -- we just found a
bug of such nature this week.  I believe that it is okay for a Common Lisp
implementation to signal an error for any file operation, saying "the underlying
file system our implementation is built on is incapable of implementing that
Common Lisp function, too bad".  I no more believe that Common Lisp implementors
should be required to rewrite their host operating systems than I believe that
they should be required to redesign their host hardware.  Of course this means
that some programs will be more portable than others, and some programs will
port to some implementations but not others.  In practice that is always the
situation and there is nothing you can do about it.  But I believe the note
at the front of section 23.3 ought to be changed to say that these functions
will either work or signal an error.  None of them need "is an error" freedom
since they aren't operations whose efficiency matters.

    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

I believe the statement under PROBE-FILE, "Note that if the file is an open
stream associated with a file, then probe-file cannot return NIL but will
produce the true name of the associated file" to be bogus.  I think PROBE-FILE
should simply call PATHNAME to coerce its argument to a pathname, as the
functions in 23.1 and 23.2 do, rather than treating streams specially, as
the other functions in 23.3 do.  I think your argument above is convincing
and my suggested change would make things more consistent.