Soit un CCC . Soit être un bifoncteur produit sur . Comme Cat est CCC, nous pouvons curry :
Catégorie de foncteurs a une structure monoïdale habituelle. A monoid en est une monade en . Nous considérons que les produits finis que la structure monoïdale sur .
Par conséquent préserve la structure monoïdale, donc il transporte un monoïde vers une monade et un comonoïde vers une comonade. À savoir, il transporte un monoïde arbitraire w vers ( W r i t e r w ) monade (regardez la définition - w doit être un monoïde). De même, il transporte la comonoïde diagonale vers la comonade Coreader.
Maintenant, pour être concret, je déplie la construction de Writer.
Commencer. En fait , ils ont simplement des noms distincts dans Haskell. Nous avons une monoid Haskell ⟨ w , m a p p e n d , m e m p t y ⟩ :
Writer est un foncteur, il doit donc cartographier également les morphismes, tels que et m e m p t y . J'écris ceci comme ci-dessous, bien qu'il ne soit pas valide dans Haskell:
est une transformation naturelle, un morphisme en C ⇒ C . Par propriétés de c u c'est une fonction, qui prend a ∈ O b ( C ) et donne un morphisme en C :
De façon informelle, des composants de leur montant de type p et pompes intacte. C'est exactement la définition de Writer dans Haskell. Un obstacle est que pour la monade ⟨ W r i t e r w , μ , r | ⟩ nous avons besoin
c'est-à-dire incompatibilité des types. Mais ces foncteurs sont isomorphes: par l'associateur habituel pour les produits finis qui est un isomorphisme naturel ≅ λ a . w × ( w × a ) = W r i t e r w ∘ W r i t e r w . On définit alors via W r i t e r m a . J'omets une construction de η via m e m p t y .
Écrivain, être un foncteur, conserve des diagrammes commutatives, à savoir les conserves monoid égalités, nous avons donc des égalités prouvé accordées pour = monoid dans ( C ⇒ C ) = une monade en C . Fin.
Et Reader et Cowriter? Le lecteur est adjoint à Coreader, comme expliqué dans la définition de Coreader, voir le lien ci-dessus. De même, Cowriter est adjoint à Writer. Je n'ai pas trouvé de définition de Cowriter, je l'ai donc inventée par analogie dans le tableau:
{- 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')))
Voici les définitions simplifiées de ces (co) monades. fr_ob F désigne une cartographie d'un foncteur F sur des objets, fr_mor F désigne une cartographie d'un foncteur F sur des morphismes. Il est un objet de monoid en C .
- Écrivain
- Lecteur
- Coreader
- Cowriter
La question est que l'adjonction en concerne les foncteurs, pas les monades. Je ne vois pas comment l'adjonction implique "Coreader est une comonade" → "Reader est une monade" et "Writer est une monade" → "Cowriter est une comonade".
Remarque. J'ai du mal à fournir plus de contexte. Cela demande du travail. Surtout, si vous avez besoin d'une pureté catégorique et que ces (co) monades ont été introduites pour les programmeurs. Continuez à harceler! ;)
Réponses:
Yes, if a monadM:C→C has a right adjoint N , then N automatically inherits a comonad structure.
IfC=D , then Fun(C,C) has a monoidal structure given by composition and so does FunL(C,D) , because the composition of left adjoints is a left adjoint. Specifically, (FG)R=GRFR , so −R is an antimonoidal contravariant functor. If you apply −R to the structural natural transformations which equip a functor M with the structure of a monad, what you get out is a comonad.
la source
By the way, this:
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 withC 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:
whereC×D is a product of categories, and ED is the category of functors F:D→E . This works regardless of whether C , D and E are Cartesian closed, though. When we let C=D=E , we get:
But this is merely a special case of:
la source
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×A→Y}≅{f∗:X→YA} . Or if it helps, −∗:hom(−×A,=×1)≅hom(−1,=A)
la source