On Sun, 2008-04-20 at 14:24 -0700, Bryan O'Sullivan wrote:

Doh! For all that I wrote about encodeFile, substitute decodeFile.

Indeed the version of encodeFile you wrote should be exactly identical to the original because the lazy bytestring writeFile already uses bracket like that: writeFile :: FilePath -> ByteString -> IO () writeFile f txt = bracket (openBinaryFile f WriteMode) hClose (\hdl -> hPut hdl txt)

strictDecodeFile :: Binary a => FilePath -> (a -> b) -> IO () strictDecodeFile path force = bracket (openFile path ReadMode) hClose $ \h -> do c <- L.hGetContents h force (decode c) `seq` return ()

Yes, the problem with Ben's program was that decodeFile is lazily reading the file and lazily decoding. If the decoding consumes all the input then it should be possible to avoid rewriting decodeFile and use: dat2 <- decodeFile fname evaluate dat2 removeFile fname It's not immediately clear to me if we can make the decodeFile behave like your version. I'd have to go think about whether running the Get monad can lazily return values or if it always consumes all the input it'll ever need. Duncan

Am Montag, 21. April 2008 01:35 schrieb Ben:

FWIW, installed bytestring-0.9.1.0, ran ghc-pkg hide bytestring-0.9.0.1, recompiled and reinstalled binary-0.4.1. then i played around with all that you suggested, and came to the conclusion that i don't understand seq!

import Control.Exception (bracket) import System.Directory import System.IO import Data.Binary import Data.ByteString.Lazy as B

strictDecodeFile :: Binary a => FilePath -> (a -> b) -> IO () strictDecodeFile path force = bracket (openFile path ReadMode) hClose $ \h -> do c <- B.hGetContents h force (decode c) `seq` return ()

This means that force (decode c) is reduced to head normal form, not fully evaluated. So if the result type of force were e.g. Either String Int, it would be evaluated just far enough to determine if force (decode c) is bottom, Left something or Right somethingelse; Left undefined and Right undefined won't cause an exception. In the case below, force (decode c) is an IO action, it will be evaluated as far as necessary to see it's (IO whatever) and not bottom, for that it need not be run, therefore you don't see "strict 1" printed out.

strictDecodeFile' :: Binary a => FilePath -> (a -> IO b) -> IO () strictDecodeFile' path force = bracket (openFile path ReadMode) hClose $ \h -> do c <- B.hGetContents h force (decode c) return ()

Here you say you want the IO action force (decode c) to be run, so it is run and "strict 2" is printed out. Hope that helps.

one more piece of email pollution: import Control.Exception (bracket) import System.IO import Data.Binary import qualified Data.ByteString.Lazy as B strictDecodeFile :: Binary a => FilePath -> IO a strictDecodeFile path = bracket (openBinaryFile path ReadMode) hClose $ \h -> do c <- B.hGetContents h return $! decode c seems to work like Data.Binary.decodeFile but explicitly closes the handle. take care, ben On Sun, Apr 20, 2008 at 4:35 PM, Ben wrote:

FWIW, installed bytestring-0.9.1.0, ran ghc-pkg hide bytestring-0.9.0.1, recompiled and reinstalled binary-0.4.1. then i played around with all that you suggested, and came to the conclusion that i don't understand seq!

import Control.Exception (bracket) import System.Directory import System.IO import Data.Binary import Data.ByteString.Lazy as B

strictDecodeFile :: Binary a => FilePath -> (a -> b) -> IO () strictDecodeFile path force = bracket (openFile path ReadMode) hClose $ \h -> do c <- B.hGetContents h force (decode c) `seq` return ()

strictDecodeFile' :: Binary a => FilePath -> (a -> IO b) -> IO ()

strictDecodeFile' path force = bracket (openFile path ReadMode) hClose $ \h -> do c <- B.hGetContents h force (decode c) return ()

main = do let dat = [1..10]::[Int] fname = "foo.dat" encodeFile fname dat h <- openFile fname ReadMode c <- B.hGetContents h let dat2 = decode c print (dat == dat2) hClose h removeFile fname

encodeFile fname dat strictDecodeFile fname (\x -> do print "strict 1" print (x == dat)) removeFile fname

encodeFile fname dat strictDecodeFile' fname (\x -> do print "strict 2" print (x == dat)) removeFile fname

encodeFile fname dat dat4 <- decodeFile fname print (dat == dat4) removeFile fname

running main outputs

True "strict 2" True True *** Exception: foo.dat: removeFile: permission denied (Permission denied)

e.g. the handle version works, Bryan's original strictDecodeFile appears to not run "force", the modified strictDecodeFile' does run "force" (i didn't use seq, just an additional line in the monad), and the encodeFile / decodeFile / removeFile appears to still not work with the latest bytestring. what's the difference between the seq and non-seq versions?

for now i can use strictDecodeFile' but at least something should be said in the docs about decodeFile et al holding handles. (i understand this is not the fault of binary per se as much as haskell's non-strict semantics, but a reminder for noobs like me would be helpful.) and finally something like strictDecodeFile' might be useful in the library?

thanks for the help, ben

On Sun, Apr 20, 2008 at 2:34 PM, Duncan Coutts wrote:

...

On Sun, 2008-04-20 at 14:24 -0700, Bryan O'Sullivan wrote:

...

Doh! For all that I wrote about encodeFile, substitute decodeFile.

Indeed the version of encodeFile you wrote should be exactly identical to the original because the lazy bytestring writeFile already uses bracket like that:

writeFile :: FilePath -> ByteString -> IO () writeFile f txt = bracket (openBinaryFile f WriteMode) hClose (\hdl -> hPut hdl txt)

...

strictDecodeFile :: Binary a => FilePath -> (a -> b) -> IO () strictDecodeFile path force = bracket (openFile path ReadMode) hClose $ \h -> do c <- L.hGetContents h force (decode c) `seq` return ()

Yes, the problem with Ben's program was that decodeFile is lazily reading the file and lazily decoding. If the decoding consumes all the input then it should be possible to avoid rewriting decodeFile and use:

dat2 <- decodeFile fname evaluate dat2 removeFile fname

It's not immediately clear to me if we can make the decodeFile behave like your version. I'd have to go think about whether running the Get monad can lazily return values or if it always consumes all the input it'll ever need.

Duncan