Clean up numeric hierarchy

[hdgarrood]

After #128, we now have a couple of small problems:

• Field is exactly CommutativeRing and DivisionRing; forcing people to declare an extra Field instance doesn't really add anything.
• Field should have DivisionRing as a subclass, since every Field is a DivisionRing.

As far as I can tell, there are two options for addressing this:

Option 1: Change Field as follows:

class (DivisionRing a, CommutativeRing a) <= Field a
instance field :: (DivisionRing a, CommutativeRing a) => Field a

So that no additional Field instances should be declared anywhere, and instead the single Field instance allows people to use a Field constraint wherever a type has both DivisionRing and CommutativeRing instances. If we did this, it would only be a breaking change for people who had declared Field instances for types in their own code; functions with Field constraints should continue to work as before.

Option 2: Wait for constraint kinds and define Field in terms of a class class Both (a :: Constraint) (b :: Constraint) (is that accurate?)

[paf31]

There is also Option 3 - remove Field and just use the combination (DivisionRing a, CommutativeRing a) everywhere.

This is a just like the old Arrow = Strong + Category issue again 😄

[hdgarrood]

That's true, that is also an option. Would you prefer that over the others?

[paf31]

My issue with the other options is that we have a new class with no new laws and no new operations. As you say, Field is exactly CommutativeRing plus DivisionRing, but a new class implies there is something else which isn't true.

Option 3 will lead to slightly more cumbersome type signatures in a few cases though, so I'm not sure what's better.

[hdgarrood]

Ah, I was imagining that Field would just be a type synonym with option 2?

[paf31]

Yes I think so, but even then, Both has the same problem. I think we'd want it anyway though, so option 2 might be the best one.

[hdgarrood]

How do people feel about changing Field together with the next round of breaking changes so that it has a DivisionRing constraint as well as a CommutativeRing constraint? This would address the second of the issues I originally listed, but not the first.

[garyb]

Fine by me!