David Place wrote:
Heinrich Apfelmus wrote:
Personally, I think that lazy IO is not a weakness and works extremely well for prototyping. In contrast, I find IterateeIO to be ugly and non-idiomatic Haskell, since it exposes implementation details and is not built on an algebraic "combinators & laws" approach. Being challenging to understand is not a substitute for beauty.
Interesting, I appreciate your point of view. My experience with Lazy IO is that its non-determinism breaks down the algebraic/equational intuition. In order to manage handle resources, I must have in mind too many operational details.
Well, one could say that it's the fault of the operating system for not doing garbage collection on file handles (c.f. Oberon).
I feel that iteratee IO encapsulates these in nice compositional combinators.
What about the combinator withFile :: FilePath -> (String -> a) -> IO a withFile name f = bracket (openFile name ReadMode) hClose $ \h -> evaluate . f =<< hGetContents h ? It gives you the same thing as Iteratees - a way to apply a function to the contents of a file - without the need to rewrite all the existing list functions like map , lines , words , and so on.
I agree that it's not very beautiful, though. My feeling is that it is not quite finished. Perhaps there are a couple of more insights that will make it really nice.
I'm all for beauty in programming. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com