In opposition of Functor as super-class of Monad
tonymorris at gmail.com
Thu Oct 25 23:46:57 CEST 2012
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.
>> On 25/10/12 04:49, Ben Franksen wrote:
>>> First, let me make it clear that nowadays we are of course (I hope!)
>>> 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
>>> practically automatic fix to some old programs in the interest of
>>> up an old wart (and almost everyone agrees that this would be a good
>>> in principle).
>>> BTW, I guess most programs already contain the Functor instances (but
>>> not Applicative, as it is newer).
>>> I agree with Petr Pudlak that code duplication is not an issue, see
>>> 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
>>> 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