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
[email protected]
http://www.haskell.org/mailman/listinfo/haskell
_______________________________________________
Haskell mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell
