On 06/11/16 00:06, David Menendez wrote:
Some people claim that you shouldn’t define a class unless you can describe some sort of algebraic laws for it, but I think that’s too strong. For one thing, it would mean we lose equality and numeric operations for Float, which is one of the things classes were invented for in the first place.
I've heard that too and agree with your objection. I think what underlies that critic, is that introduccion type classes without laws makes it harder to see the "intuition" of what such class ought to do (this in the context of reading, not writing). I specifically remember being a beginners and see class RegexOptions regex compOpt execOpt not understanding what really meant and why had to sprinkle it through my code. A good case of what you say is Data.Vector.Generic.Vector, (which argueably make more sense as a backpack-module) that makes the type class usage intuition clear. So in resume, what we want is "easy to understand usage" typeclasses more than laws. To that I think putting emphasis on the important instances goes great length in helping.
Instead, define a class if (1) you have a set of operations that can be applied at multiple types but aren’t polymorphic, (2) you can give a formal or informal description of the operations which are enough to reasonably distinguish a good instance from a bad one, and (3) using a class makes your code easier to understand.
(2) hits the nail, specially when reading others code! -- -- Ruben