On Thu, Feb 14, 2013 at 2:53 PM, Joachim Breitner <span dir="ltr"><<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>></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">> That's great. I'm curious I was under the impression that it was hard<br>
> to split out a pure subset as functions might call 'error' (e.g. due<br>
> to incomplete pattern matches) and that would pull in the whole I/O<br>
> 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 "raise# (SomeException (ErrorCall<br>
foo)". 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't think having FFI far down the stack is a problem. There are lots of pure data types we'd like in the "pure data" layer (e.g. bytestring) that uses FFI. As long as the I/O layer itself (System.IO, the I/O manager, etc) doesn't get pulled in there's no real problem in depending on the FFI. </div>
</div>