An existing widely-used typeclass such as `Num` cannot at present be compatibly refined to abstract a subset of its methods into more general superclasses:: class => AdditiveSemigroup a where (+) :: a -> a -> a class AdditiveSemigroup a => AdditiveMonoid a additiveIdentity :: a class AdditiveMonoid a => AdditiveGroup a negate :: a -> a (-) :: a -> a -> a class AdditiveMonoid a => CommutativeRing a where (*) :: a -> a -> a class CommutativeRing a => Num a where abs :: a -> a signum :: a -> a -- Possibly yet another class for this method. fromInteger :: Integer -> a because then all existing definitions of `Num` instances become invalid by specifying methods that no longer belong to `Num`, and failing to speicify the requisite superclass instances. As a result we can't have a satisfactory definition of addition for `Complex Integer`, because the `Num` instance has no sensible `abs` method (the square of the absolute value though integral, fails to satisfy the trianle inequality and is not compatible with abs on the corresponding complex floats). But I'm wondering whether this barrier could be overcome by allowing a single instance definitions to **implicitly** also define any requisite superclass instances by including definitions of the appropriate methods? Thus tbe below: instance Num ... where (+) :: ... additiveIdentity :: ... negate :: ... (-) :: ... (*) : ... abs :: ... signum :: ... fromInteger :: ... would be legal, and would produce implicit instances of the associated superclasses. One might then be able to define more complex `Complex` integral types: instance CommutativeRing Complex Integer where additiveIdentity = 0 :+ 0 (a :+ b) + (c :+ d) = (a + c) :+ (b + d) negate (a :+ b) = (negate a :+ negate b) (a :+ b) - (c :+ d) = (a - c) :+ (b - d) (a :+ b) * (c :+ d) = (a*c - b*d) :+ (a*d + b*c) which is not a `Num`, but is still a commutative ring. -- Viktor. 🇺🇦 Слава Україні!