In opposition of Functor as super-class of Monad

[Tony Morris]

I should have been clearer sorry. I should hope not that Functor <-
Applicative <- Monad.

Perhaps I do not understand the purpose of this thread, but "fixing" the
hierarchy in this way is a mistake of similar magnitude to the original
position -- one that I would cringe at seeing repeated. That is why I
thought such a discussion was on-topic.


On 25/10/12 10:12, Ben Franksen wrote:
> 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
>>


-- 
Tony Morris
http://tmorris.net/