-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add lawless instances #40
Comments
I'm a little worried about this. While being able to aggregate with double or float values is certainly useful they don't satisfy the laws and defining instances for them is going to result in derived instances involves them that also aren't lawful in ways that may be less obvious. I agree it would be nice to do something here and I'm not sure what the solution is but this seems like it could be another area where we could potentially do something different than other libraries have done here. Another related thing that is I think less controversial is instances that are lawful but aren't testable. For example, function composition is closed for functions |
I think we need some form of "special" treatment here. For lawless instances perhaps pull them out into separate package? 😕 |
If you look at Scalaz and Cats, both excluded the instances, and pushed them into another package (outlaws / alleycats). This made it (a) still possible to access for the determined user, albeit as orphan instances, and (b) more painful for common case when violations of laws affect correctness only in "small" ways (e.g. associativity of float / double addition / multiplication—which affects accuracy of the result, but so do all calculations involving floats / doubles). My feeling is that this design choice (to force illegal instances to be orphans in a third-party library) is thoroughly explored in other FP libraries. There is a lot of convenience in being able to, e.g. call Will this break some generic code in mild ways? Yes, but only for people using floats / doubles generically. And if you're doing that, there's probably a reason (e.g. performance, since these types are way faster than rational types), and you are probably willing to pay the consequences. |
I like it. |
During my work on #24, I removed Identity instances for double and float. The reason I did this is because both of them violate identity laws. However, having in mind how useful these 2 types are, it makes sense to provide instances for them, but don't include them in law checking and document the reason for that.
The text was updated successfully, but these errors were encountered: