[Haskell-cafe] Why the reluctance to introduce the Functor requirement on Monad?

[Ivan Lazar Miljenovic]

On 21 July 2011 11:10, Arlen Cuss <celtic at sairyx.org> wrote:
> Hi cafe!
>
> I feel a bit like I'm speaking out of turn for bringing this up -- and
> I'm sure it must have been brought up many times before -- but I hope
> there can be something fruitful had from a discussion.
>
> In my travels I've read several people with much better grasp of Haskell
> than I have mention -- with a sad sigh of resignation -- that functions
> like liftM and return abound because some Monads don't state their
> fulfillment of Functor (or Applicative, but that's even more recent),
> and thus we can't use fmap/<$> or pure.

Well, for fmap vs liftM, you have that liftM is automatically defined
for you rather than needing to make the Functor instance, so if you're
quickly defining a Monad for internal use then you can just use liftM,
etc. without needing to also make Functor and Applicative instances
(note that AFAIK, return  and pure are the same thing, in that return
isn't automatically defined like liftM is).

That said, stylistically speaking when I'm writing monadic code, I
tend to prefer to use liftM rather than fmap as a personal preference.
 Note that if you're writing polymorphic Monad functions (i.e. you
have "Monad m => ..." in your type signature rather than a specific
Monad) then you have to use liftM and the like because we currently
don't have that Monad implies Functor.

> I understand a motivation might be that code would break if the former
> lot were removed, but surely they could shifted to the latter (and the
> former simply be defined as the latter). It might be a very large
> effort, I suppose, to comb through the standard libraries and make
> everything compile again, but is there something else I'm surely missing?

It would remove backwards-compatability if/when the typeclass
hierarchy is fixed, and thus a lot of code would break; as such I
believe that it _is_ on the table for a future version of Haskell'
that will not be 100% backwards compatible with Haskell98 and
Haskell2010.  The big effort here would be with user code and
packages, rather than standard libraries (as the former presumably has
more LOC than the latter).

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
IvanMiljenovic.wordpress.com