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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime