Después de mucho batallar pudimos encontrar la solución de este atascamiento que ciertos lectores de esta web tienen. Si deseas compartir algo puedes aportar tu información.
Solución:
los key comprender los funtores aplicativos es averiguar qué estructura conservan.
Los funtores regulares preservan la estructura categórica básica: mapean objetos y morfismos entre categorías, y preservan las leyes de la categoría (asociatividad e identidad).
Pero una categoría puede tener más estructura. Por ejemplo, puede permitir la definición de asignaciones que son como morfismos pero toman múltiples argumentos. Estas asignaciones se definen mediante curry: por ejemplo, una función de dos argumentos se define como una función de un argumento que devuelve otra función. Esto es posible si puede definir un objeto que represente un tipo de función. En general, este objeto se llama exponencial (en Haskell, es solo del tipo b->c). Entonces podemos tener morfismos de un objeto a un exponencial y llamarlo morfismo de dos argumentos.
La definición tradicional de un funtor aplicativo en Haskell se basa en la idea de mapear funciones de múltiples argumentos. Pero hay una definición equivalente que divide la función de múltiples argumentos a lo largo de un límite diferente. Puede ver una función de este tipo como un mapeo de un producto (un par, en Haskell) a otro tipo (aquí, c).
a -> (b -> c) ~ (a, b) -> c
Eso nos permite ver los funtores aplicativos como funtores que preservan el producto. Pero un producto es solo un ejemplo de lo que se llama una estructura monoide.
En general, una categoría monoide es una categoría equipada con un producto tensorial y un objeto unitario. En Haskell, esto podría ser, por ejemplo, el producto cartesiano (un par) y el tipo de unidad (). Nótese, sin embargo, que las leyes monoidales (leyes de asociatividad y de unidades) son válidas solo hasta un isomorfismo. Por ejemplo:
(a, ()) ~ a
Entonces, un funtor aplicativo podría definirse como un funtor que conserva la estructura monoide. En particular, debe preservar la unidad y el producto. No debería importar si hacemos la “multiplicación” antes o después de aplicar el funtor. Los resultados deben ser isomorfos.
Sin embargo, en realidad no necesitamos un funtor monoide en toda regla. Todo lo que necesitamos son dos morfismos (a diferencia de los isomorfismos), uno para la multiplicación y otro para la unidad. Tal funtor que conserva la mitad de la estructura monoide se llama un funtor monoide laxo. De ahí la definición alternativa:
class Functor f => Monoidal f where
unit :: f ()
(**) :: f a -> f b -> f (a, b)
Es fácil demostrar que Monoidal es equivalente a Applicative. Por ejemplo, podemos obtener pure de unit y viceversa:
pure x = fmap (const x) unit
unit = pure ()
Las leyes aplicativas se derivan simplemente de la conservación de las leyes monoides (leyes de asociatividad y de unidad).
En la teoría de categorías, la preservación de la estructura monoide está relacionada con fuerza tensorialpor lo que un funtor aplicativo también se conoce como funtor monoide laxo fuerte. Sin embargo, en hasktodo funtor tiene fuerza canónica con respecto al producto, por lo que esta propiedad no agrega nada a la definición.
Ahora, si está familiarizado con la definición de una mónada como un monoide en la categoría de endofuntores, puede interesarle saber que los aplicativos son, de manera similar, monoides en la categoría de endofuntores donde el producto tensorial es la convolución del día. Pero eso es mucho más difícil de explicar.
Estás bien, Applicative traduce menos directamente que Functor o Monad. Pero en esencia, es la clase de funtores monoidales:
class Functor f => Monoidal f where
pureUnit :: f ()
fzip :: f a -> f b -> f (a,b)
A partir de eso puedes definir – dentro hask –
pure x = fmap (const x) pureUnit
y
fs <*> xs = fmap (uncurry ($)) $ fzip fs xs
Vea esta respuesta para una prueba completa de que Applicative y Monoidal son realmente equivalentes.
Puedes asentar nuestro cometido escribiendo un comentario o puntuándolo te damos la bienvenida.