Thanks for all the replies. Perhaps my mental picture is a little less flawed, now, but this brings up something about the IO monad that has always bothered me. Papers on the IO monad say things like "A term of type IO () denotes an action, but does not necessarily perform the action." (Wadler, "How to Declare an Imperative") Or, "putc '!' denotes the command that, if it is ever performed, will print an exclamation mark." Okay... However, when I use IO in a Haskell program, the response is usually pretty snappy. It's not as if the Haskell runtime is hanging around, waiting for some time in the future when it might be appropriate to do IO. It happens right now. Yet the literature gives the impression that the IO monad in particular is a clever trick to preserve referential transparency by gathering up all the IO actions, but not necessarily actually *performing* them. Then the Haskell runtime holds its nose and *performs* them when necessary. But at least a couple responses to my question have said that the IO action is performed when `<-` (or equivalently, bind, >>=) is executed. My head has a hard time holding a mental model of code in which IO might happen at some unspecified time in the future. A mental model in which IO happens when >>= is executed is a lot better fit for my head. Yet, I remain a bit nervous about this new (to me) mental model. Is this just an intuition that works 99.9% of the time, or is it actual, literal fact? -Rod On Oct 27, 2008, at 5:43 PM, Timothy Goddard wrote:
On Tue, 28 Oct 2008 12:02:54 Rodney D Price wrote:
My old, deeply flawed mental picture had "iio" taking the role of a pointer to a value. My bright, shiny new mental picture has "iio" acting just like a C #define macro: every time I call "iio", I'm really just writing "newIORef 0". Is that what you're saying?
-Rod
No, this isn't the behaviour of IORefs at all - you're getting mixed up with Haskell's syntax. <- in a do block means perform the contained action and let me use the result. = defines a term and is effectively just an alias - it doesn't run anything by itself.
iio :: IO (IORef Int) This means "iio is an IO operation which produces an IORef to an Int" iio = newIORef 0 This means "iio is creating a new counter starting at 0" ic1 = do { io <- iio ; count io 0 } This is an IO operation which runs iio, creating a new IORef in the process, and then starts a counter at 0 and returns it. ic2 = do { io <- iio ; count io 0 } This runs iio again, creating another IORef, and then starts a counter on the new IORef.
Haskell doesn't have mutable global variables - it goes against the grain of a pure language. You have to create the IORef within an IO procedure and pass it in. You really should write:
counter = do io <- newIORef 0 c1 <- count io 0 c2 <- count io 0 c1 'a' >>= print c2 'b' >>= print c2 'a' >>= print c1 'a' >>= print
This should behave as you expected - it creates the IORef then creates two counters sharing it.
Remember that when you return IO a, you're returning an IO operation that produces an a. That operation is not run until it is bound to the main IO monad. Haskell's IO looks like any other language if you're only writing and calling procedures normally but as soon as you start passing around references to IO procedures you need to understand a little more about how monads work.
In the real world using IO counters is probably something to avoid. Only the part of your program that is actually interacting with the outside world should use IO at all, and keeping an internal count doesn't need this. Minimise IO and Haskell will reward you. Let IO spread all through your program and it will be no safer than the C the developer was really thinking in.
Cheers,
Tim _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell