Proposal: Applicative => Monad: Call for consensus

John Smith voldermort at hotmail.com
Wed Jan 5 16:22:53 CET 2011


On 05/01/2011 12:33, Simon Marlow wrote:
> We have a hard time explaining Monads to people already. But now the entire API goes from being one class with 3 methods
> (only 2 of which you need to care about) to being 3 classes with a total of 11 methods, with a lot of complex
> interactions. That's a significant increase in cognitive overhead. It might well be the "right" thing in some sense, but
> is it really worth the pain? What about all those monad tutorials? They now have to include some Functor/Applicative
> boilerplate, and hope it doesn't put the reader off too much. I like Applicative, I really do, but I want it to be
> something you only have to buy into if you want to.

The original Arrow was one class with a few simple methods, and extremely easy to explain. There are now several classes 
in the Arrow module, and Arrow itself is a subclass of Category. Tutorials simply use the original Arrow definition, 
which gets the concept across fine. The learner can then proceed to understand the richer, and better factored, current 
implementation.

> Someone knocking up a monad for a simple job now has to define 3 instances, not one. So it affects not just people
> learning the language, but also those already familiar with it and trying to get the job done.

This creates a little extra work for those who don't want Functor or Applicative (the methods have to be defined anyway, 
it's just split across the new class hierarchy). Those who do want Functor or Applicative now have them where they 
belong, without writing boilerplate definitions. Much like anyone declaring an instance of Ord also needs an instance of 
Eq, even if they're not going to use it.

> Furthermore, we have some significant compatibility issues with Haskell 98/2010 code. I wouldn't be in favour of doing
> this unless we can retain Haskell 98/2010 compatibility somehow (e.g. with superclass defaults or class aliases).

This is part of a larger problem. Is Haskell to be forever frozen as something which can be easily made compatible with 
Haskell 98? Haskell 98 an earlier made many non-backwards compatible changes, including changes to the Monad class.




More information about the Libraries mailing list