withFile vs. openFile

Question

This program produces the output I expect when given an input file of text delimited by \n:

import System.IO

main :: IO ()
main = do h <- openFile "test.txt" ReadMode 
          xs <- getlines h
          sequence_ $ map putStrLn xs

getlines :: Handle -> IO [String]
getlines h = hGetContents h >>= return . lines

By substituting withFile for openFile and rearranging slightly

import System.IO

main :: IO ()
main = do xs <- withFile "test.txt" ReadMode getlines
          sequence_ $ map putStrLn xs

getlines :: Handle -> IO [String]
getlines h = hGetContents h >>= return . lines  

I manage to get no output at all. I'm stumped.

Edit: Not stumped anymore: thanks to one and all for the thoughtful and thought-provoking answers. I did a little more reading in the documentation and learned that withFile can be understood as a partial application of bracket.

This is what I ended up with:

import System.IO

main :: IO ()
main = withFile "test.txt" ReadMode $ \h -> getlines h >>= mapM_ putStrLn 

getlines :: Handle -> IO [String]
getlines h = lines `fmap` hGetContents h

Answer 1

The file is being closed too early. From the documentation:

The handle will be closed on exit from withFile

This means the file will be closed as soon as the withFile function returns.

Because hGetContents and friends are lazy, it won't try to read the file until it is forced with putStrLn, but by then, withFile would have closed the file already.

To solve the problem, pass the whole thing to withFile:

main = withFile "test.txt" ReadMode $ \handle -> do
           xs <- getlines handle
           sequence_ $ map putStrLn xs

This works because by the time withFile gets around to closing the file, you would have already printed it.

Answer 2

Ugh, did no one ever give the simple solution?

main :: IO ()
main = do xs <- fmap lines $ readFile "test.txt"
          mapM_ putStrLn xs

Don't use openFile+hGetContents or withFile+hGetContents when you can just use readFile. With readFile you can't shoot yourself in the foot by closing the file too early.

Answer 3

They do completely different things. openFile opens a file and returns a file handle:

openFile :: FilePath -> IOMode -> IO Handle

withFile is used to wrap an IO computation that takes a file handle, ensuring that the handle is closed afterwards:

withFile :: FilePath -> IOMode -> (Handle -> IO r) -> IO r

In your case, using withFile would look like this:

main = withFile "test.txt" ReadMode $ \h -> do
      xs <- getlines h
      sequence_ $ map putStrLn xs

The version you currently have will open the file, call getlines, then close the file. Since getlines is lazy, it won't get read any output while the file is open, and once the file is closed, it can't.

Answer 4

You're running into the usual hurdles of lazy IO... lazy IO sounds like an excellent idea, making streaming a snap until you start getting those awful problems.

Not that your particular case wouldn't be a red herring to an experienced Haskeller : this is the textbook example of why lazy IO is a problem.

main = do xs <- withFile "test.txt" ReadMode getlines
          sequence_ $ map putStrLn xs

withFile takes a FilePath, a mode and an action to do with the handle resulting from opening this filepath with this mode. The interesting part from withFile is that it is implemented with bracket and guarantee, even in case of exception, than the file will be closed after the action on the handle executes. The problem here is that the action in question (getLines) don't read the file at all ! It only promise to do so when the content is really needed ! This is lazy IO (implemented with the unsafeInterleaveIO, guess what the "unsafe" part means...). Of course by the time this content is needed (putStrLn), the handle was closed by withFile as promised.

So you have several solutions : You could use open and close explicitly (and relinquish exception-safety), or you could use lazy IO but put every action touching the file content in the scope protected by withFile :

main = withFile "test.txt" ReadMode$ \h -> do
         xs <- getlines h
         mapM_ putStrLn xs

In this case, this is not too awful, but you should see that the problem may become more annoying, if you ignore when the content will be needed. Lazy IO in a big and complex program may fast become pretty annoying, and when further limitation on opened handle numbers starts to matter... Which is why the new sport of the Haskell community is to come up with solutions to the problem of streaming content (instead of reading the whole files in memory which "solve" the problem at the cost of bloating memory use to sometimes impossible levels) without lazy IO. For a time it seemed as if Iteratee was going to become the standard solution, but it was very complex and hard to understand, even for experienced Haskeller, so other candidates have crept up lately : the most promising or at least successful at present seems to be "conduit".

Answer 5

As others have noted, hGetContents is lazy. You can, however, add strictness if you so desire:

import Control.DeepSeq

forceM :: (NFData a, Monad m) => m a -> m a
forceM m = do
  val <- m
  return $!! val

main = do xs <- withFile "text.txt" ReadMode (forceM . getlines)
          ...

Though it is generally recommended that you perform all IO related to the contents of the file inside of the withFile block instead. That way, your program can actually take advantage of the lazy file read, keeping only as much as necessary in memory. If you are dealing with a very large file, then forcing the whole file to be read into memory is usually a bad idea.

If you need more fine-grained control of resources, then you should look into using ResourceT (which comes with the conduit package) or similar.

[edit: use $!! from Control.DeepSeq (instead of $!) to make sure the whole value is forced. Thanks for the tip, @benmachine]