In opposition of Functor as super-class of Monad
tonymorris at gmail.com
Thu Oct 25 01:18:39 CEST 2012
I should hope not. The identity element (return, coreturn, mempty, pure,
Category.id) is almost never needed.
On 25/10/12 04:49, Ben Franksen wrote:
> 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.
More information about the Haskell-prime