Lector, escritor mónadas


17

Deje que C sea ​​un CCC . Vamos a (×) sea un producto en bifuntor C . Como Cat es CCC, podemos curry (×) :

curry(×):C(CC)

curry(×)A=λB.A×B

La categoría de functor CC tiene una estructura monoidal habitual. A monoid en CC es una mónada en C . Consideramos productos finitos como la estructura de monoidal C .

curry(×)1id

A B.curry(×)(A×B)(curry(×)A)(curry(×)B)

Por lo tanto (curry(×)) conserva la estructura monoidal, por lo que transporta un monoide a una mónada y un comonoide a una comonad. A saber, transporta un monoide arbitrario a mónada (mira la definición - debe ser un monoide). Del mismo modo, transporta el comonoide diagonal al comandante Coreader.( W r i t e r w ) ww(Writer w)w

Ahora, para concretar, despliego la construcción de Writer.

Empezar. En realidad, Writer=Coreader=curry(×) , simplemente tienen nombres distintos en Haskell. Tenemos un monoid Haskell w,mappend,mempty :

mappend:w×ww

mempty:1w

Writer es un functor, por lo que debe mapear también los morfismos, como mappend y mempty . Escribo esto como a continuación, aunque no es válido en Haskell:

Writer mappend:Writer(w×w)Writer w

es una transformación natural, un morfismo en C C . Por propiedades de c u r r y ( × ) es una función, que toma a O b ( C ) y da un morfismo en C :Writer mappendCCcurry(×)aOb(C)C

Writer mappend a=mappend×(id(a)):Writer(w×w)aWriter w a

De manera informal, sumas componentes de tipo w y bombas un intacta. Esta es exactamente la definición de escritor en Haskell. Uno de los obstáculos es que para la mónada W r i t e r w , μ , eta necesitamosWriter mappend awaWriter w,μ,η

μ:Writer wWriter wWriter w

es decir, incompatibilidad de tipos. Pero estos functores son isomórficos: por el asociador habitual para productos finitos que es un isomorfismo natural λ a . w × ( w × a ) = W r i t e r w W r i t e r wWriter(w×w)=λa.(w×w)×aλa.w×(w×a)=Writer wWriter w. Luego definimos vía W r i t e r m a p p e n d . Omito una construcción de η a través de m e m p t y .μWriter mappendηmempty

Escritor, siendo un funtor, conserva diagrama conmutativo, es decir, conservas monoid igualdades, por lo que tenemos para igualdades probadas concedidas para = a monoid en ( C C ) = a mónada en C . Final.Writer w,μ,η(CC)C

¿Qué pasa con Reader y Cowriter? Reader es adjunto a Coreader, como se explica en la definición de Coreader, ver enlace arriba. Del mismo modo, Cowriter es adjunto al escritor. No encontré una definición de Cowriter, así que la inventé por analogía en la tabla:

texto alternativo

{- base, Hackage.category-extras -}
import Control.Comonad
import Data.Monoid
data Cowriter w a = Cowriter (w -> a)
instance Functor (Cowriter w) where
    fmap f (Cowriter g) = Cowriter (f . g)
instance Monoid w => Copointed (Cowriter w) where
    extract (Cowriter g) = g mempty
instance Monoid w => Comonad (Cowriter w) where
    duplicate (Cowriter g) = Cowriter
        (\w' -> Cowriter (\w -> g (w `mappend` w')))

A continuación se encuentran las definiciones simplificadas de esas (co) mónadas. fr_ob F denota un mapeo de un functor F en objetos, fr_mor F denota un mapeo de un functor F en morfismos. Hay un objeto monoid en C .w,+^,0^C

  • Escritor
    • fr_ob(Writer w)a=a×w
    • fr_mor(Writer w)f=λa0,w2.a0,f w2
    • ηa=λa0.a0,0^
    • μa=λa0,w1,w0.a0,w0+^w1
  • Lector
    • fr_ob(Reader r)a=ra
    • fr_mor(Reader r)f=λg r0.f(g r0)
    • ηa=λa0 r0.a0
    • μa=λf r0.f r0 r0
  • Coreader
    • fr_ob(Coreader r)a=r×a
    • fr_mor(Coreader r)f=λr0,a0.f r0,a0
    • ηa=λr0,a0.a0
    • μa=λr0,a0.r0,r0,a0
  • Cowriter
    • fr_ob(Cowriter w)a=wa
    • fr_mor(Cowriter w)f=λg r0.f(g r0)
    • ηa=λf.f 0^
    • μa=λf w1w0.f(w0+^w1)

La pregunta es que el adjunto en relaciona a los functores, no a las mónadas. No veo cómo el adjunto implica "Coreader es una comonad" "Reader es una mónada" y "Writer es una mónada" "Cowriter es una comonad".C

Observación. Estoy luchando por proporcionar más contexto. Requiere algo de trabajo. Especialmente, si necesita pureza categórica y esas (co) mónadas fueron introducidas para programadores. Sigue regañando! ;)


Oferta: puede tomar una captura de pantalla de la tabla y poner la imagen aquí.
MS Dousti

Deberías copiar la pregunta aquí.
Dave Clarke

2
las personas que votan en contra deben publicar un comentario explicando por qué.
Suresh Venkat

1
@Ohad. I confess that I introduced that change to try to provide the question with more context (as was originally found in the blog post originally referenced). I think beroal should spend more effort making his question self contained, for example, by defining what Reader and Writer and Coreader and Cowriter are in categorical terms or in Haskell or both, rather than assuming that we all know what is being referred to.
Dave Clarke

2
@beroal: What I meant was that, as I don't use Haskell on a day to day basis, parsing the Haskell code and making the transition into CT is non-trivial for me, and perhaps others. By rephrasing the question in purely categorical terms, you are more likely to receive an answer quicker...
Ohad Kammar

Respuestas:


13

Yes, if a monad M:CC has a right adjoint N, then N automatically inherits a comonad structure.

The general category-theoretic setting to understand this is as follows. Let C and D be two categories. Write Fun(C,D) for the categeory of functors from C to D; Its objects are functors and its morphisms natural transformations. Write FunL(C,D) for the full subcategory of Fun(C,D) on the functors which have right adjoints (in other words, we consider functors CD with right adjoints and arbitrary natural transformations between them). Write FR:DC for the right adjoint of a functor F:CD. Then R:FunL(C,D)Fun(D,C) is a contravariant functor: if α:FG is a natural transformation then there is an induced natural transformation αR:GRFR.

C=DFun(C,C)FunL(C,D)(FG)R=GRFRRRM with the structure of a monad, what you get out is a comonad.


1
And one should mention that some of these functors, for example R is not really a functor but rather something like a pseudo-functor because it typically satisfies functoriality only up to canonical isomorphisms. Nevertheless, the main point is valid.
Andrej Bauer

7

By the way, this:

Let (×) be a product bifunctor in C. As C is CCC, we can curry (×)

is slightly incorrect. For one, the usual terminology would be (if I'm not mistaken) that × is a bifunctor over or on C. "In" typically means constructions using the arrows and objects of a category, whereas functors "on" categories refer to constructions relating multiple categories. And the product bifunctor isn't a construction within a Cartesian category.

And this relates to the larger inaccuracy: the ability to curry the product bifunctor has nothing to do with C being Cartesian closed. Rather, it is possible because Cat, the category of categories (insert caveats) is Cartesian closed. So the currying in question is given by:

HomCat(C×D,E)HomCat(C,ED)

where C×D is a product of categories, and ED is the category of functors F:DE. This works regardless of whether C, D and E are Cartesian closed, though. When we let C=D=E, we get:

×:C×CC
curry×:CCC

But this is merely a special case of:

F:C×DE
curryF:CED

2 Dan Doel: Yes, yes, yes, thanks. I did the mistake while translating from the original post beroal.livejournal.com/23223.html .
beroal

4

Consider the adjunction F,G,ϵ,η. For every such adjunction we have a monad GF,η,GϵF and also a comonad FG,ϵ,FηG. Notably, F and G need not be endofunctors, and in general they aren't (e.g., the list monad is an adjuction between the free and forgetful functors between Set and Mon).

So, what you want to do is take Reader (or Writer) and decompose it into the adjoint functors which give rise to the monad and the corresponding comonad. Which is to say that the connection between Reader and Coreader (or Writer and Cowriter) isn't the one you're looking for.

And it's probably better to think of currying as :hom(×A,=)hom(,=A), i.e. X,Y. {f:X×AY}{f:XYA}. Or if it helps, :hom(×A,=×1)hom(1,=A)


2 wren ng thornton: I am not aware of any defining adjunction for Reader and Writer similar to adjunctions between Set and a category of algebraic structures. Or do you mean that every monad is defined by an adjunction as in "MacLane. Categories for the Working Mathematician. VI. Monads and Algebras. 2. Algebras for a Monad. Theorem 1 (Every monad is defined by its T-algebras)."? Can you be more specific? Actually my question is the conclusion of an attempt to define those (co)monads in elegant words as the list monad is.
beroal

@beroal: I'm pretty sure Reader and Writer aren't adjoint, or at least I've yet to find a way to get the categories to work out for it. No, my point was that monads and comonads arise in "the same way", namely via an adjunction, as described above. I don't have a copy of MacLane, but yes T-algebras are the standard name for the trick above (but then again, all sorts of unrelated things are called "X-algebras", "Y-algebras",...).
wren romano

Which description of the list monad are you trying to match the eloquence of? Given the free monoid functor F:SetMon, the forgetful functor U:MonSet, the unit transformation η:idSetUF, and the counit transformation ϵ:FUidMon you have an adjunction F,U,η,ϵ. Which means you have a monad UF,η,UϵF, namely the list monad in Set. And you get the list comonad in Mon: FU,ϵ,FηU. Eloquent?
wren romano

Functors (Reader a) and (Writer a) are adjoint, and that adjunction gives rise to the (State a) monad.
beroal

"No, my point was that monads and comonads arise in "the same way", namely via an adjunction, as described above". If you get the monad and the comonad from the adjunction between categories Set and Mon, you get the monad on Set and the comonad on Mon — different categories. But Reader and Writer are on the same CCC category.
beroal
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.