[iterate-devel] in-stream closes stream at the end: bad idea?

Kalyanov Dmitry kalyanov.dmitry at gmail.com
Wed Oct 22 04:15:54 UTC 2008


В сообщении от 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))
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <https://mailman.common-lisp.net/pipermail/iterate-devel/attachments/20081022/407da025/attachment.sig>


More information about the iterate-devel mailing list