Moved to haskell-cafe...
Thanks for your comments. (I had overlooked "readFile", which certainly looks safer. I'm not yet fully used to the distribution of functions between standard libraries and the Prelude. As for my 'hSafeGetContents', I realized exactly your point about using 'id' too late, after I'd sent my email. :-( )
I've done this many many times...too often do I find myself in the state of "open mouth, insert foot." People tend to be pretty forgiving though.
The broader debate I was trying to evoke was: how, as a programmer using a combination of monads and non-strict functions, can I be confident that there aren't hidden interactions waiting to bite?
Well, I think it's more the combination of *strict* monads and non-strict functions that causes trouble. In fact, as pointed out before, lazy IO uses unsafeInterleaveIO to work. I think the rationale for lazy IO is clear. Without lazy IO, the following program, when run on a 2gb file, will allocate 2gb of memory:
main = interact (map toUpper)
whereas, with lazy IO, it will run in constant (small) space. I think the point of lazy IO (and people who designed it can probably speak better to this) is to allow people to continue to write pure functions. That is, without lazy IO, the above would have to be written something like:
main = do b <- hIsEOF stdin when (not b) $ do c <- hGetChar stdin putChar (toUpper c) main
or something like that. obviously in *this case*, we would prefer to use the pure function map. However, in order to use map, we need to only read in characters as they are demanded, which means we need lazy IO. I think that what it really boils down to is you need to ask yourself: am I benefiting by using lazy IO. In the 'interact (map toUpper)' case, clearly you are, so you should probably continue to you it. However, in a case where you know you're going to read the whole file and store it in some data structure and need to simultaneously use data from the beginning and end of the file, then you're probably not benefiting from lazy IO. It is somewhat unfortunate that the IO library doesn't contain strict versions of all the operations, but they're easy enough to write with DeepSeq in your pocket.
Using the hOpen ... hClose vs readFile case as an example, is the difficulty here to do with the interleaving of multiple statements that modify some state with non-strict functions that return results based on some particular instance of that state? Is this really a fundamental mismatch?
Yes, this is precisely the problem. Using hGetContents implicitly uses unsafeInterleaveIO, which basically only performs IO as demanded. When you then say 'hClose h', none of the input has been demanded, so nothing gets read. Ever. Someone (one of the Simons, perhaps) could comment on this, but it seems that the primary problem with using readFile is the open handles issue, which boils down to the definition of hGetContents:
hGetContents :: Handle -> IO String hGetContents handle = withHandle "hGetContents" handle $ \handle_ -> case haType handle_ of ClosedHandle -> ioe_closedHandle SemiClosedHandle -> ioe_closedHandle AppendHandle -> ioe_notReadable WriteHandle -> ioe_notReadable _ -> do xs <- lazyRead handle return (handle_{ haType=SemiClosedHandle}, xs )
If this were changed to actually close the handle, rather than leaving it in a semi closed state (call this new function hGetContentsAndClose or something) and then readFileAndClose were implemented based on this, would this solve the problem?
I read recently that other functional languages (ML?) with strict evaluation semantics can be used to mimic lazy evaluation, but saw no clue how that would work. I'm wondering if any insight might be gained by looking at how such mechanisms might interact with functional state-transformer mechanisms?
The basic idea is to do something like:
data Lazy a = Value a (Lazy a) Deferred (() -> Lazy a)
or something, and then you provide a function:
force (Value a l) = Value a l force (Deferred f) = force (f ())
You can then force values as you need them; presumably in strict evaluation semantics, 'f ()' would be evaluated only at the point that it's forced. This isn't really relevant, though, I don't think, since it's sort of the opposite of what we want to be doing... - Hal