On Thu, Feb 14, 2013 at 2:53 PM, Joachim Breitner <mail@joachim-breitner.de> wrote:
Hi,

Am Donnerstag, den 14.02.2013, 13:19 -0800 schrieb Johan Tibell:
> That's great. I'm curious  I was under the impression that it was hard
> to split out a pure subset as functions might call 'error' (e.g. due
> to incomplete pattern matches) and that would pull in the whole I/O
> subsystem. How did you avoid that?

as mentioned before: By crippling GHC.Fingerprint. error foo just calls
raise (ErrorCall foo), which calls "raise# (SomeException (ErrorCall
foo)". The problem is that the definition of SomeException pulls in the
Exception type class, which pulls in Typeable, which pulls in
GHC.Fingerprint, which uses FFI and IO code to to fingerprinting...

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.