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 <tonymor...@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@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-prime
-- Tony Morris http://tmorris.net/ _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
