On Thu, Feb 14, 2013 at 2:53 PM, Joachim Breitner
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.