What to do about Dividable? #902
stylewarning
started this conversation in
Other
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
...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 anda
andb
are integers, thenc(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.
Beta Was this translation helpful? Give feedback.
All reactions