<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br>
&gt;&gt; 2b. You can define brand new flow control constructs *inside* the language<br>
&gt;&gt; itself. (E.g., in Java, a &quot;for&quot; loop is a built-in language construct. In<br>
&gt;&gt; Haskell, &quot;for&quot; is a function in Control.Monad. Just a plain ordinary<br>
&gt;&gt; function that anybody could write.)<br>
&gt;&gt;<br>
&gt;<br>
&gt; Psst, heard about Scheme &amp; call/cc?<br>
<br>
</div>But, very importantly, purity allows you to *restrict* the flow<br>
constructs that client code has available.  If you have continuations<br>
+ mutable state you can do anything, but the more code can *do*, the<br>
less you *know* about it.  For example, providing parser combinators<br>
as an applicative functor offers more power than a traditional parser<br>
generator, but not enough that we can no longer parse efficiently.<br></blockquote><div><br></div><div>Exactly my fear over unsafePerformIO in 3rd party Haskell libraries :-).</div><div><br></div><div>One can present an interface in Haskell that looks safe, but it can be very unsafe in its implementation.</div>
<div><br></div><div>Dave</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
Luke<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br>