What to do about divMod'.

[Don Stewart]

lane:
> 
> 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?

Almost certainly. Things like fromIntegral and truncate already have
extensive type-based rules.

> 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.

Well, we make them the same as they currently are.

> 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.

Check the core!

-- Donn