¿Existe un concepto de algo así como functores co-aplicativos sentados entre comonads y functors?


17

Cualquier mónada también es un funtor aplicativo y cualquier funtor aplicativo es un ficticio. Además, cualquier comonad es un functor. ¿Existe un concepto similar entre comonads y functors, algo así como un co-aplicador y cuáles son sus propiedades?

FunctorsFunctorsApplicative functors???MonadsComonads

Actualización: también me interesarían los posibles usos de dicho concepto.


¿Estás seguro de que no estabas buscando Comonads -> ??? -> Cofunctores?
Josías

1
@josiah No, que yo sepa, los comonads son functores , no cofunctores.
Petr Pudlák

1
¿No es divisible esa pieza faltante?
Gus

Respuestas:


15

Ante todo:

Cualquier mónada también es un funtor aplicativo y cualquier funtor aplicativo es un ficticio.

Esto es cierto en el contexto de Haskell, pero (que se lee Applicativecomo "functor monoidal fuerte y laxo") no en general, por la razón bastante trivial de que puede tener functores "aplicativos" entre diferentes categorías monoidales, mientras que las mónadas (y comonads) son endofunctores .

Además, la identificación Applicativecon functores monoidales laxos y fuertes es un poco engañoso, porque para justificar el nombre (y la firma de tipo de (<*>)) se requiere un functor entre las categorías monoidales cerradas que conserva la estructura monoidal y el hom interno . Esto podría llamarse un "functor monoidal cerrado laxo", excepto que un functor entre categorías cerradas monoidales que conserva cualquiera de las propiedades conserva la otra de la manera obvia . Debido a que Applicativesolo describe los endofunctores en Hask preservando la estructura monoidal (,), sus instancias obtienen muchas propiedades automáticamente, incluida su resistencia , que por lo tanto se puede eludir.

La conexión aparente con Monades posiblemente un artefacto de las limitaciones implícitas en Applicativehacer coincidir aspectos de sus respectivas estructuras monoides, una feliz coincidencia que desafortunadamente no sobrevive a la dualización.

Así como una comonad en una categoría es una mónada en C o p , un functor monoidal oplax C D es un functor monoidal laxo C o pD o p . Pero H a s k o p no está cerrado monoidal , y un co- que no incluye la aplicación de función apenas merece el nombre. De todos modos, el resultado no sería terriblemente interesante:CCop CDCopagreopagHunskopagApplicative

class (Functor f) => CoMonoidal f where
    counit :: f () -> ()
    cozip :: f (a, b) -> (f a, f b)

ApplicativeHunskopagnewtype Op b a = Op (a -> b)HunsksiunHunskopagOp b aHunsk

HunskApplicative

class (Functor f) => CoApplicative f where
    copure :: f a -> a
    coap :: (f a -> f b) -> f (a -> b)

Agregar duplicate :: f a -> f (f a)a copureproduciría una comonad (suponiendo que se cumplan las leyes), por supuesto. Pero no hay una relación obvia entre, coapsea ​​lo que sea, y extend :: (f a -> b) -> f a -> f b. La comparación de los tipos se hace evidente que la dualización está ocurriendo en diferentes formas: las estructuras comonoidal subyacentes duplicatey coziptienen poco que ver entre sí o con coap(que probablemente no tiene sentido de todos modos), mientras que liftA2 (,)y (<*>)son equivalentes y se pueden derivar de join.

Otra posible forma de dualización Applicative, que tiene aún menos que ver con comonads, es considerar los functores monoidales contravariantes:

class (Contravariant f) => ContraMonoidal f where
    contraunit :: f a
    contrazip :: f a -> f b -> f (Either a b)

Hunskopagb <~ acontracurry :: (Either c b <~ a) -> (c <~ (b <~ a))contraapply :: b -> Either a (a <~ b)

HunskCoApplicative

Sin embargo, en una categoría cerrada monoidal más hospitalaria para la dualización, es posible que tenga mejor suerte. En particular, creo que ambos Kleisli (Cont r)y su categoría opuesta son cerrados monoidales, por lo que podría ser un mejor contexto para explorar estas ideas.


Al comparar su respuesta con cstheory.stackexchange.com/a/22302/989 , es sorprendente que no dualice los productos a sumas. Por supuesto, tienes razón en que Hask no tiene sumas categóricas; pero si está dispuesto a restringir a la categoría de programas totales (como en Agda), supongamos que está configurado por ahora, ese problema desaparece. (No digo que Set ^ op sea cerrado monoidal, pero sospecho que lo que digo lo implica).
Blaisorblade

8

En esta publicación sobre SO encontré una respuesta interesante: functores decisivos . Si reemplazamos ()por Void, (,)por Either e invertimos las flechas, obtenemos:

class Functor f => Decisive f where
    nogood :: f Void -> Void
    orwell :: f (Either s t) -> Either (f s) (f t)

La publicación del blog también ofrece algunas leyes a las que se adhieren los fundadores decisivos.

Y, todo Comonades también Decisive:

instance Comonad c => Decisive c where
    nogood = counit
    orwell story = case counit story of
                     Left s  -> fmap (either id (const s)) story
                     Right t -> fmap (either (const t) id) story 

De modo que los functores decisivos encajan entre functores y comonads, así como los fundores aplicativos encajan entre functors y mónadas.


6

McBride y Patterson (Sección 7) muestran que un functor aplicativo, también conocido como modismo, es un functor monoidal fuerte y laxo . Está buscando un functor monoidal fuerte colax también conocido como un functor monoidal oplax fuerte . Como se menciona en un comentario, un functor monoidal oplax es un functor monoidal laxo entre las categorías opuestas, que termina siendo una versión comonoidal de un functor monoidal lax.

¡Dibuja los diagramas, invierte las flechas!

Tendría que pasar un poco de tiempo resolviendo los detalles para ver cuál es y traducirlo en una noción de programación funcional.


Por alguna razón, el término estándar parece ser "functor monoidal oplax". La idea es un functor monoidal laxo entre las categorías opuestas, que termina siendo una versión comonoidal de un functor monoidal laxo. El uso de "colax comonoidal" es redundante o equivalente a "lax monoidal".
CA McCann

Exageré el "co" -ing. Arreglaré mi respuesta.
Dave Clarke
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.