Every monad is an applicative functor — generalizing to other categories

Multi tool use
Multi tool use












5














I can readily enough define general Functor and Monad classes in Haskell:



class (Category s, Category t) => Functor s t f where
map :: s a b -> t (f a) (f b)

class Functor s s m => Monad s m where
pure :: s a (m a)
join :: s (m (m a)) (m a)
join = bind id
bind :: s a (m b) -> s (m a) (m b)
bind f = join . map f


I'm reading this post which explains an applicative functor is a lax (closed or monoidal) functor. It does so in terms of a (exponential or monoidal) bifunctor. I know in the Haskell category, every Monad is Applicative; how can we generalize? How should we choose the (exponential or monoidal) functor in terms of which to define Applicative? What confuses me is our Monad class seems to have no notion whatsoever of the (closed or monoidal) structure.



Edit: A commenter says it is not generally possible, so now part of my question is where it is possible.










share|improve this question
























  • I seem to recall that this is not generally true, and relies on the extra (closed, etc.) structure of Hask.
    – Rein Henrichs
    Dec 27 '18 at 16:48






  • 1




    hackage.haskell.org/package/constrained-categories-0.3.1.1/docs/…
    – leftaroundabout
    Dec 27 '18 at 17:00
















5














I can readily enough define general Functor and Monad classes in Haskell:



class (Category s, Category t) => Functor s t f where
map :: s a b -> t (f a) (f b)

class Functor s s m => Monad s m where
pure :: s a (m a)
join :: s (m (m a)) (m a)
join = bind id
bind :: s a (m b) -> s (m a) (m b)
bind f = join . map f


I'm reading this post which explains an applicative functor is a lax (closed or monoidal) functor. It does so in terms of a (exponential or monoidal) bifunctor. I know in the Haskell category, every Monad is Applicative; how can we generalize? How should we choose the (exponential or monoidal) functor in terms of which to define Applicative? What confuses me is our Monad class seems to have no notion whatsoever of the (closed or monoidal) structure.



Edit: A commenter says it is not generally possible, so now part of my question is where it is possible.










share|improve this question
























  • I seem to recall that this is not generally true, and relies on the extra (closed, etc.) structure of Hask.
    – Rein Henrichs
    Dec 27 '18 at 16:48






  • 1




    hackage.haskell.org/package/constrained-categories-0.3.1.1/docs/…
    – leftaroundabout
    Dec 27 '18 at 17:00














5












5








5







I can readily enough define general Functor and Monad classes in Haskell:



class (Category s, Category t) => Functor s t f where
map :: s a b -> t (f a) (f b)

class Functor s s m => Monad s m where
pure :: s a (m a)
join :: s (m (m a)) (m a)
join = bind id
bind :: s a (m b) -> s (m a) (m b)
bind f = join . map f


I'm reading this post which explains an applicative functor is a lax (closed or monoidal) functor. It does so in terms of a (exponential or monoidal) bifunctor. I know in the Haskell category, every Monad is Applicative; how can we generalize? How should we choose the (exponential or monoidal) functor in terms of which to define Applicative? What confuses me is our Monad class seems to have no notion whatsoever of the (closed or monoidal) structure.



Edit: A commenter says it is not generally possible, so now part of my question is where it is possible.










share|improve this question















I can readily enough define general Functor and Monad classes in Haskell:



class (Category s, Category t) => Functor s t f where
map :: s a b -> t (f a) (f b)

class Functor s s m => Monad s m where
pure :: s a (m a)
join :: s (m (m a)) (m a)
join = bind id
bind :: s a (m b) -> s (m a) (m b)
bind f = join . map f


I'm reading this post which explains an applicative functor is a lax (closed or monoidal) functor. It does so in terms of a (exponential or monoidal) bifunctor. I know in the Haskell category, every Monad is Applicative; how can we generalize? How should we choose the (exponential or monoidal) functor in terms of which to define Applicative? What confuses me is our Monad class seems to have no notion whatsoever of the (closed or monoidal) structure.



Edit: A commenter says it is not generally possible, so now part of my question is where it is possible.







haskell category functor applicative category-theory






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Dec 27 '18 at 17:12

























asked Dec 27 '18 at 16:39









M Farkas-Dyck

15118




15118












  • I seem to recall that this is not generally true, and relies on the extra (closed, etc.) structure of Hask.
    – Rein Henrichs
    Dec 27 '18 at 16:48






  • 1




    hackage.haskell.org/package/constrained-categories-0.3.1.1/docs/…
    – leftaroundabout
    Dec 27 '18 at 17:00


















  • I seem to recall that this is not generally true, and relies on the extra (closed, etc.) structure of Hask.
    – Rein Henrichs
    Dec 27 '18 at 16:48






  • 1




    hackage.haskell.org/package/constrained-categories-0.3.1.1/docs/…
    – leftaroundabout
    Dec 27 '18 at 17:00
















I seem to recall that this is not generally true, and relies on the extra (closed, etc.) structure of Hask.
– Rein Henrichs
Dec 27 '18 at 16:48




I seem to recall that this is not generally true, and relies on the extra (closed, etc.) structure of Hask.
– Rein Henrichs
Dec 27 '18 at 16:48




1




1




hackage.haskell.org/package/constrained-categories-0.3.1.1/docs/…
– leftaroundabout
Dec 27 '18 at 17:00




hackage.haskell.org/package/constrained-categories-0.3.1.1/docs/…
– leftaroundabout
Dec 27 '18 at 17:00












2 Answers
2






active

oldest

votes


















3















What confuses me is our Monad class seems to have no notion whatsoever of the (closed or monoidal) structure.




If I understood your question correctly, that would be provided via the tensorial strength of the monad. The Monad class doesn't have it because it is intrinsic to the Hask category. More concretely, it is assumed to be:



t :: Monad m => (a, m b) -> m (a,b)
t (x, my) = my >>= y -> return (x,y)





share|improve this answer





















  • So in general, Applicative is not a superclass of Monad? Rather they are both superclasses of (say) StrongMonad? (And i guess Applicative can't even be defined unless the category is monoidal?)
    – M Farkas-Dyck
    Dec 27 '18 at 17:24












  • That is my understanding. In particular (<*>) = ap and in a general setting ap :: (Monad m) => m (a -> b) -> m a -> m b requires tensorial strength (more obvious if we uncurry it).
    – Jorge Adriano
    Dec 27 '18 at 17:46



















3














Essentially, all the monoidal stuff involved in the methods of a monoidal functor happens on the target category. It can be formalised thus:



class (Category s, Category t) => Functor s t f where
map :: s a b -> t (f a) (f b)

class Functor s t f => Monoidal s t f where
pureUnit :: t () (f ())
fzip :: t (f a,f b) (f (a,b))


s-morphisms only come in if you consider the laws of a monoidal functor, which roughly say that the monoidal structure of s should be mapped into this monoidal structure of t by the functor.



Perhaps more insightful is to factor an fmap into the class methods, so it's clear what the “func-”-part of the functor does:



class Functor s t f => Monoidal s t f where
...
puref :: s () y -> t () (f y)
puref f = map f . pureUnit
fzipWith :: s (a,b) c -> t (f a,f b) (f c)
fzipWith f = map f . fzip


From Monoidal, we can get back our good old Hask-Applicative thus:



pure :: Monoidal (->) (->) f => a -> f a
pure a = puref (const a) ()

(<*>) :: Monoidal (->) (->) f => f (a->b) -> f a -> f b
fs <*> xs = fzipWith (uncurry ($)) (fs, xs)


or



liftA2 :: Monoidal (->) (->) f => (a->b->c) -> f a -> f b -> f c
liftA2 f xs ys = fzipWith (uncurry f) (xs,ys)


Perhaps more interesting in this context is the other direction, because that shows us up the connection to monads in the generalised case:



instance Applicative f => Monoidal (->) (->) f where
pureUnit = pure
fzip = (xs,ys) -> liftA2 (,) xs ys
= (xs,ys) -> join $ map (x -> map (x,) ys) xs


That lambdas and tuple sections aren't available in a general category, however they can be translated to cartesian closed categories.





I'm using (,) as the product in both monoidal categories, with identity element (). More generally you might write data I_s and data I_t and type family (⊗) x y and type family (∙) x y for the products and their respective identity elements.






share|improve this answer























  • You may well be right, maybe I'm missing something. Looking at the definition of monoidal functor though, the natural transformation Φ: FA ⊗ FB -> F(A⊗B), in the case of an endofunctor, seems to be just the monad's strength no? not as I wrote it but it's pretty straightforward to derive a strength t': TA ⊗ TB -> T (A⊗B) from t: A ⊗ TB -> T (A⊗B). Is it something else I'm missing here?
    – Jorge Adriano
    Dec 27 '18 at 18:19










  • I think it begs the question, to use (,) as the product.
    – M Farkas-Dyck
    Dec 27 '18 at 19:04












  • @MFarkas-Dyck not sure. You definitely need some CCC helpers to connect the monoidal-functor and monad classes, and in any CCC the product will essentially behave as a tuple (even if you don't use Haskell tuples). But, if I'm wrong I'd be excited to see a counterexample.
    – leftaroundabout
    Dec 27 '18 at 19:12











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53948171%2fevery-monad-is-an-applicative-functor-generalizing-to-other-categories%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes









3















What confuses me is our Monad class seems to have no notion whatsoever of the (closed or monoidal) structure.




If I understood your question correctly, that would be provided via the tensorial strength of the monad. The Monad class doesn't have it because it is intrinsic to the Hask category. More concretely, it is assumed to be:



t :: Monad m => (a, m b) -> m (a,b)
t (x, my) = my >>= y -> return (x,y)





share|improve this answer





















  • So in general, Applicative is not a superclass of Monad? Rather they are both superclasses of (say) StrongMonad? (And i guess Applicative can't even be defined unless the category is monoidal?)
    – M Farkas-Dyck
    Dec 27 '18 at 17:24












  • That is my understanding. In particular (<*>) = ap and in a general setting ap :: (Monad m) => m (a -> b) -> m a -> m b requires tensorial strength (more obvious if we uncurry it).
    – Jorge Adriano
    Dec 27 '18 at 17:46
















3















What confuses me is our Monad class seems to have no notion whatsoever of the (closed or monoidal) structure.




If I understood your question correctly, that would be provided via the tensorial strength of the monad. The Monad class doesn't have it because it is intrinsic to the Hask category. More concretely, it is assumed to be:



t :: Monad m => (a, m b) -> m (a,b)
t (x, my) = my >>= y -> return (x,y)





share|improve this answer





















  • So in general, Applicative is not a superclass of Monad? Rather they are both superclasses of (say) StrongMonad? (And i guess Applicative can't even be defined unless the category is monoidal?)
    – M Farkas-Dyck
    Dec 27 '18 at 17:24












  • That is my understanding. In particular (<*>) = ap and in a general setting ap :: (Monad m) => m (a -> b) -> m a -> m b requires tensorial strength (more obvious if we uncurry it).
    – Jorge Adriano
    Dec 27 '18 at 17:46














3












3








3







What confuses me is our Monad class seems to have no notion whatsoever of the (closed or monoidal) structure.




If I understood your question correctly, that would be provided via the tensorial strength of the monad. The Monad class doesn't have it because it is intrinsic to the Hask category. More concretely, it is assumed to be:



t :: Monad m => (a, m b) -> m (a,b)
t (x, my) = my >>= y -> return (x,y)





share|improve this answer













What confuses me is our Monad class seems to have no notion whatsoever of the (closed or monoidal) structure.




If I understood your question correctly, that would be provided via the tensorial strength of the monad. The Monad class doesn't have it because it is intrinsic to the Hask category. More concretely, it is assumed to be:



t :: Monad m => (a, m b) -> m (a,b)
t (x, my) = my >>= y -> return (x,y)






share|improve this answer












share|improve this answer



share|improve this answer










answered Dec 27 '18 at 16:54









Jorge Adriano

2,190918




2,190918












  • So in general, Applicative is not a superclass of Monad? Rather they are both superclasses of (say) StrongMonad? (And i guess Applicative can't even be defined unless the category is monoidal?)
    – M Farkas-Dyck
    Dec 27 '18 at 17:24












  • That is my understanding. In particular (<*>) = ap and in a general setting ap :: (Monad m) => m (a -> b) -> m a -> m b requires tensorial strength (more obvious if we uncurry it).
    – Jorge Adriano
    Dec 27 '18 at 17:46


















  • So in general, Applicative is not a superclass of Monad? Rather they are both superclasses of (say) StrongMonad? (And i guess Applicative can't even be defined unless the category is monoidal?)
    – M Farkas-Dyck
    Dec 27 '18 at 17:24












  • That is my understanding. In particular (<*>) = ap and in a general setting ap :: (Monad m) => m (a -> b) -> m a -> m b requires tensorial strength (more obvious if we uncurry it).
    – Jorge Adriano
    Dec 27 '18 at 17:46
















So in general, Applicative is not a superclass of Monad? Rather they are both superclasses of (say) StrongMonad? (And i guess Applicative can't even be defined unless the category is monoidal?)
– M Farkas-Dyck
Dec 27 '18 at 17:24






So in general, Applicative is not a superclass of Monad? Rather they are both superclasses of (say) StrongMonad? (And i guess Applicative can't even be defined unless the category is monoidal?)
– M Farkas-Dyck
Dec 27 '18 at 17:24














That is my understanding. In particular (<*>) = ap and in a general setting ap :: (Monad m) => m (a -> b) -> m a -> m b requires tensorial strength (more obvious if we uncurry it).
– Jorge Adriano
Dec 27 '18 at 17:46




That is my understanding. In particular (<*>) = ap and in a general setting ap :: (Monad m) => m (a -> b) -> m a -> m b requires tensorial strength (more obvious if we uncurry it).
– Jorge Adriano
Dec 27 '18 at 17:46













3














Essentially, all the monoidal stuff involved in the methods of a monoidal functor happens on the target category. It can be formalised thus:



class (Category s, Category t) => Functor s t f where
map :: s a b -> t (f a) (f b)

class Functor s t f => Monoidal s t f where
pureUnit :: t () (f ())
fzip :: t (f a,f b) (f (a,b))


s-morphisms only come in if you consider the laws of a monoidal functor, which roughly say that the monoidal structure of s should be mapped into this monoidal structure of t by the functor.



Perhaps more insightful is to factor an fmap into the class methods, so it's clear what the “func-”-part of the functor does:



class Functor s t f => Monoidal s t f where
...
puref :: s () y -> t () (f y)
puref f = map f . pureUnit
fzipWith :: s (a,b) c -> t (f a,f b) (f c)
fzipWith f = map f . fzip


From Monoidal, we can get back our good old Hask-Applicative thus:



pure :: Monoidal (->) (->) f => a -> f a
pure a = puref (const a) ()

(<*>) :: Monoidal (->) (->) f => f (a->b) -> f a -> f b
fs <*> xs = fzipWith (uncurry ($)) (fs, xs)


or



liftA2 :: Monoidal (->) (->) f => (a->b->c) -> f a -> f b -> f c
liftA2 f xs ys = fzipWith (uncurry f) (xs,ys)


Perhaps more interesting in this context is the other direction, because that shows us up the connection to monads in the generalised case:



instance Applicative f => Monoidal (->) (->) f where
pureUnit = pure
fzip = (xs,ys) -> liftA2 (,) xs ys
= (xs,ys) -> join $ map (x -> map (x,) ys) xs


That lambdas and tuple sections aren't available in a general category, however they can be translated to cartesian closed categories.





I'm using (,) as the product in both monoidal categories, with identity element (). More generally you might write data I_s and data I_t and type family (⊗) x y and type family (∙) x y for the products and their respective identity elements.






share|improve this answer























  • You may well be right, maybe I'm missing something. Looking at the definition of monoidal functor though, the natural transformation Φ: FA ⊗ FB -> F(A⊗B), in the case of an endofunctor, seems to be just the monad's strength no? not as I wrote it but it's pretty straightforward to derive a strength t': TA ⊗ TB -> T (A⊗B) from t: A ⊗ TB -> T (A⊗B). Is it something else I'm missing here?
    – Jorge Adriano
    Dec 27 '18 at 18:19










  • I think it begs the question, to use (,) as the product.
    – M Farkas-Dyck
    Dec 27 '18 at 19:04












  • @MFarkas-Dyck not sure. You definitely need some CCC helpers to connect the monoidal-functor and monad classes, and in any CCC the product will essentially behave as a tuple (even if you don't use Haskell tuples). But, if I'm wrong I'd be excited to see a counterexample.
    – leftaroundabout
    Dec 27 '18 at 19:12
















3














Essentially, all the monoidal stuff involved in the methods of a monoidal functor happens on the target category. It can be formalised thus:



class (Category s, Category t) => Functor s t f where
map :: s a b -> t (f a) (f b)

class Functor s t f => Monoidal s t f where
pureUnit :: t () (f ())
fzip :: t (f a,f b) (f (a,b))


s-morphisms only come in if you consider the laws of a monoidal functor, which roughly say that the monoidal structure of s should be mapped into this monoidal structure of t by the functor.



Perhaps more insightful is to factor an fmap into the class methods, so it's clear what the “func-”-part of the functor does:



class Functor s t f => Monoidal s t f where
...
puref :: s () y -> t () (f y)
puref f = map f . pureUnit
fzipWith :: s (a,b) c -> t (f a,f b) (f c)
fzipWith f = map f . fzip


From Monoidal, we can get back our good old Hask-Applicative thus:



pure :: Monoidal (->) (->) f => a -> f a
pure a = puref (const a) ()

(<*>) :: Monoidal (->) (->) f => f (a->b) -> f a -> f b
fs <*> xs = fzipWith (uncurry ($)) (fs, xs)


or



liftA2 :: Monoidal (->) (->) f => (a->b->c) -> f a -> f b -> f c
liftA2 f xs ys = fzipWith (uncurry f) (xs,ys)


Perhaps more interesting in this context is the other direction, because that shows us up the connection to monads in the generalised case:



instance Applicative f => Monoidal (->) (->) f where
pureUnit = pure
fzip = (xs,ys) -> liftA2 (,) xs ys
= (xs,ys) -> join $ map (x -> map (x,) ys) xs


That lambdas and tuple sections aren't available in a general category, however they can be translated to cartesian closed categories.





I'm using (,) as the product in both monoidal categories, with identity element (). More generally you might write data I_s and data I_t and type family (⊗) x y and type family (∙) x y for the products and their respective identity elements.






share|improve this answer























  • You may well be right, maybe I'm missing something. Looking at the definition of monoidal functor though, the natural transformation Φ: FA ⊗ FB -> F(A⊗B), in the case of an endofunctor, seems to be just the monad's strength no? not as I wrote it but it's pretty straightforward to derive a strength t': TA ⊗ TB -> T (A⊗B) from t: A ⊗ TB -> T (A⊗B). Is it something else I'm missing here?
    – Jorge Adriano
    Dec 27 '18 at 18:19










  • I think it begs the question, to use (,) as the product.
    – M Farkas-Dyck
    Dec 27 '18 at 19:04












  • @MFarkas-Dyck not sure. You definitely need some CCC helpers to connect the monoidal-functor and monad classes, and in any CCC the product will essentially behave as a tuple (even if you don't use Haskell tuples). But, if I'm wrong I'd be excited to see a counterexample.
    – leftaroundabout
    Dec 27 '18 at 19:12














3












3








3






Essentially, all the monoidal stuff involved in the methods of a monoidal functor happens on the target category. It can be formalised thus:



class (Category s, Category t) => Functor s t f where
map :: s a b -> t (f a) (f b)

class Functor s t f => Monoidal s t f where
pureUnit :: t () (f ())
fzip :: t (f a,f b) (f (a,b))


s-morphisms only come in if you consider the laws of a monoidal functor, which roughly say that the monoidal structure of s should be mapped into this monoidal structure of t by the functor.



Perhaps more insightful is to factor an fmap into the class methods, so it's clear what the “func-”-part of the functor does:



class Functor s t f => Monoidal s t f where
...
puref :: s () y -> t () (f y)
puref f = map f . pureUnit
fzipWith :: s (a,b) c -> t (f a,f b) (f c)
fzipWith f = map f . fzip


From Monoidal, we can get back our good old Hask-Applicative thus:



pure :: Monoidal (->) (->) f => a -> f a
pure a = puref (const a) ()

(<*>) :: Monoidal (->) (->) f => f (a->b) -> f a -> f b
fs <*> xs = fzipWith (uncurry ($)) (fs, xs)


or



liftA2 :: Monoidal (->) (->) f => (a->b->c) -> f a -> f b -> f c
liftA2 f xs ys = fzipWith (uncurry f) (xs,ys)


Perhaps more interesting in this context is the other direction, because that shows us up the connection to monads in the generalised case:



instance Applicative f => Monoidal (->) (->) f where
pureUnit = pure
fzip = (xs,ys) -> liftA2 (,) xs ys
= (xs,ys) -> join $ map (x -> map (x,) ys) xs


That lambdas and tuple sections aren't available in a general category, however they can be translated to cartesian closed categories.





I'm using (,) as the product in both monoidal categories, with identity element (). More generally you might write data I_s and data I_t and type family (⊗) x y and type family (∙) x y for the products and their respective identity elements.






share|improve this answer














Essentially, all the monoidal stuff involved in the methods of a monoidal functor happens on the target category. It can be formalised thus:



class (Category s, Category t) => Functor s t f where
map :: s a b -> t (f a) (f b)

class Functor s t f => Monoidal s t f where
pureUnit :: t () (f ())
fzip :: t (f a,f b) (f (a,b))


s-morphisms only come in if you consider the laws of a monoidal functor, which roughly say that the monoidal structure of s should be mapped into this monoidal structure of t by the functor.



Perhaps more insightful is to factor an fmap into the class methods, so it's clear what the “func-”-part of the functor does:



class Functor s t f => Monoidal s t f where
...
puref :: s () y -> t () (f y)
puref f = map f . pureUnit
fzipWith :: s (a,b) c -> t (f a,f b) (f c)
fzipWith f = map f . fzip


From Monoidal, we can get back our good old Hask-Applicative thus:



pure :: Monoidal (->) (->) f => a -> f a
pure a = puref (const a) ()

(<*>) :: Monoidal (->) (->) f => f (a->b) -> f a -> f b
fs <*> xs = fzipWith (uncurry ($)) (fs, xs)


or



liftA2 :: Monoidal (->) (->) f => (a->b->c) -> f a -> f b -> f c
liftA2 f xs ys = fzipWith (uncurry f) (xs,ys)


Perhaps more interesting in this context is the other direction, because that shows us up the connection to monads in the generalised case:



instance Applicative f => Monoidal (->) (->) f where
pureUnit = pure
fzip = (xs,ys) -> liftA2 (,) xs ys
= (xs,ys) -> join $ map (x -> map (x,) ys) xs


That lambdas and tuple sections aren't available in a general category, however they can be translated to cartesian closed categories.





I'm using (,) as the product in both monoidal categories, with identity element (). More generally you might write data I_s and data I_t and type family (⊗) x y and type family (∙) x y for the products and their respective identity elements.







share|improve this answer














share|improve this answer



share|improve this answer








edited Dec 27 '18 at 18:43

























answered Dec 27 '18 at 17:14









leftaroundabout

78.9k3117233




78.9k3117233












  • You may well be right, maybe I'm missing something. Looking at the definition of monoidal functor though, the natural transformation Φ: FA ⊗ FB -> F(A⊗B), in the case of an endofunctor, seems to be just the monad's strength no? not as I wrote it but it's pretty straightforward to derive a strength t': TA ⊗ TB -> T (A⊗B) from t: A ⊗ TB -> T (A⊗B). Is it something else I'm missing here?
    – Jorge Adriano
    Dec 27 '18 at 18:19










  • I think it begs the question, to use (,) as the product.
    – M Farkas-Dyck
    Dec 27 '18 at 19:04












  • @MFarkas-Dyck not sure. You definitely need some CCC helpers to connect the monoidal-functor and monad classes, and in any CCC the product will essentially behave as a tuple (even if you don't use Haskell tuples). But, if I'm wrong I'd be excited to see a counterexample.
    – leftaroundabout
    Dec 27 '18 at 19:12


















  • You may well be right, maybe I'm missing something. Looking at the definition of monoidal functor though, the natural transformation Φ: FA ⊗ FB -> F(A⊗B), in the case of an endofunctor, seems to be just the monad's strength no? not as I wrote it but it's pretty straightforward to derive a strength t': TA ⊗ TB -> T (A⊗B) from t: A ⊗ TB -> T (A⊗B). Is it something else I'm missing here?
    – Jorge Adriano
    Dec 27 '18 at 18:19










  • I think it begs the question, to use (,) as the product.
    – M Farkas-Dyck
    Dec 27 '18 at 19:04












  • @MFarkas-Dyck not sure. You definitely need some CCC helpers to connect the monoidal-functor and monad classes, and in any CCC the product will essentially behave as a tuple (even if you don't use Haskell tuples). But, if I'm wrong I'd be excited to see a counterexample.
    – leftaroundabout
    Dec 27 '18 at 19:12
















You may well be right, maybe I'm missing something. Looking at the definition of monoidal functor though, the natural transformation Φ: FA ⊗ FB -> F(A⊗B), in the case of an endofunctor, seems to be just the monad's strength no? not as I wrote it but it's pretty straightforward to derive a strength t': TA ⊗ TB -> T (A⊗B) from t: A ⊗ TB -> T (A⊗B). Is it something else I'm missing here?
– Jorge Adriano
Dec 27 '18 at 18:19




You may well be right, maybe I'm missing something. Looking at the definition of monoidal functor though, the natural transformation Φ: FA ⊗ FB -> F(A⊗B), in the case of an endofunctor, seems to be just the monad's strength no? not as I wrote it but it's pretty straightforward to derive a strength t': TA ⊗ TB -> T (A⊗B) from t: A ⊗ TB -> T (A⊗B). Is it something else I'm missing here?
– Jorge Adriano
Dec 27 '18 at 18:19












I think it begs the question, to use (,) as the product.
– M Farkas-Dyck
Dec 27 '18 at 19:04






I think it begs the question, to use (,) as the product.
– M Farkas-Dyck
Dec 27 '18 at 19:04














@MFarkas-Dyck not sure. You definitely need some CCC helpers to connect the monoidal-functor and monad classes, and in any CCC the product will essentially behave as a tuple (even if you don't use Haskell tuples). But, if I'm wrong I'd be excited to see a counterexample.
– leftaroundabout
Dec 27 '18 at 19:12




@MFarkas-Dyck not sure. You definitely need some CCC helpers to connect the monoidal-functor and monad classes, and in any CCC the product will essentially behave as a tuple (even if you don't use Haskell tuples). But, if I'm wrong I'd be excited to see a counterexample.
– leftaroundabout
Dec 27 '18 at 19:12


















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53948171%2fevery-monad-is-an-applicative-functor-generalizing-to-other-categories%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Xb79a 3lmdKGpRmZ ETJiotKu,dFctJc ViN,b wda3v,Te6qz,hVq 62c eC2kN6to19vzEGlG MT vzm NQ5ZJ
vHjYOERK 6PoifYkdSy5698jYSQ3 vcAGR,YPUkOj 4s1,iatvW,YmQRhXt2cEXq2 m

Popular posts from this blog

Monofisismo

Angular Downloading a file using contenturl with Basic Authentication

Olmecas