Why do we put GMP allocations on GHC heaps?

[Gergely Risko]

On Wed, 23 Oct 2013 11:49:00 -0500, Austin Seipp <austin at well-typed.com> writes:

> $ ghc foo.hs
> $ ghc -integer-type=gmp foo.hs
> $ ghc -integer-type=openssl foo.hs
> $ ghc -integer-type=simple foo.hs

Well, I didn't think of this.  This would indeed be very cool,
unfortunately it's quite hard if I understood you correctly.

> As an example, libtomcrypt is damn fast, BSD3 licensed, very small,
> and well-respected. Why don't we:
>
> 1) Take libtomcrypt, modify the symbol names to be private to GHC
> (e.g. prefix everything with `ghc_integer_`) - this means the symbol
> names will be internal to GHC, so this also doesn't affect relinks
> against other copies of libtomcrypt (many projects include their own
> copy.) It is so small it basically comes under our control completely.
>
> 2) We can then offer people a integer-tomcrypt which does not have
> compatibility issues, and does not cause as much pain as the
> integration of widely deployed libraries like GMP/OpenSSL, which are
> in various use by many Haskell packages already.
>
> This should give us the flexibility of integer-simple without
> compromising so much on the efficiency aspect.
>
> This is also a very half-baked idea, but just a suggestion. I'd love a
> more modular solution to Integer as well, as I know many other people
> would.

Just to be sure I understand the idea: do you mean linking this
ghc_integer_ prefix libtommath statically into ghc and every resulting
haskell binary, right?  It makes no sense to link dynamically if the
user can't replace it with a standard libtommath anyways because of the
prefix.

And do you mean shipping this libtommath GHC by default (instead of
integer-simple) and starting to develop an integer-gmp or package on
hackage?

Gergely