[Haskell-cafe] programming style...and type classes...

[Ruben Astudillo]

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