On Fri, Feb 27, 2009 at 8:50 PM, Michael Easter <span dir="ltr"><<a href="mailto:codetojoy@gmail.com">codetojoy@gmail.com</a>></span> wrote:<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;">
<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></blockquote><div><br>Right, the IO primitives are not functions. <br></div><div> </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>It might be helpful to distinguish between internal side effects (e.g. updating a global var in an imperative language) and external (IO). Haskell uses monads to simulate the former and to serialize the latter. <br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><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 "in the IO monad" there is a large subsystem of (inaccessible) state, machinery, etc.<br>
Is it really a token?<br></blockquote><div><br>Bear in mind that's the GHC implementation. I'm told another implementation uses some kind of continuation monad. The only requirement as I understand it is that the IO monad, however it is designed, must impose an order of evaluation on the IO primitives. GHC does hide the implementation details. <br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><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 '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>Hmm, to me there's something fishy about thinking in terms of two spaces. IO expressions are normal Haskell expressions; they just happen to get sequenced because they get chained together by monad ops. I.e. as far has Haskell semantics is concerned they're not special; Haskell needn't know they're impure. The impure part is external the Haskell semantics. Then remember lazy evaluation; the whole program can be optimized at compile time to some extent, and at run time evaluation is forced by the ordering of the "IO chain" that leads to main.<br>
<br>Be careful about thinking of the program as "starting at main" and then proceeding through the IO chain. That's perilously close to imperative thinking. It's more accurate (IMO) to say that the program gets evaluated at run time, which means main gets evaluated, and since the value of main depends on the series of IO actions chained to it, they get forced in order. So main isn't really the "first thing that happens"; it's the ONLY thing that happens, since the meaning of the program (i.e. main) is equivalent to the evaluation of the IO chain. Actual IO is a side effect of evaluating main.<br>
<br>Hope it helps,<br><br>gregg<br></div></div><br>