In opposition of Functor as super-class of Monad

[Ben Franksen]

Tony Morris wrote:
> I should hope not. The identity element (return, coreturn, mempty, pure,
> Category.id) is almost never needed.
> 
> * http://hackage.haskell.org/package/semigroupoids
> * https://gist.github.com/3871764

Off-topic. Feel free to start a new thread named "The bombastic one-and-true 
class hierarchy I always wanted to have". These proposals have their merits, 
and I greatly respect the category theoretic knowledge that went into them 
-- but this is another discussion. This thread refers to a rather modest 
correction in the standard libraries, not a complete re-design. The idea is 
to fix something that is widely accepted as an unfortunate ommision (in 
fact, Oleg's comment is one of the very few that question the idea of adding 
super class constraints to Monad in principle).

BTW, it is unclear what your "I hope not" refers to, since in both of the 
hierarchies you linked to Applicative *is* a super class of Monad.

Cheers

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

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