[Haskell-cafe] Factoring into type classes

[Patai Gergely]

Hi everyone,

I have a general program design question, but I can't really think of
good examples so it will be a bit vague. There was a discussion on Show
not long ago which brought up the problem that there are several ways to
"show" a data structure, and it depends on the context (or should I call
it a use case?) which of these we actually want, e.g. human readable
form, debug information, serialisation for later reading and so on, and
one of the solutions was to propose a family of show functions that
carry the intended use in their name.

However, there are other type classes that are too general to assign
such concrete uses to. For instance, if a data structure can have more
than one meaningful (and useful) Functor or Monoid instance, what should
one do? Should one refrain from instantiating these classes altogether
and just use the names of operations directly? If one still decides to
pick a certain set of operations as an instance, what are the factors
that should guide this decision? What about designing libraries, how
much should one prefer standard classes for their interfaces?

It seems to me that there is practically no literature on design issues
like these, and it would be nice to hear some opinions from experienced
Haskellers.

Gergely

-- 
http://www.fastmail.fm - The way an email service should be