Every monad is an applicative functor — generalizing to other categories

Multi tool use
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
add a comment |
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
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
add a comment |
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
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
haskell category functor applicative category-theory
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
add a comment |
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
add a comment |
2 Answers
2
active
oldest
votes
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)
So in general,Applicative
is not a superclass ofMonad
? Rather they are both superclasses of (say)StrongMonad
? (And i guessApplicative
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 settingap :: (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
add a comment |
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.
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 strengtht': TA ⊗ TB -> T (A⊗B)
fromt: 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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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)
So in general,Applicative
is not a superclass ofMonad
? Rather they are both superclasses of (say)StrongMonad
? (And i guessApplicative
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 settingap :: (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
add a comment |
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)
So in general,Applicative
is not a superclass ofMonad
? Rather they are both superclasses of (say)StrongMonad
? (And i guessApplicative
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 settingap :: (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
add a comment |
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)
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)
answered Dec 27 '18 at 16:54
Jorge Adriano
2,190918
2,190918
So in general,Applicative
is not a superclass ofMonad
? Rather they are both superclasses of (say)StrongMonad
? (And i guessApplicative
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 settingap :: (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
add a comment |
So in general,Applicative
is not a superclass ofMonad
? Rather they are both superclasses of (say)StrongMonad
? (And i guessApplicative
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 settingap :: (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
add a comment |
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.
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 strengtht': TA ⊗ TB -> T (A⊗B)
fromt: 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
add a comment |
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.
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 strengtht': TA ⊗ TB -> T (A⊗B)
fromt: 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
add a comment |
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.
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.
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 strengtht': TA ⊗ TB -> T (A⊗B)
fromt: 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
add a comment |
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 strengtht': TA ⊗ TB -> T (A⊗B)
fromt: 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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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