What to do about Dividable?

[stylewarning]

...continuation of this thread: #877 (comment)

I think I'm a fan of generalizing the operators a la Rust. I don't know if there's a point though if we discourage the use of generalizations by only making their specializations colloquial.

I don't agree about casting prior to operating. That can lead to less accurate answers. In short, if c is a type case and a and b are integers, then c(a/b) != c(a)/c(b). Common Lisp usually avoids this mess by making division always exact (by making int/int=frac) and allowing casting afterward.

I also think that the fact some popular languages have chosen to make int/int=float a default is a testament to that (1) as a frequent expectation from users and (2) it being more intuitive compared to any of the number of possible integer division possibilities (which are subtle and a bountiful source of bugs, especially when porting numerical code). A language refusing to acknowledge this common case is putting an unnecessary burden on the programmer.

I think the first serious use of Coalton is a testament to our approach (or similar): It defines some serious and general relationships between different abstract number types—something that should be celebrated about a type system as advanced as Coalton's or Haskell's. In particular, we have nice relationships for having types that look like $R(T) := \{a+b\sqrt{2} : a,b\in T\}$ and allowing division of $R(\mathbb{Z})$ to result in $R(\mathbb{Q})$ by a little conjugate multiplication. This isn't something that's convenient or even possible with standard operators in Common Lisp.

I don't know what the fate of Dividable will be, but I do think having the user choose explicit semantics of division, while making each choice easy to select, is something Coalton ought to push for.