Dear GHC gurus, I've been looking into how GHC uses GMP (with the hidden agenda of taking the work of replacing it with something that is BSD license compatible and so can be linked in and shipped statically by default). I think I more or less understand how GMP memory is managed and how the GC works together with it. Actually understanding the "how" was not that hard, everything is quite clearly commented. What I couldn't find any reference for is the "why". Why does GHC do this? Would it be possible to just not do this and let GMP malloc and free for itself (obviously we would have to call mpz_free here and there, but that seems doable). I have multiple ideas, but don't know which one (if any) is correct: - performance reasons, - memory defragmentation reasons, - GHC GC moves around stuff and that would somehow break, - the previous one + threads + race conditions. Second question: let's assume for a moment that we don't have any licensing issues with a GMP like library, can be linked statically into GHC, but we decide to go with the same allocation methodology as with GMP. Am I right when I think that linking statically solves the technical issues too. More concretely: openssl BN uses the openssl_malloc function can only be overridden openssl wide. But if we link statically, than this override won't affect external openssl library bindings, because the openssl symbols in our object files won't even be exported, right? Third question: is replacing with openssl bn an acceptable path to you guys? I saw that 6 years ago there were work on getting integer-simple performance wise good enough to be the default and then adding other bignum libraries externally, but none of this happened. I see how sexy project it is computer science wise to write a bignum library in Haskell, but will we really do it? Thanks, Gergely (errge)