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.<br><br>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.<br>
<br>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.<br>
<br>Ok, so let's address your questions a little more specifically.<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Q1: The web page mentions that normal Haskell functions cannot cause side-effects, yet later talks about<br>
side-effects with putStrLn. I assume the key point here that IO actions are, by definition, _not_ normal functions?<br></blockquote><div><br>Right, IO actions can have side effects because they can take into account, and modify, the RealWorld.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Q2: Is it true to say that <i>any</i> monadic action <i>could </i>cause side-effects, depending on the design of that <br>
monad? i.e. Does one generalize from the IO monad to (possibly) an arbitrary monad? *Musing* This must be true as <br>using State must surely be considered a side-effect.<br></blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Q3: The web page mentions IO as being a baton, or token, that is used to thread/order the actions. Is true<br>
that this is merely one simple perspective, with respect to order of evaluation? This is hard to articulate, <br>but it seems to me that "in the IO monad" there is a large subsystem of (inaccessible) state, machinery, etc.<br>
Is it really a token?<br></blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Q4: Is the following idea accurate: a Haskell program is partitioned into 2 spaces. One is a sequence <br>
of IO actions; the other is a space of pure functions and 'normal' Haskell operations. The execution of a <br>
program begins with the main :: IO () action and, effectively, crosses from one space to the other. In the<br>pure space, the math-like functions can be highly optimized but only insofar as they do not disrupt the <br>implied order of the IO actions. Because of the type system, the program recognizes when it enters<br>
"back" into the IO space and follows different, less optimized rules.<br></blockquote><div><br>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..<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">My concern is that the above is <i>not</i> accurate, but I don't know why.<br>
<br><br>thanks so much for your help<br>Michael Easter<br clear="all"><font color="#888888">
<br>-- <br>----------------------<br>Michael Easter<br><a href="http://codetojoy.blogspot.com" target="_blank">http://codetojoy.blogspot.com</a>: Putting the thrill back in blog<br><br><a href="http://youtube.com/ocitv" target="_blank">http://youtube.com/ocitv</a> -> Fun people doing serious software engineering<br>
</font><br>_______________________________________________<br>
Beginners mailing list<br>
<a href="mailto:Beginners@haskell.org">Beginners@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/beginners" target="_blank">http://www.haskell.org/mailman/listinfo/beginners</a><br>
<br></blockquote></div><br>