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_gerg...@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@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
