[Haskell] Re: state of HaXml?

[Samuel Bronson]

On 1/4/07, Norman Ramsey <nr at eecs.harvard.edu> wrote:
>  > There seems to be a misunderstanding here: readFile in itself is not the
>  > solution.  readFile is defined thus:
>  >
>  > readFile name        =  openFile name ReadMode >>= hGetContents
>  >
>  > and the original code was this:
>  >
>  >    load fn = do handle <- IO.openFile fn IO.ReadMode
>  >                 contents <- IO.hGetContents handle
>  >                 IO.hClose handle
>  >                 return $ XP.xmlParse fn contents
>  >
>  > Sure, you can replace the openFile/hGetContents pair by readFile, but the
>  > real problem is the presence of the hClose.  Removing that will solve your
>  > problem (but note that you now have no control over when the file is
>  > actually closed).
>
> Can I just leave it hanging and rely on the garbage collector to close
> it in the fullness of time?

Actually, hGetContents closes the handle when it gets an EOF.

If it never does get EOF (because you never use all of the data), the
garbage collector *might* close the handle, but I haven't heard of a
garbage collector that was aware of the value of resources other than
RAM (that is, they don't go out of their way to run finalizers and
free up handles to OS resources). Java has the same problem, though
I'm not sure if its file handles *have* finalizers, and Python does
too, except the refcounting in CPython right now hides it.