[web-devel] Re: Lazy simpleHTTP

[Conal Elliott]

>
> 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 at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/web-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/web-devel/attachments/20081128/c80a5361/attachment.htm