[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: PATHNAME-STREAM (Version 5)
- To: Masinter.pa@XEROX.COM
- Subject: Issue: PATHNAME-STREAM (Version 5)
- From: Ram@C.CS.CMU.EDU
- Date: Fri, 23 Oct 1987 13:46 EDT
- Cc: CL-Cleanup@SAIL.STANFORD.EDU
- In-reply-to: Msg of 23 Oct 1987 12:52-EDT from Masinter.pa at Xerox.COM
- Sender: RAM@λλ
Date: Friday, 23 October 1987 12:52-EDT
From: Masinter.pa at Xerox.COM
To: CL-Cleanup at sail.stanford.edu
cc: MASINTER.pa at Xerox.COM
Re: Issue: PATHNAME-STREAM (Version
[...] I enhanced the discussion section, and added a reference to
p. 417 "the name returned represents the name used to open the
file, which may not be the actual name of the file".
I'm actually puzzled now as to whether it is legal to do with Xerox
Common Lisp does, which is only remember the TRUENAME of a stream once
the stream is open. The language on p. 417 seems to imply that it is
necessary also to remember the pathname supplied to open. Clarification?
I think that this should be read as a warning that PATHNAME on an open
stream doesn't necessarily return the truename of the file ultimately
written, or even necessarily the truename of any file that ever
existed or will exist.
If this is read as a strict requirement, then it is pretty clearly
wrong, since presumably if you do a RENAME-FILE on the stream, you want
PATHNAME of that stream to return the new name, rather than the name
it was originally opened with.
If you are trying to clean up the rot with streams as pathnames, you
should carefully look over section 23.3 pp 423-425, as many of these
functions are suggested to do something semantically different with a
stream argument as with PATHNAME of that stream argument.
For example, the claim that PROBE-FILE should never return NIL when
called on an open stream is pretty clearly wrong. In some
implementations, the file doesn't exist at all until the stream is
closed. I believe the semantics of PROBE-FILE on a stream should in
fact be the same as PROBE-FILE on PATHNAME of that stream, but maybe
we shouldn't guarantee that.
Calling TRUENAME on a stream open for output is also highly suspect,
since it is possible that the ultimate name of the file cannot be
predicted, even disregarding possible renamings. (consider version
In our implementation, TRUENAME just calls PROBE-FILE and then
complains if the result is NIL. This means that TRUENAME on an open
stream can signal an error. If this violates someone's TRUENAME
invariants, then we should firm up the definition of TRUENAME