On Wed, 23 Oct 2013 11:49:00 -0500, Austin Seipp
$ 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