Thanks for the clarification.<br><br>&gt;AFAIK, the only way to get input and produce output is via the IO monad<br><br>Now you know something different, don&#39;t you?&nbsp; FRP, Pan, TV.&nbsp; Also Grapefruit, functional forms, and others I&#39;m not thinking of or don&#39;t know about.
<br><br>As for your example, mixing the IO with the functional, as you have interferes with composing the result.&nbsp; I can think of two alternatives.&nbsp; One is to move reading &amp; printing from the definition to the uses, as with Unix stream filters.&nbsp; Still convenient, and much more flexible.&nbsp; Of course, Unix programs were written in C and so use explicit I/O instead of lazy functional streams.&nbsp; (Though Doug McIlroy, who invented Unix pipes, knew that pipes were equivalent to coroutines and to lazy evaluation.&nbsp; See my &quot;modern marriage&quot; talk (the video I mentioned) for more about Unix and TV.)
<br><br>A second alternative is to use TV to explicitly capture the interface (I/O), which could look like this:<br><br>&nbsp;&nbsp;&nbsp; coolTV :: TV (String -&gt; String)<br>&nbsp;&nbsp;&nbsp; coolTV = tv (olambda (fileIn &quot;Data.txt&quot;) defaultOut)
<br>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; performAwfullyCoolFunctionalStuff<br><br>where<br><br>&nbsp;&nbsp;&nbsp; tv :: Output src snk a -&gt; a -&gt; TV src snk a<br><br>The type parameters src &amp; snk are for various interface styles.&nbsp; Then coolTV can then be used on *either* side of a TV-style pipe, resulting in the removal of the reading or writing half.
<br><br>And yes, there are *some* uses of IO for which I&#39;d be hard pressed at this point to offer you an alternative.&nbsp; Which is a far cry from IO being necessary for all &quot;real&quot; programs, even today.<br><br>Given this state of affairs, I&#39;d prefer the Haskell community to point newbies away from IO and toward purely functional programming for things like UIs and graphics and help them change their way of thinking.&nbsp; Let&#39;s also admit that we haven&#39;t yet figured out how to apply our functional paradigm as flexibly or broadly as we&#39;d like, and so meanwhile we have thi monadic IO trick that let&#39;s them write nicely factored imperative code that can call into the functional pieces.
<br><br>Regards,&nbsp; - Conal<br><br><div class="gmail_quote">On Dec 9, 2007 12:54 PM, Daniel Fischer &lt;<a href="mailto:daniel.is.fischer@web.de">daniel.is.fischer@web.de</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Am Sonntag, 9. Dezember 2007 21:29 schrieb Conal Elliott:<br><div class="Ih2E3d">&gt; I think your real point is that some things we still haven&#39;t figured out<br>&gt; how to express functionally. &nbsp;Right?<br><br></div>
That&#39;s my point, at least. Currently, AFAIK, the only way to get input and<br>produce output is via the IO monad, so it is de facto necessary for all<br>&#39;real&#39; programmes, it need not remain so (though I cannot imagine how to
<br>functionally express<br>&#39;readFile &quot;Data.txt&quot; &gt;&gt;= print . performAwfullyCoolFunctionalStuff&#39; - surprise<br>me :).<br>Read &quot;IO is important&quot; as a description of current affairs, not as a claim of
<br>the inherent grandeur of it.<br><br>Cheers,<br><font color="#888888">Daniel<br></font><div><div></div><div class="Wj3C7c"><br>&gt; &nbsp;I would certainly agree with that<br>&gt; part. Perhaps you exaggerating when you wrote &quot;IO is important because you
<br>&gt; can&#39;t write any real program without using it.&quot;<br>&gt;<br>&gt; Cheers, - Conal<br>&gt;<br><br></div></div></blockquote></div><br>