In general I think it is good, when the one who opens a stream is also responsible for closing it.

That policy thwarts modularity, doesn't it?  Just as does the policy of whoever allocates memory is responsible for freeing it.  Laziness, like garbage collection, is mainly about modularity (as expressed and demonstrated in "Why functional programming matters").

So I'd recommend an automated, GC-based solution.  GHC has weak references and finalizers for this sort of thing.  I think there's room for improvement of the current implementation of finalizer scheduling for timely resource deallocation.  We've had to deal with this problem for managing graphics memory, in order to make functional graphics efficient.

   - Conal

2008/11/28 Henning Thielemann <lemming@henning-thielemann.de>

On Thu, 27 Nov 2008, Henning Thielemann wrote:

I have HTTP-3001.0.4 and I like to check the HTTP response headers before downloading the entire document.

I have tried to solve this on my own. I have written a wrapper to any stream type. It first reads the entire document lazily into a string and then ships its contents when readBlock or readLine is called. However, the program blocks on 'close' now and I don't know why. (See LazyStream.example)

When looking at Network.HTTP.sendHTTP I wonder whether it is a good idea, that sendHTTP closes the stream automatically when it finishs (and also when an exception is raised). In general I think it is good, when the one who opens a stream is also responsible for closing it.
 For a lazy stream, the current implementation of sendHTTP would fail, since when sendHTTP quits, the data is still not read, and when some processes the HTTP response, data will be lazily read from a closed stream.

_______________________________________________
web-devel mailing list
web-devel@haskell.org
http://www.haskell.org/mailman/listinfo/web-devel