Iterators:
Was working with iterate, and noticed this issue. I did a quick-n-dirty fix to get rid of it (copy and paste to a new in-ostream driver). But I thought: Is there actually a good reason to close the stream at the end of the loop? Or, is there a correct way to make in-stream not close the stream that I should have been using?
If not, and if there is still development going on for iterate, I can fix it up more nicely and submit a patch. My thoughts:
- in-stream should, by default, not close the stream. Unlike in-file, we should expect that the stream was created by some process that will handle closing the stream at the end, such as with-open-file.
- If the user wants to close the stream at the end, he should do something like (finally (close stream)). More complicated abstractions here aren't really helpful.
I had also been thinking that in-stream/in-file could be modified to make it easier to pass them user-defined reading functions, but that's another post.
Daniel
В сообщении от Wednesday 22 October 2008 01:29:48 daniel radetsky написал(а):
Iterators:
Was working with iterate, and noticed this issue. I did a quick-n-dirty fix to get rid of it (copy and paste to a new in-ostream driver). But I thought: Is there actually a good reason to close the stream at the end of the loop? Or, is there a correct way to make in-stream not close the stream that I should have been using?
If not, and if there is still development going on for iterate, I can fix it up more nicely and submit a patch. My thoughts:
- in-stream should, by default, not close the stream. Unlike in-file,
we should expect that the stream was created by some process that will handle closing the stream at the end, such as with-open-file.
- If the user wants to close the stream at the end, he should do
something like (finally (close stream)). More complicated abstractions here aren't really helpful.
I had also been thinking that in-stream/in-file could be modified to make it easier to pass them user-defined reading functions, but that's another post.
I think that by default, it should not close the stream. But rather it should have an option to close it. (finally (close stream)) is not good, because stream closing should be done also in case of stack unwinding. The reason for closing is that stream might be created by in-place.
My idea is of something like this: (iter (for x in-stream (open-file .....) close-stream t))
On Tue, Oct 21, 2008 at 9:15 PM, Kalyanov Dmitry kalyanov.dmitry@gmail.com wrote:
stream closing should be done also in case of stack unwinding.
Right, and it will be done if I write, e.g.
(with-open-file (stream ... ) (iter (for x in-stream stream) (foo x)))
that stream might be created by in-place.
My idea is of something like this: (iter (for x in-stream (open-file .....) close-stream t))
Iterate already has a mechanism for this: the in-file driver, which already does (and should) close the stream.
The point is, when you pass a stream to the driver, iterate doesn't know what the stream is, what you want to do with it, or anything. Why should it close the stream, especially when streams are generally created inside UNWIND-PROTECT-based macros?
"daniel radetsky" dradetsky@gmail.com writes:
My idea is of something like this: (iter (for x in-stream (open-file .....) close-stream t))
That's not a bad idea, but it would be nice if close-stream defaulted to true.
Why should it close the stream, especially when streams are generally created inside UNWIND-PROTECT-based macros?
That is not the case I most commonly use. Typical usage is:
(iter (for x :in-stream (make-my-stream)) ...)
This is shorter and more convenient than the equivalent (assuming the CLOSE-STREAM option):
(with-open-stream (s (make-my-stream)) (iter (for x :in-stream s :close-stream nil) ...)
And you don't even really need the CLOSE-STREAM option in this case, since all we would do is close the stream twice.
(Of course, Both of these have a CLOSE inside an UNWIND-PROTECT block.)
Cheers, Chris Dean
-
Chris Dean -
daniel radetsky -
Kalyanov Dmitry