Update Field

[garyb]

Resolves #132

[hdgarrood]

Every field is a euclidean ring, so I think it might be best to keep the EuclideanRing constraint. In fact with what's in this PR, you wouldn't be able to write a function which uses / and which only has a Field constraint, right?

How about this instead:

class (EuclideanRing a, DivisionRing a) <= Field a
instance (EuclideanRing a, DivisionRing a) => Field a

[hdgarrood]

Also this relates to #132, not #128, right?

[garyb]

I did wonder about that, in the other PR I had it with the EuclideanRing constraint but then looking at it again today I thought that might have been a mistake 😄

[hdgarrood]

Also I think it might be worth mentioning that every type with law-abiding DivisionRing and CommutativeRing instances only really has one sensible law-abiding EuclideanRing implementation, where div a b = a * recip b, mod _ _ = zero, and degree _ = 1; see https://a-guide-to-the-purescript-numeric-hierarchy.readthedocs.io/en/latest/euclidean-rings.html, where it says "start from "Let F be a field, and suppose f:F∖{0}→N is a euclidean function". degree must be constant; any return value will work, so you might as well choose 1.

[hdgarrood]

Sorry, I didn't notice you had updated this, but there's a couple of things I think are not quite right here (in the docs). Do you mind if I send another PR?

[hdgarrood]

Oh actually, EuclideanRing implies CommutativeRing, so adding the CommutativeRing superclass won't do anything. With this commit, we have a Field Int instance, which is definitely wrong. It should have EuclideanRing and DivisionRing superclasses. I'll send a PR in a moment.

[garyb]

Oops, glad someone is paying attention 😉