On Tue, Dec 14, 2010 at 10:02:42AM +0100, Krasimir Angelov wrote:
Of course it is possible to change the affected code and to add the necessary instances. The point is that if I am going to use only the functionality of Monad and I don't care of Functor and Applicative then I don't define them at all. I add them only later if I need them.
For consistency: If you are going to use only the functionality of Ord and don't care about Eq, you don't want to define Eq at all? (Such cases are realistic, for example for using Data.Map and Data.Set.) I have some tools that allow you to just define the methods with their standard names, but outside any instance (which in many cases is good practice anyways), and then let the tool throw them together into instances for the class hierarchy du jour: http://www.cas.mcmaster.ca/~kahl/Haskell/ModuleTools/ Wolfram ------------------------------------------------------------ @InProceedings{Kahl-2009_TFP, author = {Wolfram Kahl}, title = {Haskell Module Tools for Liberating Type Class Design}, crossref = {TFP2009}, pages = {129--144}, chapter = {9}, abstract = {Design of Haskell type class hierarchies for complex purposes, including for standard containers, is a non-trivial exercise, and evolution of such designs is additionally hampered by the large overhead of connecting to existing implementations. We systematically discuss this overhead, and propose a tool solution, implemented using the GHC API, to automate its generation.} } @Book{TFP2009, title = {Trends in Functional Programming, {TFP 2009}}, booktitle = {Trends in Functional Programming, {TFP 2009}}, year = 2010, editor = {Zolt\'an Horv{\'a}th and Vikt\'oia Zs{\'o}k and Peter Achten and Pieter Koopman}, address = {UK}, publisher = {Intellect}, URL = {http://www.intellectbooks.co.uk/books/view-Book,id=4740/} }