On Wed, 23 Oct 2013 11:49:00 -0500, Austin Seipp <[email protected]> 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 _______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
