[commit: packages/integer-gmp] master: Clean-up Cmm of import/export primitives (dfd65a2)

[Herbert Valerio Riedel]

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

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