[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


I think the goal is to standardly allow those operations that are usually
implemented and are useful.

I thus think it is useful to address explicitly the questions Kent asks --
I don't think we can or should finess them.

I would prefer INPUT-STREAM-P and OUTPUT-STREAM-P to return false for
streams which do not admit input or output respectively, which, I think,
includes closed streams.


After a stream has been closed:

(STREAMP closed-stream)	returns true
(INPUT-STREAM-P closed-stream) returns false
(OUTPUT-STREAM-P closed-stream) returns false
(CLOSE stream) returns NIL (?)

All of the other functions in the list are the ones that that accept a
stream and coerce it to a pathname work at least as specifically as they
would with the open stream. (This is subject to some further work on the
pathname functions; the idea is that once the stream is CLOSEd that the
stream object may have *more* specific pathname information associated with
it than before, and that in some way the pathname used should be
best-effort name to get at the same data. )

The point here is that if I want to write out some data and read it back in
later, I should be able to

(let((saved-file (pathname (with-open-file (x pathname :direction :output)
(print stuff x) x))))
   (with-open-file (x saved-file :direction :input)
       (read x)))

and expect the second with-open-file to get at the same data that the first
one wrote.

The operation of CLOSE on constructed streams (as constructed with
WITH-OUTPUT-TO-STRING or MAKE-BROADCAST-STREAM) should be specified to have
no effect.