Simon Marlow wrote:

The real problem is that lazy I/O injects side effects into the pure
world of expressions. Haskell has a perfectly good system for
encapsulating side effects - the IO monad. So why put these sneaky side
effects into pure values?


Although monadic IO is nice in many ways, I think of its introduction in Haskell as a stopgap measure that solved the immediate problem of interfacing Haskell to traditional operating system's imperative APIs, but at the same time seems to have put a stop to further research into the proper integration of laziness and IO.

Laziness makes computation demand-driven and allows us to abstract away the order of evaluation. We think this is useful (most of the time) and that's why Haskell is a lazy language.

Demand-driven IO is useful too: sometimes, but not always, it is useful to abstract away from the exact details of when IO happens.

For example, laziness should allow the following Haskell program to run in constant space, although it makes use of a large intermediate structure:

main = let mylist = [1..10000]
              result = sum mylist
          in print result

Now suppose that for some reason that instead of processing the large intermediate structure directly, I need to store it in a file and process it later, with a program like this:

main =
 do let mylist = [1..10000]
    writeFile "myfile.txt" (unlines (map show mylist))
--   ...
    mylist' <- (map read . lines) `fmap` readFile "myfile.txt"
    let result = sum mylist'
    print result

With lazy IO, this program too should run in constant space, and the functions that consume the large intermediate structure can remain unchanged!

So, I think a lazy programming language should support not only lazy evaluation, but also lazy IO! When it is appropriate to abstract away from the details of when IO happens, lazy IO is useful. It can facilitate separation of concerns and modularity, just like lazy evaluation. Appropriate lazy IO should not compromise the purity of the language or be an obstacle to optimistic evaluation. Instead of settling for the monadic stopgap IO, we should continue to look for good ways to integrate laziness and IO!

--
Thomas H

"Delay is preferable to error."
 - Thomas Jefferson (3rd President of the United States)


_______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to