[Side-effects John Goerzen **20070711050111] { hunk ./en/ch06-io.xml 1025 - FIXME: does anyone have a better explanation here? + FIXME: I don't really like this explanation hunk ./en/ch06-io.xml 1037 + + + Side-Effects with Lazy I/O + + Earlier in this chapter, you read about &hGetContents;. + We explained that the &String; it returns can be used in pure code. + + + We need to get a bit more specific about what side-effects are. When + we say Haskell has no side-effects, what exactly does that mean? + + + At a certain level, side-effects are always possible. A poorly-written + loop, even if written in pure code, could cause the system's RAM to be + exhausted and the machine to crash. Or it could cause data to be + swapped to disk. + + + When we speak of no side-effects, we mean that pure code in Haskell + can't run commands that trigger side-effects. Pure functions + can't modify a global variable, request I/O, or run a command to take + down a system. + + + When you have a &String; from &hGetContents; that is passed to a pure + function, the function has no idea that this &String; is backed by a + disk file. It will behave just as it always would, but processing that + &String; may cause the environment to issue I/O commands. The pure + function isn't issuing them; they are happening as a result of the + processing the pure function is doing, just as with the example of + swapping RAM to disk. + + + In some cases, you may need more control over exactly when your I/O + occurs. Perhaps you are reading data interactively from the user, or + via a pipe from another program, and need to communicate directly with + the user. In those cases, &hGetContents; will probably not be + appropriate. + + I'm not sure I really like this explanation + }