Add lawless instances

[mijicd]

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.

[adamgfraser]

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 A => A, but we can't test it because it is not possible to define equality for functions. Perhaps we could use some notion of "equality to the extent of testability" here. For example, two functions are equal as far as we can tell if they return identical outputs for a random sample of inputs.

[mijicd]

I think we need some form of "special" treatment here. For lawless instances perhaps pull them out into separate package? 😕

[jdegoes]

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 foldMap on a foldable of doubles, and get back a sum, even if the answer is different depending on whether the implementation folds from the left or from the right (and it shouldn't be, according to laws).

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.

[adamgfraser]

I like it.