[Haskell-beginners] clarification on IO
wagner.andrew at gmail.com
Fri Feb 27 22:30:39 EST 2009
I'll take a shot at answering some of your questions by explaining how I
understand it, and we'll see if it helps or makes it worse.
Let's talk about monads first. Monads can be thought of as a way of sort of
hiding "side effects". That is, there is nothing inherently impure about
monads. The "side effects" happen in the bind function, essentiall. For
example, in the case of state, the state is carried from one function to
another. The bind function actually says how to do this; You just don't
usually see it because it's "hidden" in the do notation. In the Maybe
function, the plumbing hides the fact that we quit at any point the
computation fails, and so on. So while in an impure language, any statement
can have any side effect, in haskell, if you know what monad you're in, you
know exactly what the "side effect" will occur - which means, it's not
really a side effect at all, but part of the actual intended effect.
Now for IO. You can think of IO as being essentially State RealWorld. That
is, every operation is dependent on the entire state of the world, including
what you're thinking, and what kind of bug is crawling on the 18th blade of
grass in your yard. If we could actually represent the whole world this way,
Haskell would truly be a completely pure language. The only reason IO, and
thus Haskell, is impure at all, is because we can't literally represent the
whole world. EVERYTHING ELSE, INCLUDING EVERY OTHER TYPE OF MONADIC ACTION
IN HASKELL, is completely pure.
Ok, so let's address your questions a little more specifically.
Q1: The web page mentions that normal Haskell functions cannot cause
> side-effects, yet later talks about
> side-effects with putStrLn. I assume the key point here that IO actions
> are, by definition, _not_ normal functions?
Right, IO actions can have side effects because they can take into account,
and modify, the RealWorld.
> Q2: Is it true to say that *any* monadic action *could *cause
> side-effects, depending on the design of that
> monad? i.e. Does one generalize from the IO monad to (possibly) an
> arbitrary monad? *Musing* This must be true as
> using State must surely be considered a side-effect.
Again, yes, this is accurate, but it's different from most impure languages
in that the side effect is completely baked in by the monad you're in, so
that you can't really say that the effect is a "side effect" at all.
> Q3: The web page mentions IO as being a baton, or token, that is used to
> thread/order the actions. Is true
> that this is merely one simple perspective, with respect to order of
> evaluation? This is hard to articulate,
> but it seems to me that "in the IO monad" there is a large subsystem of
> (inaccessible) state, machinery, etc.
> Is it really a token?
Again, in many ways, it's easier to think of the IO monad as a state monad.
In that sense, the state of the world is indeed being passed from one action
to the next, as defined by bind. That's the inaccessible state machinery I
suspect you're sensing.
> Q4: Is the following idea accurate: a Haskell program is partitioned into 2
> spaces. One is a sequence
> of IO actions; the other is a space of pure functions and 'normal' Haskell
> operations. The execution of a
> program begins with the main :: IO () action and, effectively, crosses from
> one space to the other. In the
> pure space, the math-like functions can be highly optimized but only
> insofar as they do not disrupt the
> implied order of the IO actions. Because of the type system, the program
> recognizes when it enters
> "back" into the IO space and follows different, less optimized rules.
I think it would be easier to talk about haskell in terms of pure and impure
code. All Haskell code is pure except for IO. Pure functions are easier to
reason about and to optimize, because you don't have to take into account
the RealWorld state, or other possible, REAL side effects..
> My concern is that the above is *not* accurate, but I don't know why.
> thanks so much for your help
> Michael Easter
> Michael Easter
> http://codetojoy.blogspot.com: Putting the thrill back in blog
> http://youtube.com/ocitv -> Fun people doing serious software engineering
> Beginners mailing list
> Beginners at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Beginners