<br>Folks,<br><br>I&#39;ve been reading RWH and this <a href="http://www.haskell.org/haskellwiki/IO_inside#Haskell_is_a_pure_language">http://www.haskell.org/haskellwiki/IO_inside#Haskell_is_a_pure_language</a><br><br>I think I understand monads. I think I understand how IO is much different from, e.g. Maybe, State, etc.<br>
<br>However there are some turns of phrase with respect to IO that have me baffled.  I am giving a presentation <br>on monads next week, and hope you can help. (I&#39;m not quite as lost as this might imply!)<br><br>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><br><br>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><br><br>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 &quot;in the IO monad&quot; there is a large subsystem of (inaccessible) state, machinery, etc.<br>
Is it really a token?<br><br>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 &#39;normal&#39; 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>
&quot;back&quot; into the IO space and follows different, less optimized rules.<br><br>My concern is that the above is <i>not</i> accurate, but I don&#39;t know why.<br><br><br>thanks so much for your help<br>Michael Easter<br clear="all">
<br>-- <br>----------------------<br>Michael Easter<br><a href="http://codetojoy.blogspot.com">http://codetojoy.blogspot.com</a>: Putting the thrill back in blog<br><br><a href="http://youtube.com/ocitv">http://youtube.com/ocitv</a> -&gt; Fun people doing serious software engineering<br>