In opposition of Functor as super-class of Monad

[Ben Franksen]

First, let me make it clear that nowadays we are of course (I hope!) talking 
about making not only Functor, but Applicative a super-class of Monad (so 
Functor becomes a super-class by transitivity).

Petr P wrote:
> The main objections were that it would break existing code and that it
> would lead to code duplication. The former is serious, [...]
> 
> To address the first objection:

I don't buy this "it breaks lots of code" argument. Adding the missing 
instances is a complete no-brainer; as you wrote:

> instance Applicative ... where
>     pure   = return
>     (<*>)  = ap
> instance Functor ... where
>     fmap   = liftM

I do not think it is unreasonable to expect people to add such a simple and 
practically automatic fix to some old programs in the interest of cleaning 
up an old wart (and almost everyone agrees that this would be a good thing, 
in principle).

BTW, I guess most programs already contain the Functor instances (but maybe 
not Applicative, as it is newer).

I agree with Petr Pudlak that code duplication is not an issue, see above. 
And yes, these "automatic" instances may have stronger super-class 
constraints than strictly necessary. So what? The program didn't need the 
Functor (or Applicative) instance anyway (or it already would have defined 
it, in which case no change would be needed at all).

"Default superclass instances" strike me as a complicated proposal for 
solving trivial problems. The switch in Control.Exception (from data 
Exception to class Exception) was much more disrupting, adapting programs 
meant lots of changes everywhere exceptions are handled, not just adding 
some trivial instances. Still people managed the transition.

Cheers
-- 
Ben Franksen
()  ascii ribbon campaign - against html e-mail 
/\  www.asciiribbon.org   - against proprietary attachments