
Konstantin, Please allow me to elaborate on Dan's point -- or at least the point that I believe that Dan is making. Using, let bug = Control.DeepSeq.rnf str `seq` fileContents2Bug str or ($!!) will create a value that *when forced* cause the rnf to occur. As you don't look at bug until much later this causes the same problem as before! His addition of evaluate forces the rnf to happen before proceeding. On a more ad hoc basis you might say let !bug = fileContents2Bug $!! str but without the bang-pattern or the evaluate, which is arguably strictly better (er no pun intended) from a semantics perspective nothing has happened yet until someone inspects bug. With the code as structured this doesn't happen until it is too late. -Edward On Mon, Mar 18, 2013 at 1:11 PM, Konstantin Litvinenko < to.darkangel@gmail.com> wrote:
On 03/18/2013 06:06 PM, Dan Doel wrote:
Do note that deepSeq alone won't (I think) change anything in your current code. bug will deepSeq the file contents.
rfn fully evaluate 'bug' by reading all file content. Later hClose will close it and we done. Not reading all content will lead to semi closed handle, leaked in that case. Handle will be opened until hGetContents lazy list hit the end.
And the cons will
seq bug. But nothing is evaluating the cons. And further, the cons isn't seqing the tail, so none of that will collapse, either. So the file descriptors will still all be opened at once.
Probably the best solution if you choose to go this way is:
bug <- evaluate (fileContents2Bug $!! str)
which ties the evaluation of the file contents into the IO execution. At that point, deepSeqing the file is probably unnecessary, though, because evaluating the bug will likely allow the file contents to be collected.
evaluate do the same as $! - evaluate args to WHNF. That won't help in any way. Executing in IO monad doesn't imply strictness Thats why mixing lazy hGetContent with strict hOpen/hClose is so tricky.
______________________________**_________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe