trait EuclidianRing should not be a Ring about cats HOT 4 OPEN

cc @non

We implemented this stuff a very long time ago and may well have made a few mistakes in the encoding.

How should this have been encoded? It seems that extending GCDRing was a mistake in your view, but we don't have GCDRig do we? So I wonder if the hierarchy has greater issues in this regard.

What do you propose as our best course of action?

from cats.

I think the "right" (ideal) representation would extend a EuclidianRig from Rig. AFAICT Euclidian doesn't need negation in its sematics or laws, and there could be a valid instance for natural numbers without subtraction.

I like the way NumHask models algebra, although the names are different. NumHask's Integral ~ Cats EuclidianRing and it extends Distributive, which ~ Cats Rig.

Possibly the "right" (pragmatic) solution is to mark this issue as Won't fix and simply leave it as a signpost for the next generation of library writers. Its likely a breaking change and I'd guess very few people care.

I don't have strong knowledge or views on why GCDRing is separated from EuclidianRing. Is there any known trait that extends GCDRing but not EuclidianRing?

from cats.

I wouldn't be surprised if no one has ever used this code. The breakage cross section may be very low here.

That said, an abstraction that is never used it also tautologically not useful. I imagine that you can add a trait to your own code just as well if you intend to use it.

If we had confidence of the improvement adding a new trait costs very little.

from cats.

Well, I think a solution could be to

• new trait GCDRig extending Rig
• new trait EuclidianRig extending GCDRig.
• existing GCDRing would now extend Ring and GCDRig
• existing EuclidianRing would now extend GCDRing and EuclidianRig

Practically this would allow natural numbers to be supported since they can provide a EuclidianRig[Nat]

from cats.