On Thu, Feb 14, 2013 at 2:53 PM, Joachim Breitner <span dir="ltr">&lt;<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Hi,<br>
<br>
Am Donnerstag, den 14.02.2013, 13:19 -0800 schrieb Johan Tibell:<br>
<div class="im">&gt; That&#39;s great. I&#39;m curious  I was under the impression that it was hard<br>
&gt; to split out a pure subset as functions might call &#39;error&#39; (e.g. due<br>
&gt; to incomplete pattern matches) and that would pull in the whole I/O<br>
&gt; subsystem. How did you avoid that?<br>
<br>
</div>as mentioned before: By crippling GHC.Fingerprint. error foo just calls<br>
raise (ErrorCall foo), which calls &quot;raise# (SomeException (ErrorCall<br>
foo)&quot;. The problem is that the definition of SomeException pulls in the<br>
Exception type class, which pulls in Typeable, which pulls in<br>
GHC.Fingerprint, which uses FFI and IO code to to fingerprinting...</blockquote><div><br></div><div>I don&#39;t think having FFI far down the stack is a problem. There are lots of pure data types we&#39;d like in the &quot;pure data&quot; layer (e.g. bytestring) that uses FFI. As long as the I/O layer itself (System.IO, the I/O manager, etc) doesn&#39;t get pulled in there&#39;s no real problem in depending on the FFI. </div>

</div>