Relation entre le foncteur, le foncteur applicatif et la monade

Question

En lisant sur les classes de types, j'ai vu que la relation entre les foncteurs, les foncteurs applicatifs et les monades est celle d'une puissance strictement croissante. Les foncteurs sont des types qui peuvent être transposés. Les foncteurs applicatifs peuvent faire la même chose avec les types certains effets. Monades : même chose avec éventuellement non restrictif effets. De plus :

Every Monad is an Applicative Functor
Every Applicative Functor is a Functor

La définition du foncteur applicatif le montre clairement avec :

class Functor f => Applicative f where
  pure  :: a -> f a
  (<*>) :: f (a -> b) -> f a -> f b

Mais la définition de Monad est :

class Monad m where
  return :: a -> m a
  (>>=)  :: m a -> (a -> m b) -> m b
  (>>)   :: m a -> m b -> m b
  m >> n = m >>= \_ -> n
  fail   :: String -> m a

Selon le grand livre de Brent Yorgey. typclassopédie qu'une définition alternative de la monade pourrait être :

class Applicative m => Monad' m where
  (>>=) :: m a -> (a -> m b) -> m b

ce qui est évidemment plus simple y cimenterait que Functor < Applicative Functor < Monad. Alors pourquoi ce n'est pas la définition ? Je sais que les foncteurs applicatifs sont nouveaux, mais d'après la définition des Rapport Haskell 2010 page 80, cela n'a pas changé. Pourquoi cela ?

Answer 1

Tout le monde veut voir Applicative devenir une superclasse de Monad, mais cela casserait tellement de code (si return est éliminée, toutes les instances actuelles de Monad deviennent invalides) que tout le monde veut retarder jusqu'à ce que nous puissions étendre le langage d'une manière qui évite de casser le code ( voir ici pour une proposition importante).

Haskell 2010 a été une amélioration conservatrice et incrémentale en général, ne standardisant que quelques extensions non controversées et rompant la compatibilité dans les domaines suivants une zone pour mettre la norme en conformité avec toutes les mises en œuvre existantes. En effet, les bibliothèques d'Haskell 2010 n'incluent même pas Applicative, ce qui représente moins que ce que l'on attend de la part de la bibliothèque standard est plus standardisé que ce à quoi on pourrait s'attendre.

Espérons que la situation s'améliorera bientôt, mais heureusement, il ne s'agit généralement que d'un léger désagrément (devoir écrire liftM au lieu de fmap dans le code générique, etc.)

Answer 2

Changer la définition de Monad à ce stade, aurait cassé beaucoup de code existant (tout morceau de code qui définit une instance de Monad) pour être utile.

Une telle rupture de la rétrocompatibilité ne vaut la peine que si le changement présente un avantage pratique important. Dans ce cas, l'avantage n'est pas si important (et de toute façon, il est surtout théorique) et ne justifierait pas une telle rupture.