What to do about divMod'.

[Christopher Lane Hinson]

Data.Fixed contains divMod' :: (Real a, Integral b) => a -> a -> (b, a)
as well as div' and mod'.

There are two problems:

1) Implementation of this type signature requires conversion to Rational, 
which is extremely slow.  It really isn't usable in any kind of 
significant loop at all.

2) This has nothing specific to do with fixed precision arithmetic 
despite being in the Data.Fixed module.

I played with writing a patch but I think this requires discussion.  I 
believe the original author was aware of the problems and didn't consider 
them urgent.

Should there be a RULES to address the performance issues?  Should this be 
based on RealFrac or specific to Float, Double, etc?  Alternately OR 
additionally should there be a separate set of functions created based on 
RealFrac?

Another possibility is to change the signature of the divMod' family 
itself to use RealFrac instead of Real.  This might break at compile time, 
but Rational is still an instance of RealFrac, so the fix would easy, and 
the performance penalty of calling to/fromRational would be visible in the 
calling code instead of hidden away.

If we use RULES, this may make programs that depend on it effectively 
unusable without the optimizer.  Whatever we do will probably change the 
semantics a bit in terms of infinite/NaN, but I don't think that is likely 
to matter.

I personally prefer changing the signature of the divMod' family, but I 
anticipate objections.

I also think that we should make sure that the divMod' family gets inlined 
as my understanding is this will avoid dictionary lookups and aid 
the strictness analyzer, but I'm not 100% certain on this point.

Does a module (Data.Num?) need to be created to keep these?

Thanks,
--Lane