In opposition of Functor as super-class of Monad

[Tony Morris]

OK, sorry about the noise!

On 26/10/12 09:41, Edward Kmett wrote:
> Tony, I think you misparsed the proposal. 
>
> The ...'s were for specific monads indicating the additional work required for each Monad.
>
> I think the only real proposal on the table is the obvious one of adding Applicative as a superclass of monad.
>
> From there there are a couple of incremental "improvements" that could be made like adding the unimplemented superclass defaults or adding the equivalent of DefaultSignatures to the language spec to reduce the burden on Monad implementors.
>
> In practice I think either of those extensions would be premature to add to the language specification at this time.
>
> I would be 100% behind adding the Applicative constraint as a superclass of Monad and even perhaps of some bikeshedding, like exporting Applicative from the Prelude, because otherwise you can't define a Monad without an import, while you can now.
>
> I would be strongly against requiring superclass defaults or DefaultSignatures in the haskell standard, however. The former is a largely untested point in the design space and the latter has issues where it tightly couples classes with their dependencies, leading to unbreakable cycles between classes that all have to be defined together and poor engineering practices.
>
> Best,
> --Edward
>
>
> On Oct 25, 2012, at 5:46 PM, Tony Morris <tonymorris at gmail.com> wrote:
>
>> 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/
>>
>>
>>
>> _______________________________________________
>> Haskell-prime mailing list
>> Haskell-prime at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-prime


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