At some point I'd actually like to explore trying to build a satisfactory "integer-fancy" in Haskell, but there's a few technical challenges I'll be trying to do first before there'll be an engineering story for building a satisfactory Haskell replacement  that is performant enough to justify dropping Gmp<div>
<br></div><div>Basically I think until we can build an alternative with competitive performance in straight ghc Haskell, there's no good argument for dropping Gmp overall.  There are a number of great reasons that everyone has mentioned, but it needs to be a net win for everyone before the leap could be justifiable. </div>
<div><br></div><div> If I manage to get my target work for 7.10 sorted out with a few months to spare, I may try to spend a few months exploring this, though no promises.  Current  ghc doesn't have the right primops to do this yet. <span></span><br>
<br>On Tuesday, October 22, 2013, Edward Kmett  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Not suggesting we actually switch, but there is one strong 'why': You can't link Haskell code with any library that uses GMP internally internally without switching to using integer-simple. I've been trying with very limited success to get good MPFR bindings for Haskell for ~3 years now as a result.<div>

<br></div><div>The most likely fix actually involves changes to MPFR as their constant cache and our garbage collector don't play nice.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Oct 22, 2013 at 7:36 PM, Edward Z. Yang <span dir="ltr"><<a href="javascript:_e({}, 'cvml', 'ezyang@mit.edu');" target="_blank">ezyang@mit.edu</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey Gergeley,<br>
<div><br>
> (obviously we would have to call mpz_free here and there, but that<br>
> seems doable).<br>
<br>
</div>Actually, this is precisely the problem.  When is a GMP integer freed?<br>
It can have pointers to it from objects on the heap, so this free should<br>
only occur when the integer is dead, with no references from the heap.<br>
How can that be arranged?  Well, the garbage collector is responsible<br>
for figuring this out.  So why shouldn't they just live on the heap, and<br>
then smoothly integrate with the existing garbage collector.<br>
<br>
The alternate strategy is to arrange that some sort of "callback" gets<br>
invoked when an object dies.  You can achieve this using our finalizer<br>
support, but you pay an efficiency penalty and cannot guarantee that<br>
the integers will get freed in a timely manner at all.<br>
<div><br>
> More concretely: openssl BN uses the openssl_malloc function can only be<br>
> overridden openssl wide.  But if we link statically, than this override<br>
> won't affect external openssl library bindings, because the openssl<br>
> symbols in our object files won't even be exported, right?<br>
<br>
</div>Only if literally two copies of OpenSSL are linked.  This seems unlikely to<br>
work the way you want it to.<br>
<br>
Cheers,<br>
Edward<br>
<div><div>_______________________________________________<br>
ghc-devs mailing list<br>
<a href="javascript:_e({}, 'cvml', 'ghc-devs@haskell.org');" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
</div></div></blockquote></div><br></div>
</blockquote></div>