tutorial - haskell simbolos

Relación entre el Functor, el Functor Aplicativo y la Mónada

Question

Al leer sobre clases de tipos, he visto que la relación entre Functors, Aplicative Functors y Monads es la de aumentar estrictamente el poder. Los funtores son tipos que se pueden mapear. Los Funcionadores Aplicativos pueden hacer las mismas cosas con ciertos efectos. Las mónadas son iguales con efectos posiblemente no restringidos . Además:

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

La definición del Funcionador Aplicativo muestra esto claramente con:

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

Pero la definición de Monad es:

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

De acuerdo con la gran typeclassopedia Brent Yorgey, una definición alternativa de mónada podría ser:

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

que obviamente es más simple y consolidaría ese Functor <Applicative Functor <Monad. Entonces, ¿por qué esta no es la definición? Sé que los funtores aplicativos son nuevos, pero de acuerdo con la página 80 del Informe Haskell de 2010 , esto no ha cambiado. ¿Por qué es esto?

Answer 1

Cambiar la definición de Mónada en este punto, habría quebrado una gran cantidad de código existente (cualquier código que defina una instancia de Mónada) para que valga la pena.

Romper la compatibilidad con versiones anteriores solo vale la pena si hay un gran beneficio práctico para el cambio. En este caso, el beneficio no es tan grande (y en su mayoría teórico de todos modos) y no justificaría esa cantidad de rotura.

Answer 2

Todo el mundo quiere ver que Applicative se convierta en una superclase de Monad, pero rompería tanto código (si se elimina el return , todas las instancias actuales de Monad se vuelven inválidas) que todos quieran esperar hasta que podamos extender el lenguaje de tal manera que evite romper el código ( ver aquí una propuesta destacada).

Haskell 2010 fue una mejora progresiva conservadora en general, estandarizando solo algunas extensiones no controvertidas y rompiendo la compatibilidad en un área para alinear el estándar con cada implementación existente. De hecho, las bibliotecas de Haskell 2010 ni siquiera incluyen Aplicativo: menos de lo que las personas esperan de la biblioteca estándar está estandarizado de lo que cabría esperar.

Con suerte veremos que la situación mejore pronto, pero afortunadamente solo es un inconveniente leve (tener que escribir liftM lugar de fmap en código genérico, etc.).