[Haskell-cafe] Factoring into type classes

[Eugene Kirpichov]

As for multiple Monoid or Functor instances, simply define a newtype,
as it is done in Data.Monoid.
What part of your question does that answer and what part doesn't it?

2009/1/19 Patai Gergely <patai_gergely at fastmail.fm>:
> 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
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>