You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
...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