Am 26.03.2014 16:10, schrieb Casey McCann:
This situation really should not be a warning. It's an Integral constraint on a type in contravariant position, which by itself can only be ambiguous if it's given something built from numeric literals and basic arithmetic. Having an Integral instance means a type supports conversions to and from Integer, and I would be very dubious about a type where (fromInteger . toInteger) was not equivalent to id. I really can't see how defaulting an Integral constraint alone to Integer is anything other than safe and sensible.
In NumericPrelude I decided to fix the exponent type to Integer. 1. This solves the defaulting problem. 2. Most of the time in my code the exponent is constant and is 2. 3. It broke a dependency cycle between the numeric classes.