Functor => Applicative => Monad

kahl at kahl at
Tue Dec 14 16:44:38 CET 2010

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:



  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.}

  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 = {,id=4740/}

More information about the Libraries mailing list