[commit: packages/integer-gmp] master: Clean-up Cmm of import/export primitives (dfd65a2)
Gabor Greif
ggreif at gmail.com
Tue Nov 5 23:49:37 UTC 2013
On 11/5/13, Herbert Valerio Riedel <hvr at gnu.org> wrote:
> On 2013-11-05 at 22:08:11 +0100, Gabor Greif wrote:
>> I suppose the integer-simple library also needs the <new-primops>
>> treatment.
>> Many embedded platforms won't have GMP.
>> Should we just provide 'error "unimplemented"' stubs?
>
> Well, I extended the precedent set by
>
> http://www.haskell.org/ghc/docs/latest/html/libraries/integer-gmp-0.5.0.0/GHC-Integer-GMP-Internals.html
Oh, I see. I'll shut up now :-)
Gabor
>
> where the underlying `gcdInteger#` and `lcmInteger#` primitives are
> provided only by `integer-gmp`, and their wrappers are located in a
> module whose name clearly denotes these as being specific to GMP.
>
> This should be regarded as an optimization to tap into GMP's highly
> optimized primitives, which afaik can't be easily added outside of
> integer-gmp.
>
> However, in the long-term, I don't think packages should build-depend
> directly on integer-{gmp,simple} (I was surprised to see that `text`
> does this), but instead an `integer` "super-package" could abstract over
> the decision whether `integer-gmp` or `integer-simple` is used as
> Integer "backend" library, and pass-thru a common set of functions,
> while enforcing that no function is missing and/or has a diverging
> type.
>
> Cheers,
> hvr
>
More information about the ghc-devs
mailing list