On Thu, Oct 3, 2013 at 8:16 AM, Wvv <vite...@rambler.ru> wrote: > > Your first two cases will be fixed in 7.10, as Applicative finally > becomes > a superclass of Monad. > > Sure, newclassses not about Applicative and Monads only. > This question is more wider. > > Must Apply be a superclass of Bind? > Must Bind be a superclass of Monad? > So, must Monad has 2 superclasses at once: Bind and Applicative? > > Must Semigroupoids be a superclass of Category? > Must Category be a superclass of Arrow?

There is no theoretical problem here, just a practical one. It would be resolved by solving your 4th problem, for which you don't need newclasses. Consider: {-# LANGUAGE ConstraintKinds #-} class Functor f where { fmap :: (a -> b) -> f a -> f b } class Functor f => Apply f where { (<*>) :: f (a -> b) -> f a -> f b } class Apply f => Applicative f where { pure :: a -> f a } class Apply f => Bind f where { (=<<) :: (a -> f b) -> f a -> f b } type Monad f = (Applicative f, Bind f) return :: Monad f => a -> f a return = pure I might have made some mistakes in the exact hierarchy, but something like this should work. There are no problems with having hierarchies like this, as far as I'm aware. The current problem is that nobody wants to use this hierarchy: to get a Monad instance, you have to write four separate instances for your type. What would be nicer is a feature (ConstraintSynonymInstances?) where something like this can be written: instance (Functor Maybe, Apply Maybe, Monad Maybe) where fmap _ Nothing = Nothing fmap f (Just x) = Just (f x) Just f <*> Just x = Just (f x) _ <*> _ = Nothing pure = Just f =<< Just x = f x _ =<< Nothing = Nothing This would be sugar for instance Functor Maybe where { fmap = ... } instance Apply Maybe where { (<*>) = ... } instance Monad Maybe where { pure = ... ; (=<<) = ... } and the last would be sugar for instance Applicative Maybe where { pure = ... } instance Bind Maybe where { (=<<) = ... } You don't need any new keywords for this, because the above does not conflict with the existing rules for instance declarations. > Also, I don't see why it would be a misfeature to have Eq as a superclass > > of Ord, or Functor as a superclass of Applicative. > I see 2 reasons: > 1) class functions in reality don't depend of superclass functions > 2) Haskell can't check if superclass instance is correspond with class laws Again, I don't see why that makes it a misfeature.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe