John A. De Goes schrieb:
Elsewhere, laziness can be a real boon, so I don't understand your question, "Why have laziness in Haskell at all?"
As I have written, many libaries process their data lazily (or could be changed to do so without altering their interface) but their interface can forbid application to data that is fetched from the outside world. Say you are used to 'map', 'filter', 'foldr' - you cannot use them on data fetched by the iteratee/enumerator approach.
Thank you for replying to this; it's good to see what features people would like to make iteratees more useful. Where did you get the idea that you can't use 'map'? IterateeGM is a Monad and Functor, so fmap is available for the resultant value. If you want to map over the elements of the stream, use the 'mapStream' function ('map_stream' in Oleg's writings). I never thought about writing a general iteratee fold because that's all iteratees are anyway; it's simple enough to make a foldl. It should be possible to write foldr for seekable resources by enumerating the stream backwards. That certainly wouldn't work for network I/O, unfortunately. Note that this is essentially the approach taken by lazy bytestrings, for example. There are other elements I'd want to address before adding this, however. There are also complications dealing with nested streams. I have some ideas, but the way forward is far from clear. filter should be fairly simple to implement with peek and drop. I'll look into it. Cheers, John