On Thu, Feb 14, 2013 at 2:53 PM, Joachim Breitner <[email protected]>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.
_______________________________________________ Glasgow-haskell-users mailing list [email protected] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
