Are all monads functions?

Hello Café, One thought occur to me recently when explaining the concept of Monad to non-haskellers: internally, all standard Monads are newtypes wrapping functions: StateT is, WriterT is, ContT is. Even IO and ST are, both conceptually and in their implementation by GHC. ParsecT (not part of mtl, but still) is. And so on... So I'm saying that most of the time, we define a new monad: - either by building a monad stack of existing transformers (thus "melting" their internal functions), - or by creating a newtype containing a custom function. Thinking thusly, >>= would then just be a special function composition operator: in the spirit of '.' but for a specific type of functions. So my questions are: - Is it reasonable to think like that, or are there too many monads that cannot be defined like that, and then contradict me? - Is it reasonable to present monads to newcomers by saying : monads are basically always functions. 'return x' will then be a function that always return 'x' regardless of its input and >>= is a special composition for this occasion. -- The ⊥ is a lie.

Maybe and [] have still the same meaning: they can be seen as functions:
- they represent the result(s) that might or might not have a computation
- *they have to be called/ran/executed* (wichever term you prefer) through
Data.Maybe.maybe or Data.List.foldX, so that we can extract some value out
of them.
It's just that their input is () (void). But in Haskell, the type:
() -> Maybe a
is useless, Maybe a is sufficient.
Maybe in that case "procedure" is then a better term than function.
2011/12/31 Jerzy Karczmarczuk
Yves Parès :
all standard Monads are newtypes wrapping functions
What about Maybe and [] ?
Jerzy Karczmarczuk
______________________________**_________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe

* Yves Parès
One thought occur to me recently when explaining the concept of Monad to non-haskellers: internally, all standard Monads are newtypes wrapping functions: StateT is, WriterT is, ContT is. Even IO and ST are, both conceptually and in their implementation by GHC. ParsecT (not part of mtl, but still) is. And so on...
Writer(T) is not a function, it's just a tuple. Jerzy already mentioned [] and Maybe. Another example is a free monad generated by any polynomial functor. This subsumes Maybe and (almost) [], as described here: http://blog.omega-prime.co.uk/?p=34 To summarise, since there are only so many ways to form types in Haskell (sum, product and exponentiation (functions)), it's no surprise that functions do occur often, but that's not something fundamental to monads. -- Roman I. Cheplyaka :: http://ro-che.info/

Thanks for the explanation on free monads, it's interesting.
But still, I maintain my previous view. I could clarify that by saying that
(e.g. for Maybe) we could separate it in two types, Maybe itself and its
monad:
-- The plain Maybe type
data Maybe a = Just a | Nothing
-- The MaybeMonad
newtype MaybeMonad a = MM ( () -> Maybe a )
That's what using Maybe as a monad semantically means, doesn't it?
It's just that as I said before, the function () -> Maybe a is useless,
thus making the whole type MaybeMonad entirely equivalent to Maybe.
So Roman, as I understand it, a free monad can only be a stateless monad.
So *again*, FreeM is equivalent to :
data FreeM f a = Return a
| Bind (* () ->* f (FreeM f a) )
You cannot express StateT for instance with a functor and FreeM, can you?
But if you change FreeM to be:
data FreeM f s a = Return a
| Bind (* s ->* f (FreeM f a) )
Then maybe it becomes possible...
2011/12/31 Roman Cheplyaka
* Yves Parès
[2011-12-31 13:09:37+0100] One thought occur to me recently when explaining the concept of Monad to non-haskellers: internally, all standard Monads are newtypes wrapping functions: StateT is, WriterT is, ContT is. Even IO and ST are, both conceptually and in their implementation by GHC. ParsecT (not part of mtl, but still) is. And so on...
Writer(T) is not a function, it's just a tuple.
Jerzy already mentioned [] and Maybe.
Another example is a free monad generated by any polynomial functor. This subsumes Maybe and (almost) [], as described here: http://blog.omega-prime.coRoman.uk/?p=34http://blog.omega-prime.co.uk/?p=34
To summarise, since there are only so many ways to form types in Haskell (sum, product and exponentiation (functions)), it's no surprise that functions do occur often, but that's not something fundamental to monads.
-- Roman I. Cheplyaka :: http://ro-che.info/
-- The ⊥ is a lie.

On Dec 31, 2011 8:19 AM, "Yves Parès"
-- The plain Maybe type data Maybe a = Just a | Nothing
-- The MaybeMonad newtype MaybeMonad a = MM ( () -> Maybe a )
That's what using Maybe as a monad semantically means, doesn't it?
I'd have to say no. That Maybe types are isomorphic to functions from () is not related to their being monads... indeed it's true of all types. I'm not sure what meaning you see in the function, but I don't see anything of monads in it.

On 31/12/2011 13:18, Yves Parès wrote:
But still, I maintain my previous view. I could clarify that by saying that (e.g. for Maybe) we could separate it in two types, Maybe itself and its monad:
-- The plain Maybe type data Maybe a = Just a | Nothing
-- The MaybeMonad newtype MaybeMonad a = MM ( () -> Maybe a )
You've just reminded me of a painful time - lot's a scratching my head and saying "but these parser functions are monadic - the tutorial clearly says they're monadic - why does my every attempt at making the type an instance of Monad fail?" Answer - I only had the equivalent of the Maybe type, and I was trying to force it where the MaybeMonad should go.

Yves Parès
But still, I maintain my previous view. I could clarify that by saying that (e.g. for Maybe) we could separate it in two types, Maybe itself and its monad:
-- The plain Maybe type data Maybe a = Just a | Nothing
-- The MaybeMonad newtype MaybeMonad a = MM ( () -> Maybe a )
That's what using Maybe as a monad semantically means, doesn't it?
That's a statement like "the sky is blue". You can represent any value as a function of (). You are saying that every integer is a function. newtype MyInt = MyInt (() -> Int) newtype My a = My (() -> a) Think of it this way: There is something like a canonical representation of every monad. If you let that one be the one with the least order (which is reasonable), then no, not every monad's canonical representation is a function, because the base library definition of Maybe is the canonical one (order zero). In that sense every value in maths is a function. In other words: Your extension of everything (!) to functions is redundant. You get the idea. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/

In that sense every value in maths is a function. In other words: Your extension of everything (!) to functions is redundant.
And function is not unique in this way. All types can be embedded into
pairs also, e.g., newtype MyInt = MyInt ((),Int), or newtype MyInt = MyInt
(((),Int),()), etc.
- Conal
2011/12/31 Ertugrul Söylemez
Yves Parès
wrote: But still, I maintain my previous view. I could clarify that by saying that (e.g. for Maybe) we could separate it in two types, Maybe itself and its monad:
-- The plain Maybe type data Maybe a = Just a | Nothing
-- The MaybeMonad newtype MaybeMonad a = MM ( () -> Maybe a )
That's what using Maybe as a monad semantically means, doesn't it?
That's a statement like "the sky is blue". You can represent any value as a function of (). You are saying that every integer is a function.
newtype MyInt = MyInt (() -> Int) newtype My a = My (() -> a)
Think of it this way: There is something like a canonical representation of every monad. If you let that one be the one with the least order (which is reasonable), then no, not every monad's canonical representation is a function, because the base library definition of Maybe is the canonical one (order zero).
In that sense every value in maths is a function. In other words: Your extension of everything (!) to functions is redundant.
You get the idea.
Greets, Ertugrul

On 12/31/11 8:18 AM, Yves Parès wrote:
Thanks for the explanation on free monads, it's interesting.
But still, I maintain my previous view. I could clarify that by saying that (e.g. for Maybe) we could separate it in two types, Maybe itself and its monad:
-- The plain Maybe type data Maybe a = Just a | Nothing
-- The MaybeMonad newtype MaybeMonad a = MM ( () -> Maybe a )
That's what using Maybe as a monad semantically means, doesn't it?
Well, to take the category-theoretic perspective, a "value" or "element" of X is simply defined to be any morphism from the terminal object into X. Thus, saying "x \in X" or "x :: X" is just another way to say x : 1 -> X. The unit type isn't quite terminal because it has two values, but it's close enough to get the idea. If unit truly had only one value, then ()->Y is at least (isomorphic to) a subobject of Y, and almost surely isomorphic to (all of) Y. All of this is just by the definition of what a terminal object is; nothing about monads anywhere. Also note that (X ->) forms a monad for any X. But that's a separate issue. -- Live well, ~wren
participants (10)
-
Chris Smith
-
Conal Elliott
-
Ertugrul Söylemez
-
Jerzy Karczmarczuk
-
Roman Cheplyaka
-
Stephen Tetley
-
Steve Horne
-
wren ng thornton
-
Yves Parès
-
Yves Parès