https://wiki.haskell.org/api.php?action=feedcontributions&user=Ksf&feedformat=atomHaskellWiki - User contributions [en]2023-10-01T12:58:54ZUser contributionsMediaWiki 1.35.5https://wiki.haskell.org/index.php?title=What_a_Monad_is_not&diff=63510What a Monad is not2020-12-02T16:45:35Z<p>Ksf: /* Warning */ Reverted "warm and fuzzy" link to archive version of the original. It's really really hand-holdy that's why I chose it. The other one is still nice and crisp for the more math-inclined mind.</p>
<hr />
<div>==Warning==<br />
Don't be surprised if you leave this page more confused than before. That just means that it has successfully destroyed your false assumptions, or that you've fallen for some horrible inside joke. Beware of [[Zygohistomorphic prepromorphisms]]. Go for [https://web.archive.org/web/20120114225257/http://ertes.de/articles/monads.html warm and fuzzy], instead. Or [http://en.wikibooks.org/wiki/Haskell/Understanding_monads this one].<br />
<br />
==Monads are not a good choice as topic for your first Haskell blog entry==<br />
...just accept that they're [http://blog.plover.com/prog/burritos.html burritos], and wait until later.<br />
<br />
==Monads are not a language feature==<br />
Really. They are defined in terms of Haskell, not Haskell in terms of them. Conversely,<br />
<br />
==Haskell doesn't need Monads==<br />
...well, apart from the current Haskell standard defining the way IO is done in terms of Monads: [http://donsbot.wordpress.com/2009/01/31/reviving-the-gofer-standard-prelude-circa-1994/ It could be done differently and still work].<br />
<br />
==Monads are not impure==<br />
...In no way whatsoever. You don't even need flexible morals to claim it. To be more specific, it's IO that's impure. That makes the IO monad impure. But that's not a general property of monads - just IO. And even then, we can pretend that Haskell is a purely functional description language for imperative programs. But we didn't want to employ flexible morals, now did we?<br />
<br />
==Monads are not about state==<br />
While it is certainly possible to abstract away explicit state passing by using a Monad, that's not what a monad is. Some examples for monads that are not about state: Identity monad, Reader monad, List monad, Continuation monad, Exception monad.<br />
<br />
==Monads are not about strictness==<br />
Monad operations (bind and return) have to be [[Non-strict semantics|non-strict]] in fact, always! However<br />
other operations can be specific to each monad.<br />
For instance some are strict (like IO), and some are non-strict (like []). Then there are some that come in multiple flavours, like State.<br />
<br />
Try the following:<br />
<br />
<haskell><br />
runState (sequence . repeat $ state (\x -> (x,x+1))) 0<br />
</haskell><br />
<br />
Having a look at the implementation of fixIO might be helpful, too.<br />
<br />
==Monads are not values==<br />
This point might be driven home best by pointing out that instance Monad Foo where ... is not a data type, but a declaration of a typeclass instance. However, to elaborate:<br />
<br />
Monads are not values in the same sense that addition and multiplication are not numbers: They capture a -- very specific -- relationship between values of a specific domain into a common abstraction. We're going to call these values monads manage ''mobits'', somewhat like this:<br />
<br />
<haskell><br />
type Mobit m a = Monad m => m a<br />
</haskell><br />
<br />
The IO monad manages mobits representing side-effects ("IO actions").<br />
<br />
The List monad manages mobits representing multiple values ("[a]")<br />
<br />
The Reader monads manages mobits that are pure computations that use asks to propagate information instead of explicit arguments<br />
<br />
...and while addition and multiplication are both monoids over the positive natural numbers, a monad is a monoid object in a category of endofunctors: return is the unit, and join is the binary operation. It couldn't be more simple. If that confuses you, it might be helpful to see a Monad as a lax functor from a terminal bicategory.<br />
<br />
==Monads are not a replacement for applicative functors==<br />
Instead, every monad ''is'' an applicative functor (as well as a functor). It is considered good practice not to use >>= if all you need is <*>, or even fmap.<br />
<br />
Not confusing which features of monads are specific to monads only and which stem from applicative functors is vitally important for a deeper understanding of monads. As an example, the applicative functor interface of parser libraries can parse context-free languages (modulo hacks abusing open recursion), while the monadic interface can parse context-sensitive grammars: Monads allow you to influence further processing by inspecting the result of your parse. To understand why, have a look at the type of >>=. To understand why applicative functors by themselves are sufficient to track the current parsing position and express sequencing, have a look at the [http://www.cs.uu.nl/research/techreps/repo/CS-2008/2008-044.pdf uu-parsinglib tutorial (pdf)].<br />
<br />
The exact differences are elaborated in even greater detail in Brent Yorgey's excellent [[Typeclassopedia]].<br />
<br />
==Monads are not about ordering/sequencing==<br />
Monads are commonly used to order sequences of computations. But this is misleading. Just as you can use monads for state, or strictness, you can use them to order computations. But there are also commutative monads, like Reader, that don't order anything. So ordering is not in any way essential to what a monad is.<br />
<br />
Let's have a look at what's meant by ordering. Consider an expression like<br />
<br />
<haskell><br />
let x = a<br />
y = b<br />
in f x y<br />
</haskell><br />
<br />
That gives the same result as<br />
<br />
<haskell><br />
let y = b<br />
x = a<br />
in f x y<br />
</haskell><br />
<br />
It doesn't matter what order we write the two bindings. But for doing I/O we'd like ordering. Monads allow us to express<br />
<br />
<haskell><br />
do<br />
x <- getChar<br />
y <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
and have it be different from<br />
<br />
<haskell><br />
do<br />
y <- getChar<br />
x <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
Unlike the first, the second example returns a pair of characters in the opposite order to which they were entered.<br />
<br />
It might help to meditate about the difference between 'assignment' and 'binding', right now.<br />
<br />
However, just to spoil the enlightenment you just attained, there are monads for which swapping the order of lines like this makes no difference: For example, the Reader monad.<br />
<br />
So while it is correct to say that monads can be used to order operations, it would be wrong to say that monads are a mechanism for ordering operations.<br />
<br />
This notion of commutativity looks superficially very different from the familiar one in vanilla algebra where a+b=b+a. It doesn't mean that<br />
<haskell><br />
m >> n === n >> m<br />
</haskell><br />
which doesn't hold in general for ''any'' non-trivial monad, as for the most part<br />
<haskell><br />
return 1 >> return 2 === return 2 =/= return 1 === return 2 >> return 1<br />
</haskell><br />
<br />
This shouldn't be too surprising, though, as >> isn't the binary operation of a monoid. The [http://ncatlab.org/nlab/show/commutative+algebraic+theory category-theoretic definition] of a commutative monad is rather more abstract.<br />
<br />
==See also==<br />
<br />
* [[Do notation considered harmful]]<br />
<br />
[[Category:FAQ]]<br />
[[Category:Monad]]</div>Ksfhttps://wiki.haskell.org/index.php?title=What_a_Monad_is_not&diff=55878What a Monad is not2013-05-08T15:22:39Z<p>Ksf: /* Haskell doesn't need Monads */</p>
<hr />
<div>==Warning==<br />
Don't be surprised if you leave this page more confused than before. That just means that it has successfully destroyed your false assumptions, or that you've fallen for some horrible inside joke. Beware of [[Zygohistomorphic prepromorphisms]]. Go for [http://ertes.de/articles/monads.html warm and fuzzy], instead.<br />
<br />
==Monads are not a good choice as topic for your first Haskell blog entry==<br />
...just accept that they're [http://blog.plover.com/prog/burritos.html burritos], and wait until later.<br />
<br />
==Monads are not a language feature==<br />
Really. They are defined in terms of Haskell, not Haskell in terms of them. Conversely,<br />
<br />
==Haskell doesn't need Monads==<br />
...well, apart from the current Haskell standard defining the way IO is done in terms of Monads: [http://donsbot.wordpress.com/2009/01/31/reviving-the-gofer-standard-prelude-circa-1994/ It could be done differently and still work].<br />
<br />
==Monads are not impure==<br />
...In no way whatsoever. You don't even need flexible morals to claim it. To be more specific, it's IO that's impure. That makes the IO monad impure. But that's not a general property of monads - just IO. And even then, we can pretend that Haskell is a purely functional description language for imperative programs. But we didn't want to employ flexible morals, now did we?<br />
<br />
==Monads are not about state==<br />
While it is certainly possible to abstract away explicit state passing by using a Monad, that's not what a monad is. Some examples for monads that are not about state: Identity monad, Reader monad, List monad, Continuation monad, Exception monad.<br />
<br />
==Monads are not about strictness==<br />
Monad operations (bind and return) have to be [[Non-strict semantics|non-strict]] in fact, always! However<br />
other operations can be specific to each monad.<br />
For instance some are strict (like IO), and some are non-strict (like []). Then there are some that come in multiple flavours, like State.<br />
<br />
Try the following:<br />
<br />
<haskell><br />
runState (sequence . repeat $ state (\x -> (x,x+1))) 0<br />
</haskell><br />
<br />
Having a look at the implementation of fixIO might be helpful, too.<br />
<br />
==Monads are not values==<br />
This point might be driven home best by pointing out that instance Monad Foo where ... is not a data type, but a declaration of a typeclass instance. However, to elaborate:<br />
<br />
Monads are not values in the same sense that addition and multiplication are not numbers: They capture a -- very specific -- relationship between values of a specific domain into a common abstraction. We're going to call these values monads manage ''mobits'', somewhat like this:<br />
<br />
<haskell><br />
type Mobit m a = Monad m => m a<br />
</haskell><br />
<br />
The IO monad manages mobits representing side-effects ("IO actions").<br />
<br />
The List monad manages mobits representing multiple values ("[a]")<br />
<br />
The Reader monads manages mobits that are pure computations that use asks to propagate information instead of explicit arguments<br />
<br />
...and while addition and multiplication are both monoids over the positive natural numbers, a monad is a monoid object in a category of endofunctors: return is the unit, and join is the binary operation. It couldn't be more simple. If that confuses you, it might be helpful to see a Monad as a lax functor from a terminal bicategory.<br />
<br />
==Monads are not a replacement for applicative functors==<br />
Instead, every monad ''is'' an applicative functor (as well as a functor). It is considered good practice not to use >>= if all you need is <*>, or even fmap.<br />
<br />
Not confusing which features of monads are specific to monads only and which stem from applicative functors is vitally important for a deeper understanding of monads. As an example, the applicative functor interface of parser libraries can parse context-free languages (modulo hacks abusing open recursion), while the monadic interface can parse context-sensitive grammars: Monads allow you to influence further processing by inspecting the result of your parse. To understand why, have a look at the type of >>=. To understand why applicative functors by themselves are sufficient to track the current parsing position and express sequencing, have a look at the [http://www.cs.uu.nl/research/techreps/repo/CS-2008/2008-044.pdf uu-parsinglib tutorial (pdf)].<br />
<br />
The exact differences are elaborated in even greater detail in Brent Yorgey's excellent [[Typeclassopedia]].<br />
<br />
==Monads are not about ordering/sequencing==<br />
Monads are commonly used to order sequences of computations. But this is misleading. Just as you can use monads for state, or strictness, you can use them to order computations. But there are also commutative monads, like Maybe, that don't order anything. So ordering is not in any way essential to what a monad is.<br />
<br />
Let's have a look at what's meant by ordering. Consider an expression like<br />
<br />
<haskell><br />
let x = a<br />
y = b<br />
in f x y<br />
</haskell><br />
<br />
That gives the same result as<br />
<br />
<haskell><br />
let y = b<br />
x = a<br />
in f x y<br />
</haskell><br />
<br />
It doesn't matter what order we write the two bindings. But for doing I/O we'd like ordering. Monads allow us to express<br />
<br />
<haskell><br />
do<br />
x <- getChar<br />
y <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
and have it be different from<br />
<br />
<haskell><br />
do<br />
y <- getChar<br />
x <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
Unlike the first, the second example returns a pair of characters in the opposite order to which they were entered.<br />
<br />
It might help to meditate about the difference between 'assignment' and 'binding', right now.<br />
<br />
However, just to spoil the enlightenment you just attained, there are monads for which swapping the order of lines like this makes no difference: For example, the Maybe monad.<br />
<br />
So while it is correct to say that monads can be used to order operations, it would be wrong to say that monads are a mechanism for ordering operations.<br />
<br />
This notion of commutativity looks superficially very different from the familiar one in vanilla algebra where a+b=b+a. It's not about the fact that<br />
<br />
<haskell><br />
(Just 2 >> Just 3) == Just 3<br />
</haskell><br />
, implying <br />
<haskell><br />
(Just 2 >> Just 3) /= (Just 3 >> Just 2)<br />
</haskell><br />
<br />
This shouldn't be too surprising, though, as >> isn't the binary operation of some monoid: the algebraic properties of '''''join''''' are very close to those of + and incidentally, '''''join''''' is also the operation true category theorists tend to work with. They also know of bind, but don't use it a lot because, unlike programmers, they don't do any actual productive work.<br />
<br />
==See also==<br />
<br />
* [[Do notation considered harmful]]<br />
<br />
[[Category:FAQ]]</div>Ksfhttps://wiki.haskell.org/index.php?title=What_a_Monad_is_not&diff=55726What a Monad is not2013-04-20T01:59:22Z<p>Ksf: /* Monads are not a replacement for applicative functors */</p>
<hr />
<div>==Warning==<br />
Don't be surprised if you leave this page more confused than before. That just means that it has successfully destroyed your false assumptions, or that you've fallen for some horrible inside joke. Beware of [[Zygohistomorphic prepromorphisms]]. Go for [http://ertes.de/articles/monads.html warm and fuzzy], instead.<br />
<br />
==Monads are not a good choice as topic for your first Haskell blog entry==<br />
...just accept that they're [http://blog.plover.com/prog/burritos.html burritos], and wait until later.<br />
<br />
==Monads are not a language feature==<br />
Really. They are defined in terms of Haskell, not Haskell in terms of them. Conversely,<br />
<br />
==Haskell doesn't need Monads==<br />
...well, apart from the current Haskell standard defining the way IO is done in terms of Monads: It could be done differently and still work.<br />
<br />
==Monads are not impure==<br />
...In no way whatsoever. You don't even need flexible morals to claim it. To be more specific, it's IO that's impure. That makes the IO monad impure. But that's not a general property of monads - just IO. And even then, we can pretend that Haskell is a purely functional description language for imperative programs. But we didn't want to employ flexible morals, now did we?<br />
<br />
==Monads are not about state==<br />
While it is certainly possible to abstract away explicit state passing by using a Monad, that's not what a monad is. Some examples for monads that are not about state: Identity monad, Reader monad, List monad, Continuation monad, Exception monad.<br />
<br />
==Monads are not about strictness==<br />
Monad operations (bind and return) have to be [[Non-strict semantics|non-strict]] in fact, always! However<br />
other operations can be specific to each monad.<br />
For instance some are strict (like IO), and some are non-strict (like []). Then there are some that come in multiple flavours, like State.<br />
<br />
Try the following:<br />
<br />
<haskell><br />
runState (sequence . repeat $ state (\x -> (x,x+1))) 0<br />
</haskell><br />
<br />
Having a look at the implementation of fixIO might be helpful, too.<br />
<br />
==Monads are not values==<br />
This point might be driven home best by pointing out that instance Monad Foo where ... is not a data type, but a declaration of a typeclass instance. However, to elaborate:<br />
<br />
Monads are not values in the same sense that addition and multiplication are not numbers: They capture a -- very specific -- relationship between values of a specific domain into a common abstraction. We're going to call these values monads manage ''mobits'', somewhat like this:<br />
<br />
<haskell><br />
type Mobit m a = Monad m => m a<br />
</haskell><br />
<br />
The IO monad manages mobits representing side-effects ("IO actions").<br />
<br />
The List monad manages mobits representing multiple values ("[a]")<br />
<br />
The Reader monads manages mobits that are pure computations that use asks to propagate information instead of explicit arguments<br />
<br />
...and while addition and multiplication are both monoids over the positive natural numbers, a monad is a monoid object in a category of endofunctors: return is the unit, and join is the binary operation. It couldn't be more simple. If that confuses you, it might be helpful to see a Monad as a lax functor from a terminal bicategory.<br />
<br />
==Monads are not a replacement for applicative functors==<br />
Instead, every monad ''is'' an applicative functor (as well as a functor). It is considered good practice not to use >>= if all you need is <*>, or even fmap.<br />
<br />
Not confusing which features of monads are specific to monads only and which stem from applicative functors is vitally important for a deeper understanding of monads. As an example, the applicative functor interface of parser libraries can parse context-free languages (modulo hacks abusing open recursion), while the monadic interface can parse context-sensitive grammars: Monads allow you to influence further processing by inspecting the result of your parse. To understand why, have a look at the type of >>=. To understand why applicative functors by themselves are sufficient to track the current parsing position and express sequencing, have a look at the [http://www.cs.uu.nl/research/techreps/repo/CS-2008/2008-044.pdf uu-parsinglib tutorial (pdf)].<br />
<br />
The exact differences are elaborated in even greater detail in Brent Yorgey's excellent [[Typeclassopedia]].<br />
<br />
==Monads are not about ordering/sequencing==<br />
Monads are commonly used to order sequences of computations. But this is misleading. Just as you can use monads for state, or strictness, you can use them to order computations. But there are also commutative monads, like Maybe, that don't order anything. So ordering is not in any way essential to what a monad is.<br />
<br />
Let's have a look at what's meant by ordering. Consider an expression like<br />
<br />
<haskell><br />
let x = a<br />
y = b<br />
in f x y<br />
</haskell><br />
<br />
That gives the same result as<br />
<br />
<haskell><br />
let y = b<br />
x = a<br />
in f x y<br />
</haskell><br />
<br />
It doesn't matter what order we write the two bindings. But for doing I/O we'd like ordering. Monads allow us to express<br />
<br />
<haskell><br />
do<br />
x <- getChar<br />
y <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
and have it be different from<br />
<br />
<haskell><br />
do<br />
y <- getChar<br />
x <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
Unlike the first, the second example returns a pair of characters in the opposite order to which they were entered.<br />
<br />
It might help to meditate about the difference between 'assignment' and 'binding', right now.<br />
<br />
However, just to spoil the enlightenment you just attained, there are monads for which swapping the order of lines like this makes no difference: For example, the Maybe monad.<br />
<br />
So while it is correct to say that monads can be used to order operations, it would be wrong to say that monads are a mechanism for ordering operations.<br />
<br />
This notion of commutativity looks superficially very different from the familiar one in vanilla algebra where a+b=b+a. It's not about the fact that<br />
<br />
<haskell><br />
(Just 2 >> Just 3) == Just 3<br />
</haskell><br />
, implying <br />
<haskell><br />
(Just 2 >> Just 3) /= (Just 3 >> Just 2)<br />
</haskell><br />
<br />
This shouldn't be too surprising, though, as >> isn't the binary operation of some monoid: the algebraic properties of '''''join''''' are very close to those of + and incidentally, '''''join''''' is also the operation true category theorists tend to work with. They also know of bind, but don't use it a lot because, unlike programmers, they don't do any actual productive work.<br />
<br />
==See also==<br />
<br />
* [[Do notation considered harmful]]<br />
<br />
[[Category:FAQ]]</div>Ksfhttps://wiki.haskell.org/index.php?title=What_a_Monad_is_not&diff=55725What a Monad is not2013-04-20T01:57:06Z<p>Ksf: /* Monads are not values */</p>
<hr />
<div>==Warning==<br />
Don't be surprised if you leave this page more confused than before. That just means that it has successfully destroyed your false assumptions, or that you've fallen for some horrible inside joke. Beware of [[Zygohistomorphic prepromorphisms]]. Go for [http://ertes.de/articles/monads.html warm and fuzzy], instead.<br />
<br />
==Monads are not a good choice as topic for your first Haskell blog entry==<br />
...just accept that they're [http://blog.plover.com/prog/burritos.html burritos], and wait until later.<br />
<br />
==Monads are not a language feature==<br />
Really. They are defined in terms of Haskell, not Haskell in terms of them. Conversely,<br />
<br />
==Haskell doesn't need Monads==<br />
...well, apart from the current Haskell standard defining the way IO is done in terms of Monads: It could be done differently and still work.<br />
<br />
==Monads are not impure==<br />
...In no way whatsoever. You don't even need flexible morals to claim it. To be more specific, it's IO that's impure. That makes the IO monad impure. But that's not a general property of monads - just IO. And even then, we can pretend that Haskell is a purely functional description language for imperative programs. But we didn't want to employ flexible morals, now did we?<br />
<br />
==Monads are not about state==<br />
While it is certainly possible to abstract away explicit state passing by using a Monad, that's not what a monad is. Some examples for monads that are not about state: Identity monad, Reader monad, List monad, Continuation monad, Exception monad.<br />
<br />
==Monads are not about strictness==<br />
Monad operations (bind and return) have to be [[Non-strict semantics|non-strict]] in fact, always! However<br />
other operations can be specific to each monad.<br />
For instance some are strict (like IO), and some are non-strict (like []). Then there are some that come in multiple flavours, like State.<br />
<br />
Try the following:<br />
<br />
<haskell><br />
runState (sequence . repeat $ state (\x -> (x,x+1))) 0<br />
</haskell><br />
<br />
Having a look at the implementation of fixIO might be helpful, too.<br />
<br />
==Monads are not values==<br />
This point might be driven home best by pointing out that instance Monad Foo where ... is not a data type, but a declaration of a typeclass instance. However, to elaborate:<br />
<br />
Monads are not values in the same sense that addition and multiplication are not numbers: They capture a -- very specific -- relationship between values of a specific domain into a common abstraction. We're going to call these values monads manage ''mobits'', somewhat like this:<br />
<br />
<haskell><br />
type Mobit m a = Monad m => m a<br />
</haskell><br />
<br />
The IO monad manages mobits representing side-effects ("IO actions").<br />
<br />
The List monad manages mobits representing multiple values ("[a]")<br />
<br />
The Reader monads manages mobits that are pure computations that use asks to propagate information instead of explicit arguments<br />
<br />
...and while addition and multiplication are both monoids over the positive natural numbers, a monad is a monoid object in a category of endofunctors: return is the unit, and join is the binary operation. It couldn't be more simple. If that confuses you, it might be helpful to see a Monad as a lax functor from a terminal bicategory.<br />
<br />
==Monads are not a replacement for applicative functors==<br />
Instead, every monad ''is'' an applicative functor (as well as a functor). It is considered good practice not to use >>= if all you need is <*>, or even fmap.<br />
<br />
Not confusing which features of monads are specific to monads only and which stem from applicative functors is vitally important for a deeper understanding of monads. As an example, the applicative functor interface of parser libraries can parse recursively enumerable languages, while the monadic interface can parse context-sensitive grammars: Monads allow you to influence further processing by inspecting the result of your parse. To understand why, have a look at the type of >>=. To understand why applicative functors by themselves are sufficient to track the current parsing position and express sequencing, have a look at the [http://www.cs.uu.nl/research/techreps/repo/CS-2008/2008-044.pdf uu-parsinglib tutorial (pdf)].<br />
<br />
The exact differences are elaborated in even greater detail in Brent Yorgey's excellent [[Typeclassopedia]].<br />
<br />
==Monads are not about ordering/sequencing==<br />
Monads are commonly used to order sequences of computations. But this is misleading. Just as you can use monads for state, or strictness, you can use them to order computations. But there are also commutative monads, like Maybe, that don't order anything. So ordering is not in any way essential to what a monad is.<br />
<br />
Let's have a look at what's meant by ordering. Consider an expression like<br />
<br />
<haskell><br />
let x = a<br />
y = b<br />
in f x y<br />
</haskell><br />
<br />
That gives the same result as<br />
<br />
<haskell><br />
let y = b<br />
x = a<br />
in f x y<br />
</haskell><br />
<br />
It doesn't matter what order we write the two bindings. But for doing I/O we'd like ordering. Monads allow us to express<br />
<br />
<haskell><br />
do<br />
x <- getChar<br />
y <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
and have it be different from<br />
<br />
<haskell><br />
do<br />
y <- getChar<br />
x <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
Unlike the first, the second example returns a pair of characters in the opposite order to which they were entered.<br />
<br />
It might help to meditate about the difference between 'assignment' and 'binding', right now.<br />
<br />
However, just to spoil the enlightenment you just attained, there are monads for which swapping the order of lines like this makes no difference: For example, the Maybe monad.<br />
<br />
So while it is correct to say that monads can be used to order operations, it would be wrong to say that monads are a mechanism for ordering operations.<br />
<br />
This notion of commutativity looks superficially very different from the familiar one in vanilla algebra where a+b=b+a. It's not about the fact that<br />
<br />
<haskell><br />
(Just 2 >> Just 3) == Just 3<br />
</haskell><br />
, implying <br />
<haskell><br />
(Just 2 >> Just 3) /= (Just 3 >> Just 2)<br />
</haskell><br />
<br />
This shouldn't be too surprising, though, as >> isn't the binary operation of some monoid: the algebraic properties of '''''join''''' are very close to those of + and incidentally, '''''join''''' is also the operation true category theorists tend to work with. They also know of bind, but don't use it a lot because, unlike programmers, they don't do any actual productive work.<br />
<br />
==See also==<br />
<br />
* [[Do notation considered harmful]]<br />
<br />
[[Category:FAQ]]</div>Ksfhttps://wiki.haskell.org/index.php?title=What_a_Monad_is_not&diff=55724What a Monad is not2013-04-20T01:53:36Z<p>Ksf: /* Monads are not a replacement for applicative functors */</p>
<hr />
<div>==Warning==<br />
Don't be surprised if you leave this page more confused than before. That just means that it has successfully destroyed your false assumptions, or that you've fallen for some horrible inside joke. Beware of [[Zygohistomorphic prepromorphisms]]. Go for [http://ertes.de/articles/monads.html warm and fuzzy], instead.<br />
<br />
==Monads are not a good choice as topic for your first Haskell blog entry==<br />
...just accept that they're [http://blog.plover.com/prog/burritos.html burritos], and wait until later.<br />
<br />
==Monads are not a language feature==<br />
Really. They are defined in terms of Haskell, not Haskell in terms of them. Conversely,<br />
<br />
==Haskell doesn't need Monads==<br />
...well, apart from the current Haskell standard defining the way IO is done in terms of Monads: It could be done differently and still work.<br />
<br />
==Monads are not impure==<br />
...In no way whatsoever. You don't even need flexible morals to claim it. To be more specific, it's IO that's impure. That makes the IO monad impure. But that's not a general property of monads - just IO. And even then, we can pretend that Haskell is a purely functional description language for imperative programs. But we didn't want to employ flexible morals, now did we?<br />
<br />
==Monads are not about state==<br />
While it is certainly possible to abstract away explicit state passing by using a Monad, that's not what a monad is. Some examples for monads that are not about state: Identity monad, Reader monad, List monad, Continuation monad, Exception monad.<br />
<br />
==Monads are not about strictness==<br />
Monad operations (bind and return) have to be [[Non-strict semantics|non-strict]] in fact, always! However<br />
other operations can be specific to each monad.<br />
For instance some are strict (like IO), and some are non-strict (like []). Then there are some that come in multiple flavours, like State.<br />
<br />
Try the following:<br />
<br />
<haskell><br />
runState (sequence . repeat $ state (\x -> (x,x+1))) 0<br />
</haskell><br />
<br />
Having a look at the implementation of fixIO might be helpful, too.<br />
<br />
==Monads are not values==<br />
This point might be driven home best by pointing out that instance Monad Foo where ... is not a data type, but a declaration of a typeclass instance. However, to elaborate:<br />
<br />
Monads are not values in the same sense that addition and multiplication are not numbers, or, for that matter, an oven is not food: They capture a -- very specific -- relationship between values of a specific domain into a common abstraction. We're going to call these values monads manage ''mobits'', somewhat like this:<br />
<br />
<haskell><br />
type Mobit m a = Monad m => m a<br />
</haskell><br />
<br />
The IO monad manages mobits representing side-effects ("IO actions").<br />
<br />
The List monad manages mobits representing multiple values ("[a]")<br />
<br />
The Reader monads manages mobits that are pure computations that use asks to propagate information instead of explicit arguments<br />
<br />
...and while addition and multiplication are both monoids over the positive natural numbers, an oven is a monoid over food (Burned pizza doesn't concern us, here: Food stays food, even if you don't want to eat it.), a monad is a monoid object in a category of endofunctors: return is the unit, and join is the binary operation. It couldn't be more simple. If that confuses you, it might be helpful to see a Monad as a lax functor from a terminal bicategory.<br />
<br />
==Monads are not a replacement for applicative functors==<br />
Instead, every monad ''is'' an applicative functor (as well as a functor). It is considered good practice not to use >>= if all you need is <*>, or even fmap.<br />
<br />
Not confusing which features of monads are specific to monads only and which stem from applicative functors is vitally important for a deeper understanding of monads. As an example, the applicative functor interface of parser libraries can parse recursively enumerable languages, while the monadic interface can parse context-sensitive grammars: Monads allow you to influence further processing by inspecting the result of your parse. To understand why, have a look at the type of >>=. To understand why applicative functors by themselves are sufficient to track the current parsing position and express sequencing, have a look at the [http://www.cs.uu.nl/research/techreps/repo/CS-2008/2008-044.pdf uu-parsinglib tutorial (pdf)].<br />
<br />
The exact differences are elaborated in even greater detail in Brent Yorgey's excellent [[Typeclassopedia]].<br />
<br />
==Monads are not about ordering/sequencing==<br />
Monads are commonly used to order sequences of computations. But this is misleading. Just as you can use monads for state, or strictness, you can use them to order computations. But there are also commutative monads, like Maybe, that don't order anything. So ordering is not in any way essential to what a monad is.<br />
<br />
Let's have a look at what's meant by ordering. Consider an expression like<br />
<br />
<haskell><br />
let x = a<br />
y = b<br />
in f x y<br />
</haskell><br />
<br />
That gives the same result as<br />
<br />
<haskell><br />
let y = b<br />
x = a<br />
in f x y<br />
</haskell><br />
<br />
It doesn't matter what order we write the two bindings. But for doing I/O we'd like ordering. Monads allow us to express<br />
<br />
<haskell><br />
do<br />
x <- getChar<br />
y <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
and have it be different from<br />
<br />
<haskell><br />
do<br />
y <- getChar<br />
x <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
Unlike the first, the second example returns a pair of characters in the opposite order to which they were entered.<br />
<br />
It might help to meditate about the difference between 'assignment' and 'binding', right now.<br />
<br />
However, just to spoil the enlightenment you just attained, there are monads for which swapping the order of lines like this makes no difference: For example, the Maybe monad.<br />
<br />
So while it is correct to say that monads can be used to order operations, it would be wrong to say that monads are a mechanism for ordering operations.<br />
<br />
This notion of commutativity looks superficially very different from the familiar one in vanilla algebra where a+b=b+a. It's not about the fact that<br />
<br />
<haskell><br />
(Just 2 >> Just 3) == Just 3<br />
</haskell><br />
, implying <br />
<haskell><br />
(Just 2 >> Just 3) /= (Just 3 >> Just 2)<br />
</haskell><br />
<br />
This shouldn't be too surprising, though, as >> isn't the binary operation of some monoid: the algebraic properties of '''''join''''' are very close to those of + and incidentally, '''''join''''' is also the operation true category theorists tend to work with. They also know of bind, but don't use it a lot because, unlike programmers, they don't do any actual productive work.<br />
<br />
==See also==<br />
<br />
* [[Do notation considered harmful]]<br />
<br />
[[Category:FAQ]]</div>Ksfhttps://wiki.haskell.org/index.php?title=What_a_Monad_is_not&diff=55723What a Monad is not2013-04-20T01:52:46Z<p>Ksf: /* Monads are not a replacement for applicative functors */</p>
<hr />
<div>==Warning==<br />
Don't be surprised if you leave this page more confused than before. That just means that it has successfully destroyed your false assumptions, or that you've fallen for some horrible inside joke. Beware of [[Zygohistomorphic prepromorphisms]]. Go for [http://ertes.de/articles/monads.html warm and fuzzy], instead.<br />
<br />
==Monads are not a good choice as topic for your first Haskell blog entry==<br />
...just accept that they're [http://blog.plover.com/prog/burritos.html burritos], and wait until later.<br />
<br />
==Monads are not a language feature==<br />
Really. They are defined in terms of Haskell, not Haskell in terms of them. Conversely,<br />
<br />
==Haskell doesn't need Monads==<br />
...well, apart from the current Haskell standard defining the way IO is done in terms of Monads: It could be done differently and still work.<br />
<br />
==Monads are not impure==<br />
...In no way whatsoever. You don't even need flexible morals to claim it. To be more specific, it's IO that's impure. That makes the IO monad impure. But that's not a general property of monads - just IO. And even then, we can pretend that Haskell is a purely functional description language for imperative programs. But we didn't want to employ flexible morals, now did we?<br />
<br />
==Monads are not about state==<br />
While it is certainly possible to abstract away explicit state passing by using a Monad, that's not what a monad is. Some examples for monads that are not about state: Identity monad, Reader monad, List monad, Continuation monad, Exception monad.<br />
<br />
==Monads are not about strictness==<br />
Monad operations (bind and return) have to be [[Non-strict semantics|non-strict]] in fact, always! However<br />
other operations can be specific to each monad.<br />
For instance some are strict (like IO), and some are non-strict (like []). Then there are some that come in multiple flavours, like State.<br />
<br />
Try the following:<br />
<br />
<haskell><br />
runState (sequence . repeat $ state (\x -> (x,x+1))) 0<br />
</haskell><br />
<br />
Having a look at the implementation of fixIO might be helpful, too.<br />
<br />
==Monads are not values==<br />
This point might be driven home best by pointing out that instance Monad Foo where ... is not a data type, but a declaration of a typeclass instance. However, to elaborate:<br />
<br />
Monads are not values in the same sense that addition and multiplication are not numbers, or, for that matter, an oven is not food: They capture a -- very specific -- relationship between values of a specific domain into a common abstraction. We're going to call these values monads manage ''mobits'', somewhat like this:<br />
<br />
<haskell><br />
type Mobit m a = Monad m => m a<br />
</haskell><br />
<br />
The IO monad manages mobits representing side-effects ("IO actions").<br />
<br />
The List monad manages mobits representing multiple values ("[a]")<br />
<br />
The Reader monads manages mobits that are pure computations that use asks to propagate information instead of explicit arguments<br />
<br />
...and while addition and multiplication are both monoids over the positive natural numbers, an oven is a monoid over food (Burned pizza doesn't concern us, here: Food stays food, even if you don't want to eat it.), a monad is a monoid object in a category of endofunctors: return is the unit, and join is the binary operation. It couldn't be more simple. If that confuses you, it might be helpful to see a Monad as a lax functor from a terminal bicategory.<br />
<br />
==Monads are not a replacement for applicative functors==<br />
Instead, every monad ''is'' an applicative functor (as well as a functor). It is considered good practice not to use >>= if all you need is <*>, or even fmap.<br />
<br />
Not confusing which features of monads are specific to monads only and which stem from applicative functors is vitally important for a deeper understanding of monads. As an example, the applicative functor interface of parser libraries can parse recursively enumerable languages (context-free ones if you forego open recursion), while the monadic interface can parse context-sensitive grammars: Monads allow you to influence further processing by inspecting the result of your parse. To understand why, have a look at the type of >>=. To understand why applicative functors by themselves are sufficient to track the current parsing position and express sequencing, have a look at the [http://www.cs.uu.nl/research/techreps/repo/CS-2008/2008-044.pdf uu-parsinglib tutorial (pdf)].<br />
<br />
The exact differences are elaborated in even greater detail in Brent Yorgey's excellent [[Typeclassopedia]].<br />
<br />
==Monads are not about ordering/sequencing==<br />
Monads are commonly used to order sequences of computations. But this is misleading. Just as you can use monads for state, or strictness, you can use them to order computations. But there are also commutative monads, like Maybe, that don't order anything. So ordering is not in any way essential to what a monad is.<br />
<br />
Let's have a look at what's meant by ordering. Consider an expression like<br />
<br />
<haskell><br />
let x = a<br />
y = b<br />
in f x y<br />
</haskell><br />
<br />
That gives the same result as<br />
<br />
<haskell><br />
let y = b<br />
x = a<br />
in f x y<br />
</haskell><br />
<br />
It doesn't matter what order we write the two bindings. But for doing I/O we'd like ordering. Monads allow us to express<br />
<br />
<haskell><br />
do<br />
x <- getChar<br />
y <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
and have it be different from<br />
<br />
<haskell><br />
do<br />
y <- getChar<br />
x <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
Unlike the first, the second example returns a pair of characters in the opposite order to which they were entered.<br />
<br />
It might help to meditate about the difference between 'assignment' and 'binding', right now.<br />
<br />
However, just to spoil the enlightenment you just attained, there are monads for which swapping the order of lines like this makes no difference: For example, the Maybe monad.<br />
<br />
So while it is correct to say that monads can be used to order operations, it would be wrong to say that monads are a mechanism for ordering operations.<br />
<br />
This notion of commutativity looks superficially very different from the familiar one in vanilla algebra where a+b=b+a. It's not about the fact that<br />
<br />
<haskell><br />
(Just 2 >> Just 3) == Just 3<br />
</haskell><br />
, implying <br />
<haskell><br />
(Just 2 >> Just 3) /= (Just 3 >> Just 2)<br />
</haskell><br />
<br />
This shouldn't be too surprising, though, as >> isn't the binary operation of some monoid: the algebraic properties of '''''join''''' are very close to those of + and incidentally, '''''join''''' is also the operation true category theorists tend to work with. They also know of bind, but don't use it a lot because, unlike programmers, they don't do any actual productive work.<br />
<br />
==See also==<br />
<br />
* [[Do notation considered harmful]]<br />
<br />
[[Category:FAQ]]</div>Ksfhttps://wiki.haskell.org/index.php?title=What_a_Monad_is_not&diff=55587What a Monad is not2013-03-21T09:28:40Z<p>Ksf: /* Monads are not a replacement for applicative functors */</p>
<hr />
<div>==Warning==<br />
Don't be surprised if you leave this page more confused than before. That just means that it has successfully destroyed your false assumptions, or that you've fallen for some horrible inside joke. Beware of [[Zygohistomorphic prepromorphisms]]. Go for [http://ertes.de/articles/monads.html warm and fuzzy], instead.<br />
<br />
==Monads are not a good choice as topic for your first Haskell blog entry==<br />
...just accept that they're [http://blog.plover.com/prog/burritos.html burritos], and wait until later.<br />
<br />
==Monads are not a language feature==<br />
Really. They are defined in terms of Haskell, not Haskell in terms of them. Conversely,<br />
<br />
==Haskell doesn't need Monads==<br />
...well, apart from the current Haskell standard defining the way IO is done in terms of Monads: It could be done differently and still work.<br />
<br />
==Monads are not impure==<br />
...In no way whatsoever. You don't even need flexible morals to claim it. To be more specific, it's IO that's impure. That makes the IO monad impure. But that's not a general property of monads - just IO. And even then, we can pretend that Haskell is a purely functional description language for imperative programs. But we didn't want to employ flexible morals, now did we?<br />
<br />
==Monads are not about state==<br />
While it is certainly possible to abstract away explicit state passing by using a Monad, that's not what a monad is. Some examples for monads that are not about state: Identity monad, Reader monad, List monad, Continuation monad, Exception monad.<br />
<br />
==Monads are not about strictness==<br />
Monad operations (bind and return) have to be [[Non-strict semantics|non-strict]] in fact, always! However<br />
other operations can be specific to each monad.<br />
For instance some are strict (like IO), and some are non-strict (like []). Then there are some that come in multiple flavours, like State.<br />
<br />
Try the following:<br />
<br />
<haskell><br />
runState (sequence . repeat $ state (\x -> (x,x+1))) 0<br />
</haskell><br />
<br />
Having a look at the implementation of fixIO might be helpful, too.<br />
<br />
==Monads are not values==<br />
This point might be driven home best by pointing out that instance Monad Foo where ... is not a data type, but a declaration of a typeclass instance. However, to elaborate:<br />
<br />
Monads are not values in the same sense that addition and multiplication are not numbers, or, for that matter, an oven is not food: They capture a -- very specific -- relationship between values of a specific domain into a common abstraction. We're going to call these values monads manage ''mobits'', somewhat like this:<br />
<br />
<haskell><br />
type Mobit m a = Monad m => m a<br />
</haskell><br />
<br />
The IO monad manages mobits representing side-effects ("IO actions").<br />
<br />
The List monad manages mobits representing multiple values ("[a]")<br />
<br />
The Reader monads manages mobits that are pure computations that use asks to propagate information instead of explicit arguments<br />
<br />
...and while addition and multiplication are both monoids over the positive natural numbers, an oven is a monoid over food (Burned pizza doesn't concern us, here: Food stays food, even if you don't want to eat it.), a monad is a monoid object in a category of endofunctors: return is the unit, and join is the binary operation. It couldn't be more simple. If that confuses you, it might be helpful to see a Monad as a lax functor from a terminal bicategory.<br />
<br />
==Monads are not a replacement for applicative functors==<br />
Instead, every monad ''is'' an applicative functor (as well as a functor). It is considered good practice not to use >>= if all you need is <*>, or even fmap.<br />
<br />
Not confusing which features of monads are specific to monads only and which stem from applicative functors is vitally important for a deeper understanding of monads. As an example, the applicative functor interface of parser libraries can parse context-free grammars (and looks just like EBNF), while the monadic interface can parse context-sensitive grammars: Monads allow you to influence further processing by inspecting the result of your parse. To understand why, have a look at the type of >>=. To understand why applicative functors by themselves are sufficient to track the current parsing position, have a look at the [http://www.cs.uu.nl/research/techreps/repo/CS-2008/2008-044.pdf uu-parsinglib tutorial (pdf)].<br />
<br />
The exact differences are elaborated in even greater detail in Brent Yorgey's excellent [[Typeclassopedia]].<br />
<br />
==Monads are not about ordering/sequencing==<br />
Monads are commonly used to order sequences of computations. But this is misleading. Just as you can use monads for state, or strictness, you can use them to order computations. But there are also commutative monads, like Maybe, that don't order anything. So ordering is not in any way essential to what a monad is.<br />
<br />
Let's have a look at what's meant by ordering. Consider an expression like<br />
<br />
<haskell><br />
let x = a<br />
y = b<br />
in f x y<br />
</haskell><br />
<br />
That gives the same result as<br />
<br />
<haskell><br />
let y = b<br />
x = a<br />
in f x y<br />
</haskell><br />
<br />
It doesn't matter what order we write the two bindings. But for doing I/O we'd like ordering. Monads allow us to express<br />
<br />
<haskell><br />
do<br />
x <- getChar<br />
y <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
and have it be different from<br />
<br />
<haskell><br />
do<br />
y <- getChar<br />
x <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
Unlike the first, the second example returns a pair of characters in the opposite order to which they were entered.<br />
<br />
It might help to meditate about the difference between 'assignment' and 'binding', right now.<br />
<br />
However, just to spoil the enlightenment you just attained, there are monads for which swapping the order of lines like this makes no difference: For example, the Maybe monad.<br />
<br />
So while it is correct to say that monads can be used to order operations, it would be wrong to say that monads are a mechanism for ordering operations.<br />
<br />
This notion of commutativity looks superficially very different from the familiar one in vanilla algebra where a+b=b+a. It's not about the fact that<br />
<br />
<haskell><br />
(Just 2 >> Just 3) == Just 3<br />
</haskell><br />
, implying <br />
<haskell><br />
(Just 2 >> Just 3) /= (Just 3 >> Just 2)<br />
</haskell><br />
<br />
This shouldn't be too surprising, though, as >> isn't the binary operation of some monoid: the algebraic properties of '''''join''''' are very close to those of + and incidentally, '''''join''''' is also the operation true category theorists tend to work with. They also know of bind, but don't use it a lot because, unlike programmers, they don't do any actual productive work.<br />
<br />
==See also==<br />
<br />
* [[Do notation considered harmful]]<br />
<br />
[[Category:FAQ]]</div>Ksfhttps://wiki.haskell.org/index.php?title=What_a_Monad_is_not&diff=55586What a Monad is not2013-03-21T09:22:19Z<p>Ksf: /* Warning */</p>
<hr />
<div>==Warning==<br />
Don't be surprised if you leave this page more confused than before. That just means that it has successfully destroyed your false assumptions, or that you've fallen for some horrible inside joke. Beware of [[Zygohistomorphic prepromorphisms]]. Go for [http://ertes.de/articles/monads.html warm and fuzzy], instead.<br />
<br />
==Monads are not a good choice as topic for your first Haskell blog entry==<br />
...just accept that they're [http://blog.plover.com/prog/burritos.html burritos], and wait until later.<br />
<br />
==Monads are not a language feature==<br />
Really. They are defined in terms of Haskell, not Haskell in terms of them. Conversely,<br />
<br />
==Haskell doesn't need Monads==<br />
...well, apart from the current Haskell standard defining the way IO is done in terms of Monads: It could be done differently and still work.<br />
<br />
==Monads are not impure==<br />
...In no way whatsoever. You don't even need flexible morals to claim it. To be more specific, it's IO that's impure. That makes the IO monad impure. But that's not a general property of monads - just IO. And even then, we can pretend that Haskell is a purely functional description language for imperative programs. But we didn't want to employ flexible morals, now did we?<br />
<br />
==Monads are not about state==<br />
While it is certainly possible to abstract away explicit state passing by using a Monad, that's not what a monad is. Some examples for monads that are not about state: Identity monad, Reader monad, List monad, Continuation monad, Exception monad.<br />
<br />
==Monads are not about strictness==<br />
Monad operations (bind and return) have to be [[Non-strict semantics|non-strict]] in fact, always! However<br />
other operations can be specific to each monad.<br />
For instance some are strict (like IO), and some are non-strict (like []). Then there are some that come in multiple flavours, like State.<br />
<br />
Try the following:<br />
<br />
<haskell><br />
runState (sequence . repeat $ state (\x -> (x,x+1))) 0<br />
</haskell><br />
<br />
Having a look at the implementation of fixIO might be helpful, too.<br />
<br />
==Monads are not values==<br />
This point might be driven home best by pointing out that instance Monad Foo where ... is not a data type, but a declaration of a typeclass instance. However, to elaborate:<br />
<br />
Monads are not values in the same sense that addition and multiplication are not numbers, or, for that matter, an oven is not food: They capture a -- very specific -- relationship between values of a specific domain into a common abstraction. We're going to call these values monads manage ''mobits'', somewhat like this:<br />
<br />
<haskell><br />
type Mobit m a = Monad m => m a<br />
</haskell><br />
<br />
The IO monad manages mobits representing side-effects ("IO actions").<br />
<br />
The List monad manages mobits representing multiple values ("[a]")<br />
<br />
The Reader monads manages mobits that are pure computations that use asks to propagate information instead of explicit arguments<br />
<br />
...and while addition and multiplication are both monoids over the positive natural numbers, an oven is a monoid over food (Burned pizza doesn't concern us, here: Food stays food, even if you don't want to eat it.), a monad is a monoid object in a category of endofunctors: return is the unit, and join is the binary operation. It couldn't be more simple. If that confuses you, it might be helpful to see a Monad as a lax functor from a terminal bicategory.<br />
<br />
==Monads are not a replacement for applicative functors==<br />
Instead, every monad ''is'' an applicative functor (as well as a functor). It is considered good practice not to use >>= if all you need is <*>, or even fmap.<br />
<br />
Not confusing which features of monads are specific to monads only and which stem from applicative functors is vitally important for a deeper understanding of monads. As an example, the applicative functor interface of parser libraries can parse context-free grammars (and look just like EBNF), while the monadic interface can parse context-sensitive grammars: Monads allow you to influence further processing by inspecting the result of your parse. To understand why, have a look at the type of >>=. To understand why applicative functors by themselves are sufficient to track the current parsing position, have a look at the [http://www.cs.uu.nl/research/techreps/repo/CS-2008/2008-044.pdf uu-parsinglib tutorial (pdf)].<br />
<br />
The exact differences are elaborated in even greater detail in Brent Yorgey's excellent [[Typeclassopedia]].<br />
<br />
==Monads are not about ordering/sequencing==<br />
Monads are commonly used to order sequences of computations. But this is misleading. Just as you can use monads for state, or strictness, you can use them to order computations. But there are also commutative monads, like Maybe, that don't order anything. So ordering is not in any way essential to what a monad is.<br />
<br />
Let's have a look at what's meant by ordering. Consider an expression like<br />
<br />
<haskell><br />
let x = a<br />
y = b<br />
in f x y<br />
</haskell><br />
<br />
That gives the same result as<br />
<br />
<haskell><br />
let y = b<br />
x = a<br />
in f x y<br />
</haskell><br />
<br />
It doesn't matter what order we write the two bindings. But for doing I/O we'd like ordering. Monads allow us to express<br />
<br />
<haskell><br />
do<br />
x <- getChar<br />
y <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
and have it be different from<br />
<br />
<haskell><br />
do<br />
y <- getChar<br />
x <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
Unlike the first, the second example returns a pair of characters in the opposite order to which they were entered.<br />
<br />
It might help to meditate about the difference between 'assignment' and 'binding', right now.<br />
<br />
However, just to spoil the enlightenment you just attained, there are monads for which swapping the order of lines like this makes no difference: For example, the Maybe monad.<br />
<br />
So while it is correct to say that monads can be used to order operations, it would be wrong to say that monads are a mechanism for ordering operations.<br />
<br />
This notion of commutativity looks superficially very different from the familiar one in vanilla algebra where a+b=b+a. It's not about the fact that<br />
<br />
<haskell><br />
(Just 2 >> Just 3) == Just 3<br />
</haskell><br />
, implying <br />
<haskell><br />
(Just 2 >> Just 3) /= (Just 3 >> Just 2)<br />
</haskell><br />
<br />
This shouldn't be too surprising, though, as >> isn't the binary operation of some monoid: the algebraic properties of '''''join''''' are very close to those of + and incidentally, '''''join''''' is also the operation true category theorists tend to work with. They also know of bind, but don't use it a lot because, unlike programmers, they don't do any actual productive work.<br />
<br />
==See also==<br />
<br />
* [[Do notation considered harmful]]<br />
<br />
[[Category:FAQ]]</div>Ksfhttps://wiki.haskell.org/index.php?title=QuotesPage&diff=40715QuotesPage2011-06-30T03:25:12Z<p>Ksf: </p>
<hr />
<div>seen on comp.lang.functional:<br />
<br />
From: Ashley Yakeley <ashley@semantic.org><br />
Subject: Re: Type advocacy<br />
Newsgroups: comp.lang.functional<br />
Date: Thu, 11 Oct 2001 21:16:20 -0700<br />
Organization: Myself<br />
<br />
In article <9pdvgc$u3d$1@news.fas.harvard.edu>, Ken Shan<br />
<ken@digitas.harvard.edu> wrote:<br />
<br />
> I am preparing a three-minute talk to tell incoming graduate students<br />
> at my school about types.<br />
<br />
Oh like that's going to work. You'd be better off selling T-shirts that<br />
say "WHAT PART OF" (and then the Hindley-Milner prinicipal-type<br />
algorithm) "DON'T YOU UNDERSTAND?".<br />
<br />
If anyone gives you any lip, ask them how to find the square-root of a<br />
string. Everything else follows on from that.<br />
<br />
> What pointers should I give?<br />
<br />
Safe ones.<br />
<br />
--<br />
Ashley Yakeley, Seattle WA<br />
<br />
After reading this, I just couldn't resist:<br />
<br />
http://www.cafeshops.com/skicalc<br />
<br />
--Riastradh<br />
<br />
----<br />
<br />
<Pseudonym> Lazy evalution is really, really trippy. <br />
<br />
----<br />
<br />
<nowiki>*</nowiki> jemfinch just printed an infinite list.<br />
<Pseudonym> Quick, type control-C before you run out of bits!<br />
<br />
----<br />
<br />
Not all things worth counting are countable and not all things that count are worth counting. <br />
<br />
-- Albert Einstein<br />
<br />
----<br />
<br />
<tez> Anyway, I think the lesson is "don't drink and derive". Or something.<br />
<br />
----<br />
<br />
seen on The Pragmatic Programmer's yahoo mailing list:<br />
<br />
From: Ronald Legere <rjljr2@yahoo.com><br />
Subject: Re: Jedi Programming (was: [pragprog] Common List or Dylan?)<br />
To: pragprog@yahoogroups.com<br />
Date: Wed, 25 Sep 2002 03:29:01 -0700 (PDT)<br />
Reply-To: pragprog@yahoogroups.com<br />
<br />
No no no, a jedi master must fashion his<br />
OWN language.<br />
<br />
<*grin*><br />
<br />
--- Michael Schuerig <schuerig@acm.org> wrote:<br />
> On Wednesday 25 September 2002 05:27, Edward Wilson<br />
> wrote:<br />
> > The real question is: if you were a Jedi Knight,<br />
> and<br />
> > you could only master *one* language as your<br />
> weapon of<br />
> > choice, what would it be--Common Lisp?<br />
><br />
> Probably. In particular, considering that the Jedi<br />
> seem to be somewhat<br />
> conservative and CL beautifully captures the<br />
> anachronistic elegance and<br />
> power of a programming lightsaber. Future Jedi<br />
> generations might choose<br />
> more modern weapons; Haskell, OCaml and Oz being<br />
> among the contenders.<br />
><br />
> Michael<br />
><br />
> --<br />
> Michael Schuerig<br />
> You should go home and<br />
> mailto:schuerig@acm.org<br />
> reconsider your life.<br />
> http://www.schuerig.de/michael/<br />
> --Obi-Wan, "AotC"<br />
<br />
----<br />
<br />
<shapr> I'm addicted to arrows.<br />
<nowiki>*</nowiki> shapr begins his own paper "Generalizing Arrows to Spears"<br />
<shapr> Spears can do anything efficiently, but they have sixty thousand laws they must satisfy, and we haven't actually found one yet.<br />
<raphael> maybe "Generalizing Arrows to Nuclear Weapons" would simply be: unsafeInterleaveIO<br />
<br />
----<br />
<br />
<Janni> doesn't ghc create really _fast_ code?<br />
<Heffalump> Janni: it creates really fast Haskell code<br />
<br />
----<br />
<br />
seen on #java<br />
<br />
<sh1nta> anyone familiar with javacc or any kind of parser for java object?<br />
<shapr> I know of a good java source parser for Haskell<br />
<sh1nta> shapr:what do you think is a good way to parse an inputstream of strings?<br />
like there is a,b,c coming through the serial stream..i have to grab those data<br />
<shapr> sh1nta: I'd use monadic parser combinators.<br />
<sh1nta> shapr:in simpler words?<br />
<sh1nta> shapr:i am kinda newbie<br />
<Logi> shapr: no fair to use heavy haskell jargon<br />
<nowiki>*</nowiki> mprentice applauds shapr for picking on the n00b<br />
<Logi> sh1nta: shapr would do that cause he'd be doing it in Haskell.<br />
<mprentice> sh1nta: it depends on what kind of data you're parsing, but javacc might be kinda overkill. it'll take a day at least to learn enough to do anything complicated enough to make it worth doing.<br />
<nowiki>*</nowiki> mprentice uses a nuke to kill the pesky cockroach<br />
<Logi> oh, learning enough to use monads will take you a week<br />
<br />
----<br />
<br />
<esap> I think the way to get stuff done is by doing it.<br />
<Marvin--> esap: damn you're smart<br />
<br />
----<br />
<br />
<shapr> GHC has more flags than the UN<br />
<br />
----<br />
<br />
<nowiki>*</nowiki> jlouis replaces dark with a very small higher order function<br />
<br />
----<br />
<br />
<jlouis> Q: When does one know he has programmed too much Haskell? A: When he uses == and /= in everyday IRC chat<br />
<jlouis> or when he tries to fix a relationship by passing himself as a continuation<br />
<br />
----<br />
<br />
<shapr> I think we should make up a name for combinators that works like Java Beans<br />
<shapr> how about calling them Chickens?<br />
<Arnia> Chickens?<br />
<shapr> then we could talk about Currying Chickens<br />
<nowiki>*</nowiki> Arnia groans<br />
<br />
----<br />
<br />
<Grog`> http://www.cse.unsw.edu.au/~cs1011/assignment/assign1/index.html<br />
<Smerdyakov> This isn't a homework answer service.<br />
<Grog`> is it a kind service<br />
<Smerdyakov> Yeah, the answer is "drop the class if you're too dumb to do that problem," directed to whoever is in the class.<br />
<br />
----<br />
<br />
after a long pointless discussion with a fanatically loyal C programmer on comp.lang.functional <a40a15cb.0304160038.585f3e8@posting.google.com>:<br />
<br />
"The best thing to get out of this, I guess,is that Haskell IS becoming more mainstream and even morons have heard of it." -- DerekElkins<br />
<br />
----<br />
<br />
seen on news://comp.lang.functional<br />
<br />
> By the way seriously: how do you debug Haskell programs?<br />
<br />
Mostly seriously: I don't. If the programme doesn't work the<br />
way I intended it, I rewrite bits in a simpler fashion until<br />
I understand it well enough and it works. For the sort of<br />
programme you were asking for, breaking things up until they<br />
are small enough that one can understand the individual<br />
parts completely (as I did in the solution I posted) and<br />
then composing them together really is the best approach.<br />
<br />
If you need to debug a programme that simple, what it's<br />
telling you is that you've written it the wrong way!<br />
<br />
--<br />
Jón Fairbairn<br />
<br />
----<br />
<br />
<Marvin--> the good thing with free software, though, is that I can write my damn software and when someone complains that it doesn't work on their toaster because I'm a moron who can't write portable code, I can say, smiling, "patches welcome"<br />
<shapr> yah, I like that too<br />
<shapr> but then sometimes you get "I can't understand a bit of your Java code"<br />
<Marvin--> that's when you reply "me neither, life's a bitch, isn't it?"<br />
<br />
----<br />
<br />
"So, the essence of XML is this: the problem it solves is not hard, and<br />
it does not solve the problem well." -- Jerome Simeon & Phil Wadler<br />
<br />
----<br />
<br />
in the midst of a discussion about the 'Evil Mangler' in GHC 5.04<br />
<br />
<shapr> the evil mangler uses *perl* ??<br />
<ChilliX> yes...<br />
<ChilliX> it is Evil after all<br />
<br />
----<br />
<br />
<andersca> what meeting?<br />
<Marvin--> research meeting for the cover group<br />
<shapr> are you guys covering up the black ops section?<br />
<Marvin--> shapr: there is no HSU<br />
<shapr> and you're not part of it<br />
<Marvin--> of course not<br />
<br />
----<br />
<br />
In reply to someone who said unsafePerformIO docs didn't include enough warnings, ManuelChakravarty replied:<br />
<br />
After all, you can import any C function with a pure type,<br />
which also allows you to wreak arbitrary havoc. We enable<br />
the user to disguise arbitrary machine code as a Haskell<br />
function of essentially arbitrary type. In comparison,<br />
`unsafePerformIO' seems angelic.<br />
<br />
----<br />
<br />
[discussion of the merits of lazy, eager, macros snipped]<br />
The idea isn't to blunder into a language looking for evidence<br />
to support a bunch of preconceived misconceptions.<br />
the idea is to understand why things are the way they are.<br />
<br />
macros have advantages and disadvantages.<br />
graham lists them in that same chapter.<br />
understanding those lets you choose the right tool for the job.<br />
that's why it's a good book. if you're not interested in choosing the right tool, but only in proving that something is "better" or "worse" than something else, then why waste time reading books?<br />
the world is complex and the more you understand the less certain things become.<br />
if you prefer simple black and white then it's better not to learn...<br />
<br />
(maybe i should add that i don't use lisp;<br />
that normally i find it's lisp users who are annoyingly dismissive of other languages; that i, too, have criticised things before understanding them at times; also it's monday morning and i'm still on my first cup of coffee)<br />
<br />
-- andrew cooke <br />
<br />
----<br />
<br />
<CowGirl> what are the 2 most common recursive errors?<br />
<hdaume> CowGirl: what<br />
<CowGirl> is a question in a past exam on haskell<br />
<CowGirl> 2 of the most common recursive errors<br />
<hdaume> ...oh....i thought it was a lead-in to a joke<br />
<br />
----<br />
<br />
<syntax-laptop> is there a punchline to "how many recursions does it take to screw in a lightbulb?"? <br />
<cale> It takes n recursions to screw in a light bulb, one to turn the light bulb once, and n-1 to screw it in.<br />
<br />
----<br />
<br />
seen on #haskell:<br />
<br />
<Riastradh> What does HFL stand for?<br />
<shapr> Haskell Foundation Libraries<br />
<Igloo> Haskell Foundation Library<br />
<dark> Obviously shapr and Igloo must now duel to the death.<br />
<nowiki>*</nowiki> shapr duals Igloo<br />
<nowiki>*</nowiki> Riastradh hands shapr a monad and Igloo a comonad.<br />
<nowiki>*</nowiki> Igloo waves it around and makes voooob voooob noises<br />
<nowiki>*</nowiki> shapr waves his monad around making boov boov noises<br />
<Heffalump> Igloo: careful with that, it's unsafe<br />
<br />
----<br />
<br />
<shapr> for example: "head (filter (\x -> x > 5) [1..])"<br />
<shapr> in a strict language, you can't easily play with infinite lists<br />
<dark> In a strict language, you would write that as "6" :)<br />
<br />
----<br />
<br />
<Marvin--> I often sigh and say "I could do this way faster and way better in Haskell" and then they say "yeah, and we wouldn't understand a thing of it"<br />
<br />
----<br />
<br />
<ejt> I guess it's time I leant how to interface to foriegn code, any pointers ?<br />
<br />
----<br />
<br />
<Riastradh> There's no Greek letter for it that I can confuse people with?<br />
<br />
The "it" refers to the monadic bind operation.<br />
<br />
----<br />
<br />
<Darius> ($$$) :: HardWork -> Dedication -> IO Money<br />
<Darius> _ $$$ _ = ioError "Ideology overflow"<br />
<br />
----<br />
<br />
Ninja Jones does a not-too-far-off parody of a certain flavor of visitor to #haskell<br />
<br />
*** highlyInterested has joined channel #haskell<br />
<highlyInterested> hi! I'm highly interested, but have no attention span!!!<br />
<highlyInterested> Can anyone help me?!?!?<br />
<nowiki>*</nowiki> highlyInterested runs around!!<br />
*** highlyInterested has quit: Client Quit<br />
<br />
----<br />
<br />
January 9, 2003:<br />
<br />
Heffalump: I need to teach my girlfriend temporal logic.<br />
Marvin--: how so?<br />
Heffalump: she seems to have problems with the "until" operator.<br />
<br />
----<br />
<br />
VersusQuotesPage<br />
<br />
----<br />
<br />
(Ok, remove these c.l.s quotes (or move to some other page) if deemed unappropriate for this QuotesPage !)<br />
<br />
seen on news://comp.lang.scheme :<br />
<br />
From: Shriram Krishnamurthi <sk@cs.brown.edu><br />
Newsgroups: comp.lang.scheme<br />
Subject: Re: What happened to schemers.org?<br />
Date: 17 Sep 2002 11:53:53 -0400<br />
Organization: Brown University<br />
<br />
Luigi Ballabio <luigi.ballabio@fastwebnet.it> writes:<br />
<br />
> I just checked to site only to find out that it was taken over<br />
> by the Dept. of CS at Brown. Is the old site still alive somewhere?<br />
<br />
The Revolution has begun. The department has been taken over.<br />
Comrade Shivers's helicopter will land on College Green at 3.14pm.<br />
Deployment of the Underground begins soon thereafter. Lambda bandanas<br />
will be available at the corner of Thayer and Waterman. Please remain<br />
calm and nobody will get skewered on parentheses.<br />
<br />
[snipped]<br />
<br />
Cmde. Shriram<br />
<br />
From: ds26@goldshoe.gte.com (Dorai Sitaram)<br />
<br />
In article <w7d1y7slii6.fsf@cs.brown.edu>,<br />
Shriram Krishnamurthi <sk@cs.brown.edu> wrote:<br />
>Luigi Ballabio <luigi.ballabio@fastwebnet.it> writes:<br />
[snipped]<br />
<br />
3.14 *pm*, huh? Underground types (once so strong and<br />
dynamic) seem to be getting rather soft and lazy<br />
these days.<br />
<br />
From: "Anton van Straaten" <anton@appsolutions.com><br />
<br />
Dorai Sitaram wrote:<br />
[snipped]<br />
<br />
There's such a thing as being too eager, you know. You wouldn't want an<br />
organization like the Underground to remain static, now, would you? That<br />
might make them weak, and then they'd need a strict hand to recover the type<br />
of discipline they're known for...<br />
<br />
From: Joe Marshall <jrm@ccs.neu.edu><br />
<br />
MJ Ray <markj+0111@cloaked.freeserve.co.uk> writes:<br />
<br />
> Joe Marshall <jrm@ccs.neu.edu> wrote:<br />
> > Maybe the plans have shouldn't have been finalized.<br />
> > There is a lot of collective finger-pointing.<br />
><br />
> Please, this is exceptionally short.<br />
<br />
Damn, you caught me. But you raise an important point.<br />
<br />
> I think it's elaboration time.<br />
<br />
Perhaps, but this message may be read by people who, shall we say,<br />
`don't exercise proper hygiene' and I don't want them to take anything<br />
out of context.<br />
<br />
----<br />
<br />
<DeezNuts> whats the point of programming in haskell beyond it being a cute toy for math fans<br />
<mgoetze> DeezNuts: what's the point of programming in c++ beyond it being a cute toy for masochists?<br />
<br />
----<br />
<br />
<Pseudonym> Well, personally, I don't think dumb people should be let near a programming language.<br />
<br />
----<br />
<br />
<shapr> how will you know when you've written enough?<br />
<kosmikus> I don't really know yet, but one of the following:<br />
(a) if my supervisor tells me I have,<br />
(b) if every chapter heading has content following it,<br />
(c) if the deadline is there<br />
<shapr> that's an excellent heuristic<br />
<br />
----<br />
<br />
<Jerub> I wonder if any interesting languages are going to come out of this parrot thing.<br />
<CrewdenX> Jerub: is that the hybrid perl/python thing?<br />
<Heffalump> it's the common bytecode for the two, yes<br />
<stepcut> see, perl wasn't bad enough, so now you can make your code even more unreadable by written it a mixture of languages<br />
<Jerub> its actually the perl6 vm, but they're trying to be the be all and end all of VMs for languages.<br />
<Riastradh> And they're going to fail miserably and end up with something that sorta kinda works for Python and Perl and doesn't make sense for anything else.<br />
<Riastradh> But they'll persist and say 'ooh ooh look it has continuations so it must work for other languages!' causing more and more people to flock to them more and write more crappy compiler back ends and make the state of the main stream of programming languages suck even more.<br />
<Riastradh> Meanwhile, due to lack of person power, the quality functional language compilers will deteriorate into bitrot, so that the main stream idiots can say 'but look, it doesn't even have a library for X, so it must suck, and I won't even bother thinking about writing it, because my crappy language already has it!'<br />
<Riastradh> Then the revolution will come.<br />
<Riastradh> What happens then I leave up to your imagination, but I can tell you it won't be pretty for the main stream.<br />
<br />
----<br />
<br />
seen in an email from Simon Marlow,<br />
<br />
Simon's cheat sheet for getting fast Haskell code:<br />
Rule 1: don't use String I/O.<br />
Rule 2: Profile your program. Find the inner loop. Look for overloading. Squash. Repeat. Look for laziness. Squash. Repeat.<br />
<br />
----<br />
<br />
Haskell poetry : 16:50 < shapr> the snow falls slowly, the lambdas are lifting, weak head normal form<br />
<br />
----<br />
<br />
/DuelsPage<br />
<br />
----<br />
<br />
<SyntaxNinja> it is a little disturbing when lambdabot starts channeling shapr<br />
<Riastradh> What about when shapr starts channeling lambdabot?<br />
<Riastradh> shapr: @yow<br />
<shapr> I was in MINNETONKA!<br />
<shapr> Butch Cassidy had my children!<br />
<Riastradh> shapr: @eval (X X X) (X (X X)) (X (X X)) ((X (X X) (X X X))<br />
<br />
----<br />
<br />
15:50 < Marvin--> remind me to prod Koen about releasing a new version of QC<br />
15:50 < shapr> Marvin--: hey, could you prod Koen about ...<br />
15:50 < Marvin--> huh?<br />
15:50 < Marvin--> about what?<br />
15:50 < shapr> about releasing a new version of QC!<br />
15:50 * Marvin-- has even shorter attention span than shapr!<br />
<br />
----<br />
<br />
Simon Marlow's How to Translate C to Haskell:<br />
<br />
> On Thu, Mar 25, 2004 at 01:38:44AM +1100, Alex Gontcharov wrote:<br />
> > Hi,<br />
> ><br />
> > I am new to haskell and would look to write a function equivalent<br />
> > to the following loop in C<br />
> ><br />
> > int value = 500000;<br />
> > int part_stack[4];<br />
> > int *part_ptr = part_stack;<br />
> > for (; value; value /= 10000)<br />
> > *part_ptr++ = value % 10000;<br />
><br />
> part_stack :: [Int]<br />
> part_stack = [0,50]<br />
><br />
> Note that I've performed a memoization optimization--this<br />
> makes the code both smaller, faster and easier to read! :P<br />
<br />
Ignore David, he's pulling your leg. Here's the proper translation:<br />
<br />
do<br />
alloca $ \value -> do<br />
poke value (500000::Int)<br />
allocaArray 4 $ \part_stack -> do<br />
alloca $ \part_ptr -> do<br />
poke part_ptr part_stack<br />
let loop = do<br />
val <- peek value<br />
if val == 0 then return () else do<br />
p <- peek part_ptr<br />
poke p (val `rem` 10000)<br />
poke part_ptr (p `plusPtr` 1)<br />
poke value (val `quot` 10000)<br />
loop<br />
loop<br />
<br />
Cheers,<br />
Simon<br />
<br />
----<br />
<br />
IRL is short for "in real life" and refers to face to face communication<br />
<br />
<bring> it seems it's a lot easier to get into a heated discussion (flamewar if you will) in irc, email or news than irl<br />
<bring> something about the lack of non-verbal communication<br />
<shapr> I think assholes don't survive IRL<br />
<bring> making someone not survive must surely count as non-verbal communication<br />
<br />
----<br />
<br />
there's the port we've been missing...<br />
<br />
<ozone> shapr: hugs has been ported to an apple IIIc?<br />
<ozone> shapr: MAIN :: IO (); MAIN = DO PUTSTRLN "GODDAMN CAPS"<br />
<br />
----<br />
<br />
sig seen on usenet :<br />
<br />
--<br />
<nowiki>.:[ dave benjamin: ramen/[sp00] -:- spoomusic.com -:- ramenfest.com ]:.</nowiki><br />
<nowiki>: please talk to your son or daughter about parametric polymorphism. :</nowiki><br />
<br />
----<br />
<br />
In the spirit of the above quote:<br />
<br />
"But I don't _want_ functional programming!"<br />
-- Sarah Peyton Jones, age 11, upon hearing the rules of Go<br />
<br />
----<br />
<br />
Sometimes I wonder if Java will be indirectly responsible for hastening the adoption of functional programming languages by providing a caricature of procedural OO. -- Christopher Hendrie<br />
<br />
----<br />
<br />
<kosmikus> is there a good english translation for the german word gleichnamig"?<br />
<kosmikus> basically: The Chapter "Type-indexed datatypes" is based on the ... paper.<br />
<Igloo> I'd say "on the paper of the same name"<br />
<Shammah> earthy: but apparently german can do it in one word, and we can't be letting the germans get away with a shorter phrase than us for the same concept!!! ;)<br />
<earthy> `Das Kapittel `Type-indexed data types' ist auf dem gleichnamigen Artikel basiert'<br />
<earthy> `The chapter `Type-indexed data types' is based on the article of the same name'<br />
<earthy> you count. :)<br />
<earthy> `Het hoofdstuk `Type-indexed data types' is op het gelijknamige artikel gebaseerd'<br />
<shapr> Det kapitel `Type-indexed data types' &#228;r grunded av det artikel med samma namn.<br />
<earthy> `Le chapitre `Type-indexed data types' est bas&#233; sur l'article du m&#234;me nom'<br />
<adept> Here's in russian: òÁÚÄÅÌ "éÎÄÅËÓÉÒÏ×ÁÎÎÙÅ ÔÉÐÁÍÉ ÔÉÐÙ ÄÁÎÎÙÈ" ÏÓÎÏ×ÁÎ ÎÁ ÏÄÎÉÍÅÎÎÏÊ ÓÔÁÔØÅ<br />
<br />
----<br />
<br />
during a discussion about writing a real-time strategy game in Haskell....<br />
<br />
<shapr> so my idea was to write a strategy combinator library<br />
<det> shapr: you crazy haskellers, a special tool for every program!<br />
<shapr> nah, a way to program your units<br />
<det> shapr: Function Ractive Arrows with Monadic covariance, HOW CAN MY RTS FAIL!<br />
<br />
----<br />
<br />
<Igloo> Waah. LaTeX hates me.<br />
<lispy> Igloo: why is that?<br />
<Igloo> Because it's cast from pure liquid evil, probably<br />
<br />
----<br />
<br />
<Jerub> shapr: we have a new manager. she complained of a bad heart when I told her we didn't have revision control.<br />
<br />
----<br />
<br />
one minute after the 2004 ICFP programming contest task was announced...<br />
<br />
<Lor> This looks pretty darn cool.<br />
<Lor> This also looks pretty darn non-trivial.<br />
<tmoertel> Lor: No, it *is* trivial: Just de-compile a real ant and reverse engineer it.<br />
<tmoertel> :P<br />
<br />
----<br />
<br />
<stepcut> in unrelated news, I think I want to produce and air an infomercial<br />
<stepcut> but I am not sure what to sell yet<br />
<Riastradh> Arrows!<br />
<stepcut> "For just 5 easy payments of $29.95 you can learn haskell in my fun and easy video series"<br />
<stepcut> "You'll have the biggest Monads on your block!"<br />
<stepcut> "Do you want your own house, yacht, or beowolf cluster? Of course you do! With the skills you will learn in my haskell course, and 10 million dollars, you can get all these things AND MORE!"<br />
<blackdog> "Destroy your lucrative career as a Java programmer: Learn Haskell!"<br />
<clausen> how about a spiritual add?<br />
<clausen> "the purity of haskell helped me to deal with the kids, work and the stress of a fast-pace life"<br />
<blackdog> there must be a way to use haskell to sell exercise equipment. they've used everything else.<br />
<stepcut> "I used to be a fat lazy slob, but now, thanks to haskell, I am fully functional..."<br />
<Riastradh> '...and I can still be lazy!'<br />
<br />
----<br />
<br />
<Igloo> Syn: You're looking at how WASH works and are in charge of the cabal project, and you're asking /us/ if cabal 0.1 will handle WASH? :-)<br />
<br />
----<br />
<br />
seen on #java:<br />
<br />
(14:21:13) ricky_clarkson: Is Haskell an interface between programming languages and academics?<br />
<br />
----<br />
<br />
roconnor has joined #haskell<br />
<roconnor> ?<br />
<Riastradh> !<br />
<roconnor> oh, nevermind. I figured it out.<br />
<br />
----<br />
<br />
<Igloo> Oh, I'm going to sue you for emotional trauma, BTW<br />
<Marvin--> uh-oh<br />
<Igloo> I had to use unsafeCoerce# 3 times to write my gtk2hs program<br />
<Marvin--> ouch<br />
<Igloo> I think I'll be scarred for life<br />
<Marvin--> :-/<br />
<br />
----<br />
<br />
The acronym TMI is short for Too Much Information!<br />
<br />
<desrt> wtf. i just opened up my underwear drawer and there was a network card in it<br />
<shapr> desrt: you're a sick sick puppy<br />
<earthy> TMI<br />
<earthy> I won't be borrowing any hardware of desrt anytime in the future, that's for sure ;)<br />
<desrt> earthy; it's all cool. it was in with the socks<br />
<br />
----<br />
<br />
<desrt> how do i turn on PIC code generation for ghc?<br />
<shapr> -fPIC maybe?<br />
<desrt> no<br />
<shapr> -fThaller ?<br />
<desrt> ghc-6.2.2: unrecognised flags: -fThaller<br />
<desrt> :(<br />
<br />
----<br />
<br />
Just after a discussion of Microsoft's involvement in the Haskell world...<br />
<br />
<CosmicRay> Is there a way to, say, convert from a Word32 to a Word8 when I know the data in question will fit in a Word8?<br />
<drlion> CosmicRay: just open the file and Word will ask you to convert it<br />
<br />
----<br />
<br />
<Philippa> I'm fed up of writing uglyprinters for values inside an interpreter<br />
<br />
----<br />
<br />
<kristnjov> QuickCheck is god<br />
<nowiki>*</nowiki> earthy thinks kristnjov has a *weird* religion<br />
<kristnjov> it's called hughes-ism<br />
<kristnjov> a bit new age<br />
<blackdog> this y combinator, which was given to you for the recursion of sins<br />
<earthy> lead me not into global state<br />
<blackdog> yea, though I should walk in the valley of imperative code, I shall fear no evil, for your monad comforts me still<br />
<br />
----<br />
<br />
ISAGN is irc-speak for "I see a great need"<br />
<br />
<nowiki>*</nowiki> shapr throws a lambda boomerang<br />
<Igloo> ISAGN<br />
<shapr> Maybe if ICFP is in .au one year, they can give them away as the entrance gift.<br />
<Igloo> That sounds dangerous. Best to give them away as exit gifts<br />
<ski> or moooonad didgeridoos<br />
<br />
----<br />
<br />
<jemfinch|lambda> maybe I'll write an IRC bot in Haskell or SML.<br />
<dash> what's wrong with lambdabot?<br />
<dash> other than an excess of sarcasm<br />
<br />
----<br />
<br />
during a discussion of endomorphisms, hylomorphisms, catamorphisms, anamorphisms...<br />
<br />
<stepcut> endo-hylo-cata-ana-expi-ali-docious<br />
<br />
----<br />
<br />
<edi> What's SPJ ?<br />
<jadrian> Simon P. Jones<br />
<jadrian> edi: http://research.microsoft.com/Users/simonpj/<br />
<shapr> SPJ is a large part of the reason Haskell is so cool.<br />
<shapr> I'm an obsessive research paper downloader/reader, and I still haven't read everything I have on-disk by SPJ.<br />
<jadrian> shapr: I think SPJ is an obsessive paper uploader/writer, so it's going to be tough competition :)<br />
<br />
----<br />
<br />
<shapr> Tom Lord is darcs' archenemy!<br />
<CosmicRay> shapr: and he's also carpal tunnel's best friend.<br />
<br />
----<br />
<br />
<pesco> I'm currently reading Asimov's Foundation trilogy and Haskell strangely reminds me of the Foundation. I'm just wondering how "avoid success at all costs" fits into the picture.<br />
<shapr> speed of change<br />
<pesco> Exactly!<br />
<shapr> Not sure if that fits into the Foundation trilogy though.<br />
<pesco> Of course! They don't strive to expand and conquer rapidly.<br />
<pesco> They just follow the plan.<br />
<nowiki>*</nowiki> shapr tries to remember all the details of Hari Seldon's plan.<br />
<Igloo> And every year the image of SPJ appears at HW to impart new knowledge upon us...<br />
<Igloo> And it looks so real!<br />
<br />
----<br />
<br />
?CosmicRay introduces us to his treacherous megahal bot...<br />
<br />
<Pseudonym> megamonad, what is haskell?<br />
<MegaMonad> Pseudonym: Well, i'd ask john hughes about using haskell actually.<br />
<Pseudonym> Good advice.<br />
<Pseudonym> megamonad, what is scheme?<br />
<MegaMonad> Pseudonym: Man i love scheme.. So i'll do freelance coding of this is a neat solution.<br />
<Riastradh> MegaMonad, but what _is_ Haskell?<br />
<MegaMonad> Riastradh: It's is always stupid peoples to do this in haskell.<br />
<br />
----<br />
<br />
<bringert> I think the main problem with haskell is that memory use can be hard to predict<br />
<bringert> don't get me wrong, I find it the best language for most things<br />
<bringert> sure, Java uses lots of memory, but I find it easier to predict memory use in java<br />
<bringert> i.e. always lots of it :)<br />
<br />
----<br />
<br />
<lyceen> I speak english, german french and dutch lol<br />
<ibid> what's this language "lol"? never heard<br />
<Lemmih> ibid: It's from the strange land of counter-strike players and noobs.<br />
<ibid> Lemmih: figures<br />
<ibid> are there different dialects, english lol, german lol, and perhaps ... dutch lol?<br />
<Lemmih> I think it means 'end statement' or ';' from C.<br />
<br />
----<br />
<br />
"Haskell is the least-broken programming language available today."<br />
-- Havoc Pennington http://ometer.com/books.html<br />
<br />
----<br />
<br />
<Pseudonym> Ah, poor spouse of mine.<br />
<Pseudonym> She's hit a Windows bug where every few minutes, without fail, it tells her that it's found a new printer.<br />
<Pseudonym> The one which is already installed.<br />
<Pseudonym> "It's like Chinese water torture!"<br />
<Pseudonym> "GOD MAKE IT STOP!!!!!!!"<br />
<Pseudonym> I tried to explain to her that God has no jurisdiction over Windows, and she should talk to the other guy instead. She was not impressed.<br />
<br />
----<br />
<br />
<chip> It seems to me that the authors of the C++ template rules learned Haskell, then got drunk and added it to C++<br />
<chip> process _ _ target "dict" _ = do<br />
<chip> process _ _ target "dict-help" rest = do<br />
<chip> process _ _ target cmd rest = do<br />
<chip> I could spell that in about a screen of C++ templates. Except for the string part. It'd have to be basic values like integers, or enums, or something else that's known and comparable at compile time.<br />
<br />
----<br />
<br />
"I spent about an hour figuring out how to encode things, and working through the type errors, and then of course, it just worked. Yes, I know that this is exactly what haskell is all about, so of course it worked. But it felt so<br />
good to experience it, instead of just hearing about it." -- http://www.kimbly.com/blog/000030.html<br />
<br />
----<br />
<br />
<the_learner> CAN HASKELL BE USED NOW IN A STARTUP TO MAKE MONEY<br />
<wli> the_learner: haskell.org is indeed the root of all MAKE.MONEY.FAST methods<br />
<the_learner> NICE<br />
<the_learner> OK PERL OR HASKELL<br />
<wli> the_learner: ISN'T IT?<br />
<musasabi> I think that making money has little to do with technical quality or the lack of that ;)<br />
<wli> the_learner: HASKELL OF COURSE<br />
<the_learner> HASKELL SEEMS TO HAVE LOTS OF UNFINISHED SUPPORT LIBARY<br />
<the_learner> OK<br />
<the_learner> GNIGHT 4 NOW<br />
<mflux> it's a darn shame I've sacrificed my caps lock for other purposes :-/<br />
<wli> the_learner: HASKELL DOESN'T NEED THE SUPPORT LIBRARIES; ITS ABSTRACTIONS ARE HIGHER-LEVEL<br />
<br />
----<br />
<br />
<Gahhh> monads are usually a personal experience.<br />
<br />
----<br />
<br />
<shapr> I've tried to teach people autodidactism, but I've realized they have to learn it for themselves.<br />
<br />
----<br />
<br />
<Pseudonym> OK, so I try to find stylesheets for magazine-type documents.<br />
<Pseudonym> And I search for "latex magazine".<br />
<Pseudonym> There are some weird magazines out there.<br />
<br />
----<br />
<br />
<SyntaxNinja> Fromagxo: NOT is not not in haskell, nor is "!", but rather, not.<br />
<br />
----<br />
<br />
<nowiki>*</nowiki> autrijus stares at type Eval x = forall r. ContT r (ReaderT x IO) (ReaderT x IO x) and feels very lost<br />
<shapr> Didn't you write that code?<br />
<autrijus> yeah. and it works<br />
<autrijus> I just don't know what it means.<br />
<br />
----<br />
<br />
<SyntaxNinja> I think that the compiler authors will fly here from england just to kill me if I did that<br />
<br />
----<br />
<br />
<samc__> monads are hard, let's go shopping<br />
<br />
----<br />
<br />
<desrt> it was sort of funny. i was sitting in the optimisation lab once and wolfram came in and started talking to wolfgang in german<br />
<desrt> so i'm like "it's awful rude you know, speaking a language that i don't understand right in front of me"<br />
<desrt> so they switch to english, but they were talking about category theory, so i still didn't understand them :(<br />
<br />
----<br />
<br />
"There is a VCS named darcs, which is much more flexible, but is specced using quantum physics language and written in a scary language called Haskell."<br />
<br />
-- AutrijusTang at [WWW]A Plan for Pugs<br />
<br />
Is it just me or does this so crystallize the popular view of Haskell? -- DerekElkins<br />
<br />
----<br />
<br />
After a long series of questions on #haskell from someone writing their own language:<br />
<br />
<autrijus> I think Haskell excels at everything but user base :)<br />
<br />
----<br />
<br />
<nowiki>*</nowiki> Darius imagines XSLT programmers say "It's a one pager" the way most other programmers say "It's a one liner".<br />
<br />
----<br />
<br />
<Forest> why do they make condoms with different smells ?<br />
<Lemmih> Is that a lead-in to a joke or a real question?<br />
<Forest> it's a question<br />
<RemiTurk> now, a question back to Forest: what's its relation to haskell?<br />
<Forest> RemiTurk: learning haskell is a kind of f...ing<br />
<Forest> for first time<br />
<bringert> Forest: how so?<br />
<Forest> bringert: i meant for brains<br />
<bringert> it's awkward the first time, but as you go along you gain experience and confidence. most people enjoy it enough that they continue doing it for the rest of their lives.<br />
<br />
----<br />
<br />
<jjang> Lemmih: dont u have a sourceforge page or so for the module?<br />
<Heffalump> ick, he said sourceforge :-)<br />
<Lemmih> jjang: It's just a small pet project. Nothing serious.<br />
<jjang> why not make it serious<br />
<Lemmih> jjang: And shapr is kinda like sourceforge.<br />
<jjang> ok<br />
<jjang> never heard of shapr<br />
<Heffalump> it's much more intelligent<br />
<Heffalump> better designed<br />
<Heffalump> a touch eccentric, perhaps<br />
<jjang> shapr.org?<br />
<Heffalump> even has a bot on the channel<br />
<vincenz> jjang: shapr is a concept<br />
<jjang> oh<br />
<br />
----<br />
<br />
<shapr> In my experience, Flash is mostly used as the hi-tek replacement for <BLINK><br />
<br />
----<br />
<br />
Life is Hard, But Life is Harder When You're Dumb -- The Austin Lounge Lizards<br />
<br />
----<br />
<br />
seen on #perl6<br />
<br />
<cognominal> autrijus: what is the GADT ,entionned in your journal?<br />
<cognominal> stands, for Glasgow Abstract Data Tree?<br />
<br />
----<br />
<br />
<nowiki>*</nowiki> dons keeps typing 'darcs' when he really means to type 'cvs'<br />
<blackdog> the rest of the world keeps typing cvs when they should be typing darcs...<br />
<br />
----<br />
<br />
<sethk> Are nomads the reproductive organs of Haskell? After all, something does go in and something else usually comes out... ok, kind of lame, but it is 5 AM.<br />
<br />
----<br />
<br />
Refering to typed lambda calculus as "plain ol' code" may be a sign that I need to re-examine some of my prejudices about formalisms. :-) -- LukeGorrie<br />
<br />
http://lambda-the-ultimate.org/node/view/92/536#comment-536<br />
<br />
----<br />
<br />
<pesco> Heh, to deprecate means "to ward off by prayer" in its latin root. Hehe.<br />
<br />
----<br />
<br />
<Gahhh> I told my boss that I had learned Haskell and it made me a better programmer, he gave me the puzzled look you give to homeless people claiming to be Jesus.<br />
<br />
----<br />
<br />
<shapr> Oleg will do something terrifying like implementing type checking in tcp/ip checksums on the router level through some emergent property of BGP and he'll do it all with HSP!<br />
<br />
----<br />
<br />
seen on #debian-devel<br />
<br />
<dilinger> trave11er: CosmicRay's weblog hasn't led me astray yet :P<br />
<trave11er> dilinger: i cannot trust people who can write a 100+ line haskell program :-)<br />
<trave11er> that's almost a legal definition of insanity<br />
<Igloo> You're right; Haskell is such a concise, elegant language that anyone who stretches a program beyond 100+ lines is clearly doing something wrong<br />
<br />
----<br />
<br />
<Huschi> is there a good way to make the first argument of a function the last one?<br />
<skew> Huschi: hand the other party in the argument a gun<br />
<br />
----<br />
<br />
<blackdog> kallo, kallay: my grilf dragged me along to a ceramics class, and I now have a mug with a lambda on one side and the legend "go away, or i will replace you with a trivial lambda expression" on the other.<br />
<br />
(grilf == girlfriend I assume?) (your assumption is correct. i shall get some pictures and post. (unfortunately, i've just realised that the lambda looks an awful lot like the half-life logo, so i'm expecting some confused faces.) --blackdog (Yay confusion! Lambda actually *is* the symbol for half-life. Also the nuclear one, that is.) (I don't know why this page contains so much irrelevant detail))<br />
<br />
----<br />
<br />
I'm personally of the opinion that functional programming makes it even harder to shoot yourself in the foot, but when you do, all that's left are a few strands of red goo dangling from the shattered remains of your brain pan.<br />
<br />
--Mike Stone in http://www.perlmonks.org/?node_id=450922<br />
<br />
----<br />
<br />
<wagle> A math professor I once worked for asked me several years ago what I was doing these days. I must have said something like "anything but computer science". He asked "why's that?" I spouted passionately at length why not. He said something like "oh, computer science IS your field!"<br />
<br />
----<br />
<br />
(17:20:51) JohnMeacham: The Hierchical Modules report does contain a section about how it maps to the filesystem, but it specifically says that this is not a part of the specification and just a possible implementation.<br />
(17:21:15) JohnMeacham: This is why I felt okay about jhc breaking it :)<br />
(17:21:25) SamB: nobody is crazy enough to implement it elsehow, though<br />
(17:21:42) CosmicRay: SamB: some crazy people hang out here<br />
<br />
----<br />
<br />
<skew> I think it's pretty neat how other languages struggle and sweat to add new stuff like continuations, and in Haskell somebody just applies about 20,000 IQ-years and invents another monad<br />
<br />
----<br />
<br />
<JohnMeacham> That's a lot of cows.<br />
<br />
----<br />
<br />
<shapr> Where's my socks!?<br />
<shapr> Finding my socks seems to be an NP-complete problem to me.<br />
<br />
----<br />
<br />
<nowiki>*</nowiki> dons X11s his curses installation<br />
<br />
----<br />
<br />
<lambdabot> I'm sitting on my SPEED QUEEN ... To me, it's ENJOYABLE ... I'm WARM<br />
<lambdabot> ... I'm VIBRATORY ...<br />
<dons> yikes!<br />
<dons> hmm. looks like @vixen has been talking to @yow<br />
<br />
----<br />
<br />
seen on #perl6<br />
<br />
<autrijus> using Haskell is like having the power of Reason.<br />
<autrijus> all bad guys listen to Reason.<br />
<br />
----<br />
<br />
(2005.05.30) Lambdabot is female<br />
<br />
<boegel> oh, okay, you're a experienced user then... ever heard about lambdabot ?<br />
<boegel> she's cool<br />
<SyntaxNinja> boegel: lambdabot is a girl?<br />
<boegel> SyntaxNinja: yeah, sure, why not ? :)<br />
<Biker> boegel: I have seen it working here... not used it myself though<br />
<Biker> yeah... she could be :)<br />
<br />
----<br />
<br />
<xerox> What could it mean something like this? "<nowiki><TITLE>Error</TITLE><BODY><H1>Error</H1>FW-1 at sentry2.york.ac.uk: Access denied.</BODY></nowiki>"<br />
<Itkovian> that you're screwed?<br />
<boegel> a HTML-page saying some error has occured ?<br />
<dblhelix> is this a quiz?<br />
<br />
----<br />
<br />
seen on #perl6<br />
<br />
<Limbic_Region> learning Haskell to me is akin to learning an alien (as in space) language<br />
<br />
----<br />
<br />
On #haskell:<br />
<br />
<xerox> I can't read other languages than Haskell anymore, I have the _physical_ need to know the type of the functions used.<br />
<br />
----<br />
<br />
<olliej> java is a great language<br />
<olliej> i like to eat toothpaste<br />
<olliej> :)<br />
<br />
----<br />
<br />
<shapr> Yeah, it does require more than an oleg of type-hackery.<br />
<poetix> oleg's now a unit?<br />
<autrijus> is oleg an unit now?<br />
<shapr> Yup, a rather large unit of type-hackery too.<br />
<br />
----<br />
<br />
<tomdavie> buh... I wish people would stop asking for my source... I keep having to do a make realclean, and then spending half an hour buinding again :(<br />
<nowiki>*</nowiki> earthy grinz<br />
<tomdavie> I suppose I could just back up the work... but hey... that would be inteligent<br />
<earthy> why not manage the stuff with darcs and have a clean tree and a build tree? :)<br />
<earthy> oh right, we don't want to think, we're lazy functional programmers. :P<br />
<br />
----<br />
<br />
<boegel> [BAF64]: you should ask lambdabot, she seems to be willing to donate<br />
<Igloo> [BAF64]: Are you here purely to beg for donations?<br />
<mauke> @vixen are you willing to donate?<br />
<[BAF64]> I'm not begging for donations.<br />
<xs_> oh, lilo needs rent?<br />
<lambdabot> yes, i am<br />
<Igloo> [BAF64]: If you're not here to talk about Haskell, please can you leave?<br />
<[BAF64]> Igloo, sure<br />
<[BAF64]> lambdabot, if you want more info, join #freenode<br />
<nowiki>*</nowiki> [BAF64] (ferrisr@69-169-198-47.sbtnvt.adelphia.net) has left #haskell ("Leaving")<br />
<Igloo> lol!<br />
<br />
----<br />
<br />
<autrijus> Perl: "Easy things are easy, hard things are possible"<br />
<autrijus> Haskell: "Hard things are easy, the impossible just happened"<br />
<br />
----<br />
<br />
<gennet1> i guess i just want the one language to rule them all ;)<br />
<earthy> one language to rule them all, one language to find them, one language to bring them all and in the darkness enthrall them, in the land of ICFP, where the programmers lie?<br />
<br />
----<br />
<br />
Sleep deprivation is bad!<br />
<br />
<Speck> Oh my god. Crickets in the basement.<br />
<Speck> Hundreds of them.<br />
<br />
----<br />
<br />
A http://www.cs.vu.nl/boilerplate/ parody:<br />
<br />
<shapr> autrijus: What's the title of your fabled article? Boil your ScratchPad with Style?<br />
<autrijus> shapr: it's "Boil your scratchpad", "Boil other people's scratchpads", and "Boil your scratchpad with proles". The full name of the first one is "Boil your scratchpad - Genetic frogging in Haskell"<br />
<Pseudonym> Aren't you supposed to boil a frog slowly?<br />
<autrijus> right, that's why genetic frogging is slow<br />
<Pseudonym> And what do the proles have to do with it?<br />
<autrijus> the idea is no-one with class -- not even middle class -- will bother themselves with frog boiling; it offends their bourgeois taste. so need proles to do that<br />
<dons> I see, boiling scratchpads without class<br />
<autrijus> yup.<br />
<br />
----<br />
<br />
<Speck> "That's like cheating. It isn't even programming. You just tell it what to do and it does it." -- My friend upon seeing some Haskell code<br />
<br />
----<br />
<br />
<Beelsebob> DAMN IT! There's a fly *in* my monitor<br />
<Beelsebob> it's somehow got between the LCD and the backlight<br />
<Beelsebob> it seems to have got scared by me chasing it with a cursor<br />
<Beelsebob> ARGH! There's two now<br />
<Beelsebob> has some fly made a nest in there or something?<br />
<Beelsebob> I may have to take this monitor apart<br />
<br />
----<br />
<br />
<Cale> stepcut: You know a library is good when just reading about it removes the particular task it performs from your life altogether.<br />
<br />
----<br />
<br />
<autrijus> (type inference)++ # no need to be a strong typist to enjoy strong typing<br />
<br />
----<br />
<br />
From http://www.perl.com/pub/a/2005/07/28/test_builder_p6.html<br />
<br />
"My productivity increased when Autrijus told me about Haskell's trace function.<br />
He called it a refreshing desert in the oasis of referential transparency."<br />
-- chromatic, on hacking Pugs to implement a unit test framework for Perl 6<br />
<br />
----<br />
<br />
Seen on #haskell:<br />
<br />
goron: Ah.. the halting problem is easy. Step 1 wait an infinite time Step2 Check whether the program halted.<br />
<br />
----<br />
<br />
<darix> the problem with haskell is<br />
<darix> the learning curve is like a mountain in the himalaya ...<br />
<darix> nearly 90degree and close to 8000 m<br />
<darix> but standing up the hill just rocks ;)<br />
<br />
----<br />
<br />
*** mwc (n=matt@CPE0030654f85d8-CM00137189c512.cpe.net.cable.rogers.com) has joined channel #haskell<br />
<mwc> I think that we ought to treat cats that have been sprayed by skunk with the same method as horses with broken legs.<br />
<mwc> After 20 minutes of wet cat Judo, I'm utterly convinced they don't like the common treatment<br />
<mwc> after all that biting, scratching, and attempts to jump out despite me holding its chest down, I decided not to bother drying the little bugger off<br />
<mwc> just threw outside to air dry<br />
<mwc> although after that ordeal the clothes dryer was looking MIGHTY attractive<br />
<mwc> so, that was how my day got started<br />
<br />
----<br />
<br />
<exa> so did haskell have an eval function?<br />
<exa> i remember something like a generic programming tool that allowed you to construct syntax trees but i'm not sure<br />
<nowiki>*</nowiki> exa loves genericity!<br />
<exa> +1 for type classes :)<br />
<stepcut> exa: dons wrote a hsplugins thing that has an eval function<br />
<Philippa> and template haskell effectively has compile-time eval<br />
<autrijus> and you can load hsplugins during compile time too.<br />
<autrijus> (via runIO)<br />
<Philippa> and use TH in plugins<br />
<autrijus> and generally become dangerously close to insanity<br />
<Philippa> I mean really, once we have boxy types and proper existentials... what'll the point of smalltalk /be/? :-)<br />
<br />
----<br />
<br />
On #haskell:<br />
<br />
Heffalump: I think you'll find I'm trolling, not flaming. Pay attention.<br />
...<br />
dcoutts: Heffalump, yeah, you can't really troll when we know you. Come back under another nick and it might work.<br />
<br />
----<br />
<br />
On #haskell:<br />
<br />
22:17 * poetix thinks xerox should write a book on UI programming in Haskell<br />
22:17 < Marty> that's what i'm saying ;)<br />
22:17 < xerox> A _book_ ?!<br />
22:17 < poetix> Get it published by O'Reilly<br />
22:18 < xerox> We could choose an animal for Haskell that way!<br />
22:18 < poetix> Exactly! But which animal?<br />
22:18 < vegai> Sloth?<br />
22:18 < vegai> isn't it obvious? =)<br />
22:18 < poetix> Slime mold?<br />
22:18 < xerox> Something between myth, fantasy and dream.<br />
22:18 < vininim> a catterpillar =p<br />
22:18 < basti_> -g-<br />
22:18 < basti_> with a hookah<br />
22:19 < poetix> Well, we know Haskell is a drug<br />
22:19 < xerox> Yes.<br />
22:19 < basti_> ohh.<br />
22:19 < xerox> So.. hypotic toad?<br />
22:19 < basti_> comparable to what?<br />
22:19 < xerox> *hypnotic tad<br />
22:19 < poetix> liftIO makes you larger, and foldR makes you small<br />
22:19 < poetix> And the id that mother gives you, doesn't do anything at all<br />
22:20 < vininim> o_o<br />
22:20 < basti_> lol<br />
22:20 < poetix> I am really not as old as quoting that makes me sound...<br />
<br />
----<br />
<br />
Seen is #haskell-blah<br />
<br />
poetix_: In ancient Athens, they used to punish adulterers by forcing radishes up their rectums<br />
boegel: poetix_: sounds like fun !<br />
<br />
----<br />
<br />
< int-e> @eval takeWhile ([]/=) $ map (take 2) $ iterate (drop 2)<br />
< schyffe> thanks<br />
< Igloo> unfoldr (\xs -> if null xs then Nothing else Just (splitAt 2 xs)) -- unfoldr strikes again!<br />
< int-e> neat. thanks Igloo<br />
<nowiki>*</nowiki> Heffalump thinks int-e's is clearer<br />
< Igloo> Yes, but mine uses unfoldr<br />
< Heffalump> precisely :-)<br />
< Igloo> I think you're missing the point here :-)<br />
< int-e> so null == ([]/=)<br />
< Heffalump> no, null == not.([]/=)<br />
<br />
----<br />
<br />
<ricebowl> what does >>= do?<br />
<basti_> ricebowl: monads are cute pink fuzzy little things.<br />
<gzl> with plutonium inside.<br />
<br />
----<br />
<br />
Seen on #ruby-lang<br />
<br />
<shevegen> haskell is cool but i personally find it very difficult<br />
<GnuVince> That being said, I hear it's a very nice and fun language, although some things are hard to do in a purely functionnal way<br />
<chris2> i prefer less strict languages<br />
<br />
----<br />
<br />
During a heated discussion:<br />
<br />
23:34 < shapr> Heffalump: You said that my assertions do Haskell a disservice. How does that work?<br />
23:35 < Heffalump> because if people believe you and then discover that you are wrong, they will be more suspicious of future claims by others<br />
23:35 < int-e> work_metaperl: try selling sodas and popcorn.<br />
23:36 < work_metaperl> then Heffalump and shapr will throw them at each other :)<br />
23:36 < Heffalump> eating it is better<br />
23:37 < autrijus> I'd like some pushcorns<br />
23:37 < xerox> Ã²karma- autrijus<br />
23:37 < autrijus> popcorns are overrated.<br />
23:37 < work_metaperl> the only use for soda is throwing it... either throwing it up or throwing it out<br />
23:37 < work_metaperl> it does not belong in the human body<br />
23:37 < shapr> Heffalump: So what? I'm not Haskell. We all just try to figure stuff out the best we can. I'm doing my best, I assume you're doing yours.<br />
23:37 < wagle> throwing popcorn in the exception monad?<br />
23:37 < work_metaperl> push corn, pop corn, unshift corn, shift corn<br />
23:38 < xerox> resetcorns<br />
23:38 < basti_> argh<br />
23:38 < autrijus> splicecorns<br />
23:38 < work_metaperl> :)<br />
23:38 < wagle> cornads<br />
23:38 < basti_> call/cccorns<br />
23:38 < work_metaperl> LOL<br />
23:38 < xerox> call-with-current-corn<br />
23:38 < work_metaperl> cornads .... LOLOLOL<br />
23:38 < Oejet> cocorns<br />
23:38 < xerox> ahah!<br />
23:38 < work_metaperl> lol<br />
23:38 < int-e> cornads are generalized stacks?<br />
23:38 < xerox> co-cornads<br />
23:38 < Heffalump> shapr: I'm just commenting on your opinions. I obviously don't have any power to make you act differently.<br />
23:38 < xerox> (along the lines of co-monads)<br />
23:38 < wagle> xerox: rnads<br />
23:38 < Oejet> xerox: Too late. :-P<br />
23:38 < astrolabe> Online discussions escalate too easily because of lack of non-verbal signals.<br />
23:38 < work_metaperl> thats so corny<br />
<br />
----<br />
<br />
<sethk> what's the definition of a supercombinator? what makes it super?<br />
<dave_m> sethk: supercombinators are only vulnerable to kryptonite<br />
<br />
----<br />
<br />
<ulfdoz> schemers are strange.<br />
<sieni> ulfdoz: why the call/cc would you think that?<br />
<br />
----<br />
<br />
<ValarQ> Oejet: i looked on a webpage that sells books for a haskell book today, i found one and on the page there was a note saying that people who bought that book also bought some book called "the paincarrier" (rough translation)<br />
<Philippa_> haskell's rare enough still that it doesn't take much to give a bookseller a link between it and (say) BDSM<br />
<Philippa_> hell, the only reason I've not contributed to that one myself is I've never bought a book on Haskell<br />
<br />
----<br />
<br />
<nowiki>*</nowiki> Korollary map hug #haskell<br />
<br />
----<br />
<br />
dons discovers the Google Maps API:<br />
<br />
<dons> and you can just zoom in until you see the locations at full res. huh. so this is how I track my enemies<br />
<br />
----<br />
<br />
Another C++ user enters the channel...<br />
<br />
<Megzl> The first task for Haskell would be to implement an L-System.<br />
<Cale> xerox and I wrote a nice L-System generator<br />
<Megzl> Show me the code.<br />
<Megzl> I'm interested in L-Systems; I've spent a ton of time coding them in C++.<br />
<Cale> http://www.haskell.org/hawiki/HaskellIrcPastePage<br />
<Megzl> That's too little code.<br />
<Cale> unfortunately, it involves some abstractions you don't know yet :)<br />
<Megzl> Where are all the other rules besides F.<br />
<br />
----<br />
<br />
No longer Test Driven Development, but intead:<br />
<br />
<autrijus> TDD is actually Tolkien-Driven Development.<br />
<br />
----<br />
<br />
<sieni> is yi+hide trying to be a replacement of emacs for haskell or are people going to incorporate all standard ide suckiness to hide as well?<br />
<dons> emacs for haskell, yes<br />
<dons> suckiness is an optional plugin<br />
<dons> you'll need to download that first<br />
<br />
----<br />
<br />
Seen on #perl6, discussing the weaponry of Haskell<br />
<br />
<autrijus> when I'm preparing the slides... it occured to me that most of the perculiar features in hs is there just so we can fearlessly golf^Wrefactor things, without putting the entire program logic into one's head<br />
<autrijus> aka the power of Reason -- as in Snow Crash<br />
<gaal> http://www.clubhyper.com/reference/images/Gau8a_a.jpg<br />
<gaal> it features strong typing, too, in a way.<br />
<gaal> you definitely know when you're at the wrong end of this fellow.<br />
<autrijus> and static, too<br />
<autrijus> if you stay at the right end you'll probably remain there<br />
<gaal> yes, it's very haskellish to call something static when it fires fifty rounds a second.<br />
<nowiki>*</nowiki> autrijus goes lifting -- I mean fmapping -- this picture into the talk<br />
<br />
----<br />
<br />
<musasabi> Haskell is pure Joy, and joy can be implemented in Haskell.<br />
<br />
----<br />
<br />
<sethk> I used to play in fairly loud bands but I always made sure the speakers were between the audience and me<br />
<sethk> Once they found a seriously high person _inside_ one of the big bass cabinets<br />
<br />
----<br />
<br />
<EdLin> obj c is a sort of cross between smalltalk and c<br />
<dfgp> If you fed Smalltalk lead until it became retarded. ;)<br />
<br />
----<br />
<br />
<dons> hmm, what's the opposite of serialising something ?<br />
<stefanw> deserialising?<br />
<dons> :( yeah, that's currently the function name I have. but it's ugly<br />
<dons> maybe i could use reify and, umm, what's the opposite of reifiying something?<br />
<ski> reflect<br />
<dons> ah, right.<br />
<nowiki>*</nowiki> ski thinks that's a bad idea, though<br />
<dons> hehe.<br />
<ski> hm ..<br />
<ski> 'deify' and 'deflect' ?<br />
<br />
----<br />
<br />
<JohnMeacham> not haskell related but interesting if you know wolfram or his work: http://www.cscs.umich.edu/~crshalizi/reviews/wolfram/<br />
Heh... it makes me wonder what sort of things we will be publishing in our quackery years,<br />
"Monads don't emulate the world, the world is a poor emulation of a monad."<br />
"The second law of thermodynamics as expressed via functional dependencies"<br />
<JohnMeacham> of course any minute now oleg is going to come along and actually express the second law of thermodynamics via functional dependencies as a purely incidental part of improving HList syntax or something.<br />
<br />
----<br />
<br />
<basti_> google has kind of a personality<br />
<basti_> a little like one the "great elder gods" in the cthuluh myth i think.<br />
<br />
----<br />
<br />
<astrolabe> lazyness is next to godliness<br />
<br />
----<br />
<br />
*** BigMike04 (i=BigMike0@d64-180-58-123.bchsia.telus.net) has joined channel #haskell<br />
<BigMike04> hey<br />
<BigMike04> does anyone can give a newbie here a guide to hack?<br />
<astrolabe> @learn<br />
<lambdabot> http://www.haskell.org/learning.html<br />
<BigMike04> @learn<br />
<lambdabot> http://www.haskell.org/learning.html<br />
<BigMike04> @learn<br />
<lambdabot> http://www.haskell.org/learning.html<br />
<BigMike04> opps sorry<br />
<astrolabe> :)<br />
<astrolabe> Give one of those a try<br />
<ski> @google yet another haskell tutorial<br />
<lambdabot> http://www.isi.edu/~hdaume/htut/<br />
<ski> @google haskell c tutorial<br />
<lambdabot> http://www.haskell.org/~pairwise/intro/intro.html<br />
<ulfdoz> Hack? He knows C!<br />
<ski> BigMike04 : check those out, too<br />
<BigMike04> i got one right here but it is exploit tut http://www.wifiscan.net/td/tutorials/exploits.htm<br />
<BigMike04> now, any of you guys actually hack?<br />
<Korollary> Ugh<br />
<Speck> I think we have different working definitions of "hack"<br />
<ulfdoz> I prefer "to program".<br />
<Korollary> "that" kind of hacking... umm no.<br />
<Lemmih> I so hope you're a bad joke.<br />
<astrolabe> You need to say 'where hack = ...'<br />
<Speck> the best advice I can give if you want to learn how to be a hax0r is to learn C. Maybe you'll get so distracted you come out a good programmer by mistake.<br />
<BigMike04> yes a friend told me that<br />
<BigMike04> im only 16 guys..the so far i have taken info tech..next year i will be in cisco<br />
<Speck> what would you do with your hacking knowledge?<br />
<Korollary> Why hack instead of program useful stuff like decent people ...<br />
<BigMike04> what will i do with the hacking knowledge? just like anyonem hack computers! lol im joking. i would use it in good use and not to mess around or anything.<br />
<astrolabe> LOL!<br />
<rep> hacking is fun.<br />
<ulfdoz> He watched 23. This evening it was broadcasted in germany.<br />
<rep> and you learn a lot<br />
<BigMike04> but yeah is cisco worth it?<br />
<yozora> hacking for a noble cause then huh<br />
<Speck> learn C, they probably have a channel somewhere. Haskell is horrible if you want to have dangerous knowledge -- you might accidentally hurt your manhood in Oleg's zipper, but you couldn't DDoS anyone with Haskell; your heap would explode.<br />
*** BigMike04 (i=BigMike0@d64-180-58-123.bchsia.telus.net) has left channel #haskell<br />
<br />
----<br />
<br />
<dons> oh, nice, david roundy is using ion.<br />
<dons> and tuomov is using darcs<br />
<dons> happy happy<br />
<br />
----<br />
<br />
<lispy> Me> "I worked 80 hours today";; TimeBot> "Timesheet updated."<br />
<br />
----<br />
<br />
<dcnstrct> alright people the choice is clear, even the #lisp people say go with haskell so I will<br />
<br />
----<br />
<br />
comparing what to what?<br />
<br />
<Cale> a bunch of oranges, one red<br />
<br />
----<br />
<br />
I tried to formalise a proof of rev (rev l) = l I found in W. Kluges book "Abstract Computing Machines - A Lambda Calculus Perspective" which is pretty much a 'Pimp My Ride' for SECD-machines. --Sebastian Hanowski<br />
<br />
----<br />
<br />
< ihope> data Badger = Badger Badger Badger | Mushroom<br />
< Philippa> Pattern match failure: Snake!<br />
<br />
(to those whom it might concern: this is a reference to a pretty bizarre swf animation that caused an epidemic a few times: http://www.badgerbadgerbadger.com/ )<br />
<br />
----<br />
<br />
<xerox> djinnModule type = askLennart ("write a function of this type: " ++ type) >>= \code -> replyBack code<br />
<br />
----<br />
<br />
< palomer> grr, sml can't derive Ord<br />
< palomer> sml is a pain to use sometimes<br />
< palomer> but sometimes it's a joy!<br />
< palomer> ugh, I take it back, it's a pain<br />
<br />
----<br />
<br />
Just checking:<br />
<br />
< pesco> @vixen PHP<br />
< lambdabot> hey, who did we fight in WWII besides Germany and Russia?<br />
<br />
----<br />
<br />
seen on #perl6:<br />
<br />
< azuroth> I did some of my C++ homework in haskell. teacher didn't like that :-( <br />
< Kattana> and this surprises you?<br />
<br />
----<br />
<br />
<jbc>: Phillipa - a parable: The chinese abacus has 5+2 beads in each column, allowing you to accumulate tens and carry them later. The japanese abacus has 4+1 beads - you carry NOW, dammit, no putting stuff down, don't be lazy. The haskell abacus Only has one bead, and it's not in the column you're using...<br />
<Philippa>: jbc: the haskell abacus has all the beads you want on an n-dimensional board and it'll clear up the mess for you<br />
<Philippa>: (but you're not allowed to move or change beads you've placed)<br />
<br />
----<br />
<br />
<ncalexan> Getting fed up with Haskell and picking up another language is like swapping your Greenpeace spouse for an abusive tyrant. Boy, does vegan sound good after beatings.<br />
<br />
----<br />
<br />
"In My Egotistical Opinion, most people's C programs should be<br />
indented six feet downward and covered with dirt."<br />
-- Blair P. Houghton<br />
<br />
----<br />
<br />
< Bobstopper> Assuming the universe will eventually die of heat death, counting will cease when that happens. So if you start counting now, you'll probably find the largest number (so long as nobody else has found a larger one yet)<br />
< Cale> what about faster ways to produce larger numbers?<br />
< Bobstopper> not after the heat death you can't :P<br />
< dave_m> don't you tell me what I can't do after the heat death of the universe<br />
<br />
----<br />
<br />
''sigfpe'': Haskell is so strict about type safety that randomly generated snippets of code that successfully typecheck are likely to do something useful, even if you've no idea what that useful thing is.</div>Ksfhttps://wiki.haskell.org/index.php?title=What_a_Monad_is_not&diff=40709What a Monad is not2011-06-30T02:34:32Z<p>Ksf: /* Monads are not about ordering/sequencing */</p>
<hr />
<div>==Warning==<br />
This page is currently an unprocessed braindump. Feel free to dump additional stuff or massage stuff into didactic pleasures.<br />
<br />
Also, don't be surprised if you leave this page more confused than before. That just means that it has successfully destroyed your false assumptions, or that you've fallen for some horrible inside joke. Beware of [[Zygohistomorphic prepromorphisms]]. Go for [http://ertes.de/articles/monads.html warm and fuzzy], instead.<br />
<br />
==Monads are not a good choice as topic for your first Haskell blog entry==<br />
...just accept that they're [http://blog.plover.com/prog/burritos.html burritos], and wait until later.<br />
<br />
==Monads are not a language feature==<br />
Really. They are defined in terms of Haskell, not Haskell in terms of them. Conversely,<br />
<br />
==Haskell doesn't need Monads==<br />
...well, apart from the current Haskell standard defining the way IO is done in terms of Monads: It could be done differently and still work.<br />
<br />
==Monads are not impure==<br />
...In no way whatsoever. You don't even need flexible morals to claim it. To be more specific, it's IO that's impure. That makes the IO monad impure. But that's not a general property of monads - just IO. And even then, we can pretend that Haskell is a purely functional description language for imperative programs. But we didn't want to employ flexible morals, now did we?<br />
<br />
==Monads are not about state==<br />
While it is certainly possible to abstract away explicit state passing by using a Monad, that's not what a monad is.<br />
<br />
(some elaboration needed -- Well, which monad most obviously uses no state at all?)<br />
<br />
==Monads are not about strictness==<br />
Monad operations (bind and return) have to be [[Non-strict semantics|non-strict]] in fact, always! However<br />
other operations can be specific to each monad.<br />
For instance some are strict (like IO), and some are non-strict (like []). Then there are some that come in multiple flavours, like State.<br />
<br />
Try the following:<br />
<br />
<haskell><br />
runState (sequence . repeat $ state (\x -> (x,x+1))) 0<br />
</haskell><br />
<br />
Having a look at the implementation of fixIO might be helpful, too.<br />
<br />
==Monads are not values==<br />
This point might be driven home best by pointing out that instance Monad Foo where ... is not a data type, but a declaration of a typeclass instance. However, to elaborate:<br />
<br />
Monads are not values in the same sense that addition and multiplication are not numbers, or, for that matter, an oven is not food: They capture a -- very specific -- relationship between values of a specific domain into a common abstraction. We're going to call these values monads manage ''mobits'', somewhat like this:<br />
<br />
<haskell><br />
type Mobit m a = Monad m => m a<br />
</haskell><br />
<br />
The IO monad manages mobits representing side-effects ("IO actions").<br />
<br />
The List monad manages mobits representing multiple values ("[a]")<br />
<br />
The Reader monads manages mobits that are pure computations that use asks to propagate information instead of explicit arguments<br />
<br />
...and while addition and multiplication are both monoids over the positive natural numbers, an oven is a monoid over food (Burned pizza doesn't concern us, here: Food stays food, even if you don't want to eat it.), a monad is a monoid object in a category of endofunctors: return is the unit, and join is the binary operation. It couldn't be more simple. If that confuses you, it might be helpful to see a Monad as a lax functor from a terminal bicategory.<br />
<br />
==Monads are not a replacement for applicative functors==<br />
Instead, every monad ''is'' an applicative functor (as well as a functor). It is considered good practice not to use >>= if all you need is <*>, or even fmap.<br />
<br />
Not confusing which features of monads are specific to monads only and which stem from applicative functors is vitally important for a deeper understanding of monads. As an example, the applicative functor interface of parser libraries can parse context-free grammars (and look just like EBNF), while the monadic interface can parse context-sensitive grammars: Monads allow you to influence further processing by inspecting the result of your parse. To understand why, have a look at the type of >>=. To understand why applicative functors by themselves are sufficient to track the current parsing position, have a look at the [http://www.cs.uu.nl/research/techreps/repo/CS-2008/2008-044.pdf uu-parsinglib tutorial (pdf)].<br />
<br />
The exact differences are elaborated in even greater detail in Brent Yorgey's excellent [[Typeclassopedia]].<br />
<br />
==Monads are not about ordering/sequencing==<br />
Monads are commonly used to order sequences of computations. But this is misleading. Just as you can use monads for state, or strictness, you can use them to order computations. But there are also commutative monads, like Maybe, that don't order anything. So ordering is not in any way essential to what a monad is.<br />
<br />
Let's have a look at what's meant by ordering. Consider an expression like<br />
<br />
<haskell><br />
let x = a<br />
y = b<br />
in f x y<br />
</haskell><br />
<br />
That gives the same result as<br />
<br />
<haskell><br />
let y = b<br />
x = a<br />
in f x y<br />
</haskell><br />
<br />
It doesn't matter what order we write the two bindings. But for doing I/O we'd like ordering. Monads allow use to express<br />
<br />
<haskell><br />
do<br />
x <- getChar<br />
y <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
and have it be different from<br />
<br />
<haskell><br />
do<br />
y <- getChar<br />
x <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
Unlike the first, the second example returns a pair of characters in the opposite order to which they were entered.<br />
<br />
It might help to meditate about the difference between 'assignment' and 'binding', right now.<br />
<br />
However, just to spoil the enlightenment you just attained, there are monads for which swapping the order of lines like this makes no difference: For example, the Maybe monad.<br />
<br />
So while it is correct to say that monads can be used to order operations, it would be wrong to say that monads are a mechanism for ordering operations.<br />
<br />
This notion of commutativity looks superficially very different from the familiar one in vanilla algebra where a+b=b+a. It's not about the fact that<br />
<br />
<haskell><br />
(Just 2 >> Just 3) == Just 3<br />
</haskell><br />
, implying <br />
<haskell><br />
(Just 2 >> Just 3) /= (Just 3 >> Just 2)<br />
</haskell><br />
<br />
This shouldn't be too surprising, though, as >> isn't the binary operation of some monoid: the algebraic properties of '''''join''''' are very close to those of + and incidentally, '''''join''''' is also the operation true category theorists tend to work with. They also know of bind, but don't use it a lot because, unlike programmers, they don't do any actual productive work.<br />
<br />
==See also==<br />
<br />
* [[Do notation considered harmful]]<br />
<br />
[[Category:FAQ]]</div>Ksfhttps://wiki.haskell.org/index.php?title=What_a_Monad_is_not&diff=40708What a Monad is not2011-06-30T02:33:42Z<p>Ksf: /* Monads are not about ordering/sequencing */</p>
<hr />
<div>==Warning==<br />
This page is currently an unprocessed braindump. Feel free to dump additional stuff or massage stuff into didactic pleasures.<br />
<br />
Also, don't be surprised if you leave this page more confused than before. That just means that it has successfully destroyed your false assumptions, or that you've fallen for some horrible inside joke. Beware of [[Zygohistomorphic prepromorphisms]]. Go for [http://ertes.de/articles/monads.html warm and fuzzy], instead.<br />
<br />
==Monads are not a good choice as topic for your first Haskell blog entry==<br />
...just accept that they're [http://blog.plover.com/prog/burritos.html burritos], and wait until later.<br />
<br />
==Monads are not a language feature==<br />
Really. They are defined in terms of Haskell, not Haskell in terms of them. Conversely,<br />
<br />
==Haskell doesn't need Monads==<br />
...well, apart from the current Haskell standard defining the way IO is done in terms of Monads: It could be done differently and still work.<br />
<br />
==Monads are not impure==<br />
...In no way whatsoever. You don't even need flexible morals to claim it. To be more specific, it's IO that's impure. That makes the IO monad impure. But that's not a general property of monads - just IO. And even then, we can pretend that Haskell is a purely functional description language for imperative programs. But we didn't want to employ flexible morals, now did we?<br />
<br />
==Monads are not about state==<br />
While it is certainly possible to abstract away explicit state passing by using a Monad, that's not what a monad is.<br />
<br />
(some elaboration needed -- Well, which monad most obviously uses no state at all?)<br />
<br />
==Monads are not about strictness==<br />
Monad operations (bind and return) have to be [[Non-strict semantics|non-strict]] in fact, always! However<br />
other operations can be specific to each monad.<br />
For instance some are strict (like IO), and some are non-strict (like []). Then there are some that come in multiple flavours, like State.<br />
<br />
Try the following:<br />
<br />
<haskell><br />
runState (sequence . repeat $ state (\x -> (x,x+1))) 0<br />
</haskell><br />
<br />
Having a look at the implementation of fixIO might be helpful, too.<br />
<br />
==Monads are not values==<br />
This point might be driven home best by pointing out that instance Monad Foo where ... is not a data type, but a declaration of a typeclass instance. However, to elaborate:<br />
<br />
Monads are not values in the same sense that addition and multiplication are not numbers, or, for that matter, an oven is not food: They capture a -- very specific -- relationship between values of a specific domain into a common abstraction. We're going to call these values monads manage ''mobits'', somewhat like this:<br />
<br />
<haskell><br />
type Mobit m a = Monad m => m a<br />
</haskell><br />
<br />
The IO monad manages mobits representing side-effects ("IO actions").<br />
<br />
The List monad manages mobits representing multiple values ("[a]")<br />
<br />
The Reader monads manages mobits that are pure computations that use asks to propagate information instead of explicit arguments<br />
<br />
...and while addition and multiplication are both monoids over the positive natural numbers, an oven is a monoid over food (Burned pizza doesn't concern us, here: Food stays food, even if you don't want to eat it.), a monad is a monoid object in a category of endofunctors: return is the unit, and join is the binary operation. It couldn't be more simple. If that confuses you, it might be helpful to see a Monad as a lax functor from a terminal bicategory.<br />
<br />
==Monads are not a replacement for applicative functors==<br />
Instead, every monad ''is'' an applicative functor (as well as a functor). It is considered good practice not to use >>= if all you need is <*>, or even fmap.<br />
<br />
Not confusing which features of monads are specific to monads only and which stem from applicative functors is vitally important for a deeper understanding of monads. As an example, the applicative functor interface of parser libraries can parse context-free grammars (and look just like EBNF), while the monadic interface can parse context-sensitive grammars: Monads allow you to influence further processing by inspecting the result of your parse. To understand why, have a look at the type of >>=. To understand why applicative functors by themselves are sufficient to track the current parsing position, have a look at the [http://www.cs.uu.nl/research/techreps/repo/CS-2008/2008-044.pdf uu-parsinglib tutorial (pdf)].<br />
<br />
The exact differences are elaborated in even greater detail in Brent Yorgey's excellent [[Typeclassopedia]].<br />
<br />
==Monads are not about ordering/sequencing==<br />
Monads are commonly used to order sequences of computations. But this is misleading. Just as you can use monads for state, or strictness, you can use them to order computations. But there are also commutative monads, like Maybe, that don't order anything. So ordering is not in any way essential to what a monad is.<br />
<br />
Let's have a look at what's meant by ordering. Consider an expression like<br />
<br />
<haskell><br />
let x = a<br />
y = b<br />
in f x y<br />
</haskell><br />
<br />
That gives the same result as<br />
<br />
<haskell><br />
let y = b<br />
x = a<br />
in f x y<br />
</haskell><br />
<br />
It doesn't matter what order we write the two bindings. But for doing I/O we'd like ordering. Monads allow use to express<br />
<br />
<haskell><br />
do<br />
x <- getChar<br />
y <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
and have it be different from<br />
<br />
<haskell><br />
do<br />
y <- getChar<br />
x <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
Unlike the first, the second example returns a pair of characters in the opposite order to which they were entered.<br />
<br />
It might help to meditate about the difference between 'assignment' and 'binding', right now.<br />
<br />
And now, just to spoil the enlightenment you just attained, there are monads for which swapping the order of lines like this makes no difference: For example, the Maybe monad.<br />
<br />
So while it is correct to say that monads can be used to order operations, it would be wrong to say that monads are a mechanism for ordering operations.<br />
<br />
This notion of commutativity looks superficially very different from the familiar one in vanilla algebra where a+b=b+a. It's not about the fact that<br />
<br />
<haskell><br />
(Just 2 >> Just 3) == Just 3<br />
</haskell><br />
, implying <br />
<haskell><br />
(Just 2 >> Just 3) /= (Just 3 >> Just 2)<br />
</haskell><br />
<br />
This shouldn't be too surprising, though, as >> isn't the binary operation of some monoid: the algebraic properties of '''''join''''' are very close to those of + and incidentally, '''''join''''' is also the operation true category theorists tend to work with. They also know of bind, but don't use it a lot because, unlike programmers, they don't do any actual productive work.<br />
<br />
==See also==<br />
<br />
* [[Do notation considered harmful]]<br />
<br />
[[Category:FAQ]]</div>Ksfhttps://wiki.haskell.org/index.php?title=What_a_Monad_is_not&diff=40705What a Monad is not2011-06-30T02:28:08Z<p>Ksf: /* Monads are not about ordering/sequencing */</p>
<hr />
<div>==Warning==<br />
This page is currently an unprocessed braindump. Feel free to dump additional stuff or massage stuff into didactic pleasures.<br />
<br />
Also, don't be surprised if you leave this page more confused than before. That just means that it has successfully destroyed your false assumptions, or that you've fallen for some horrible inside joke. Beware of [[Zygohistomorphic prepromorphisms]]. Go for [http://ertes.de/articles/monads.html warm and fuzzy], instead.<br />
<br />
==Monads are not a good choice as topic for your first Haskell blog entry==<br />
...just accept that they're [http://blog.plover.com/prog/burritos.html burritos], and wait until later.<br />
<br />
==Monads are not a language feature==<br />
Really. They are defined in terms of Haskell, not Haskell in terms of them. Conversely,<br />
<br />
==Haskell doesn't need Monads==<br />
...well, apart from the current Haskell standard defining the way IO is done in terms of Monads: It could be done differently and still work.<br />
<br />
==Monads are not impure==<br />
...In no way whatsoever. You don't even need flexible morals to claim it. To be more specific, it's IO that's impure. That makes the IO monad impure. But that's not a general property of monads - just IO. And even then, we can pretend that Haskell is a purely functional description language for imperative programs. But we didn't want to employ flexible morals, now did we?<br />
<br />
==Monads are not about state==<br />
While it is certainly possible to abstract away explicit state passing by using a Monad, that's not what a monad is.<br />
<br />
(some elaboration needed -- Well, which monad most obviously uses no state at all?)<br />
<br />
==Monads are not about strictness==<br />
Monad operations (bind and return) have to be [[Non-strict semantics|non-strict]] in fact, always! However<br />
other operations can be specific to each monad.<br />
For instance some are strict (like IO), and some are non-strict (like []). Then there are some that come in multiple flavours, like State.<br />
<br />
Try the following:<br />
<br />
<haskell><br />
runState (sequence . repeat $ state (\x -> (x,x+1))) 0<br />
</haskell><br />
<br />
Having a look at the implementation of fixIO might be helpful, too.<br />
<br />
==Monads are not values==<br />
This point might be driven home best by pointing out that instance Monad Foo where ... is not a data type, but a declaration of a typeclass instance. However, to elaborate:<br />
<br />
Monads are not values in the same sense that addition and multiplication are not numbers, or, for that matter, an oven is not food: They capture a -- very specific -- relationship between values of a specific domain into a common abstraction. We're going to call these values monads manage ''mobits'', somewhat like this:<br />
<br />
<haskell><br />
type Mobit m a = Monad m => m a<br />
</haskell><br />
<br />
The IO monad manages mobits representing side-effects ("IO actions").<br />
<br />
The List monad manages mobits representing multiple values ("[a]")<br />
<br />
The Reader monads manages mobits that are pure computations that use asks to propagate information instead of explicit arguments<br />
<br />
...and while addition and multiplication are both monoids over the positive natural numbers, an oven is a monoid over food (Burned pizza doesn't concern us, here: Food stays food, even if you don't want to eat it.), a monad is a monoid object in a category of endofunctors: return is the unit, and join is the binary operation. It couldn't be more simple. If that confuses you, it might be helpful to see a Monad as a lax functor from a terminal bicategory.<br />
<br />
==Monads are not a replacement for applicative functors==<br />
Instead, every monad ''is'' an applicative functor (as well as a functor). It is considered good practice not to use >>= if all you need is <*>, or even fmap.<br />
<br />
Not confusing which features of monads are specific to monads only and which stem from applicative functors is vitally important for a deeper understanding of monads. As an example, the applicative functor interface of parser libraries can parse context-free grammars (and look just like EBNF), while the monadic interface can parse context-sensitive grammars: Monads allow you to influence further processing by inspecting the result of your parse. To understand why, have a look at the type of >>=. To understand why applicative functors by themselves are sufficient to track the current parsing position, have a look at the [http://www.cs.uu.nl/research/techreps/repo/CS-2008/2008-044.pdf uu-parsinglib tutorial (pdf)].<br />
<br />
The exact differences are elaborated in even greater detail in Brent Yorgey's excellent [[Typeclassopedia]].<br />
<br />
==Monads are not about ordering/sequencing==<br />
Monads are commonly used to order sequences of computations. But this is misleading. Just as you can use monads for state, or strictness, you can use them to order computations. But there are also commutative monads, like Maybe, that don't order anything. So ordering is not in any way essential to what a monad is.<br />
<br />
Let's have a look at what's meant by ordering. Consider an expression like<br />
<br />
<haskell><br />
let x = a<br />
y = b<br />
in f x y<br />
</haskell><br />
<br />
That gives the same result as<br />
<br />
<haskell><br />
let y = b<br />
x = a<br />
in f x y<br />
</haskell><br />
<br />
It doesn't matter what order we write the two assignments. But for doing I/O we'd like ordering. Monads allow use to express<br />
<br />
<haskell><br />
do<br />
x <- getChar<br />
y <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
and have it be different from<br />
<br />
<haskell><br />
do<br />
y <- getChar<br />
x <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
The second example returns a pair of characters in the opposite order to which they were entered.<br />
<br />
However, there are monads for which swapping the order of lines like this makes no difference. For example the Maybe monad.<br />
<br />
So while it is correct to say that monads can be used to order operations, it would be wrong to say that monads are a mechanism for ordering operations.<br />
<br />
This notion of commutativity looks superficially very different from the familiar one in vanilla algebra where a+b=b+a. It's not about the fact that<br />
<br />
<haskell><br />
(Just 2 >> Just 3) == Just 3<br />
</haskell><br />
, implying <br />
<haskell><br />
(Just 2 >> Just 3) /= (Just 3 >> Just 2)<br />
</haskell><br />
<br />
This shouldn't be too surprising, though, as >> isn't the binary operation of some monoid: the algebraic properties of '''''join''''' are very close to those of + and incidentally, '''''join''''' is also the operation true category theorists tend to work with. They also know of bind, but don't use it a lot because, unlike programmers, they don't do any actual productive work.<br />
<br />
==See also==<br />
<br />
* [[Do notation considered harmful]]<br />
<br />
[[Category:FAQ]]</div>Ksfhttps://wiki.haskell.org/index.php?title=What_a_Monad_is_not&diff=40704What a Monad is not2011-06-30T02:25:19Z<p>Ksf: /* Monads are not values */</p>
<hr />
<div>==Warning==<br />
This page is currently an unprocessed braindump. Feel free to dump additional stuff or massage stuff into didactic pleasures.<br />
<br />
Also, don't be surprised if you leave this page more confused than before. That just means that it has successfully destroyed your false assumptions, or that you've fallen for some horrible inside joke. Beware of [[Zygohistomorphic prepromorphisms]]. Go for [http://ertes.de/articles/monads.html warm and fuzzy], instead.<br />
<br />
==Monads are not a good choice as topic for your first Haskell blog entry==<br />
...just accept that they're [http://blog.plover.com/prog/burritos.html burritos], and wait until later.<br />
<br />
==Monads are not a language feature==<br />
Really. They are defined in terms of Haskell, not Haskell in terms of them. Conversely,<br />
<br />
==Haskell doesn't need Monads==<br />
...well, apart from the current Haskell standard defining the way IO is done in terms of Monads: It could be done differently and still work.<br />
<br />
==Monads are not impure==<br />
...In no way whatsoever. You don't even need flexible morals to claim it. To be more specific, it's IO that's impure. That makes the IO monad impure. But that's not a general property of monads - just IO. And even then, we can pretend that Haskell is a purely functional description language for imperative programs. But we didn't want to employ flexible morals, now did we?<br />
<br />
==Monads are not about state==<br />
While it is certainly possible to abstract away explicit state passing by using a Monad, that's not what a monad is.<br />
<br />
(some elaboration needed -- Well, which monad most obviously uses no state at all?)<br />
<br />
==Monads are not about strictness==<br />
Monad operations (bind and return) have to be [[Non-strict semantics|non-strict]] in fact, always! However<br />
other operations can be specific to each monad.<br />
For instance some are strict (like IO), and some are non-strict (like []). Then there are some that come in multiple flavours, like State.<br />
<br />
Try the following:<br />
<br />
<haskell><br />
runState (sequence . repeat $ state (\x -> (x,x+1))) 0<br />
</haskell><br />
<br />
Having a look at the implementation of fixIO might be helpful, too.<br />
<br />
==Monads are not values==<br />
This point might be driven home best by pointing out that instance Monad Foo where ... is not a data type, but a declaration of a typeclass instance. However, to elaborate:<br />
<br />
Monads are not values in the same sense that addition and multiplication are not numbers, or, for that matter, an oven is not food: They capture a -- very specific -- relationship between values of a specific domain into a common abstraction. We're going to call these values monads manage ''mobits'', somewhat like this:<br />
<br />
<haskell><br />
type Mobit m a = Monad m => m a<br />
</haskell><br />
<br />
The IO monad manages mobits representing side-effects ("IO actions").<br />
<br />
The List monad manages mobits representing multiple values ("[a]")<br />
<br />
The Reader monads manages mobits that are pure computations that use asks to propagate information instead of explicit arguments<br />
<br />
...and while addition and multiplication are both monoids over the positive natural numbers, an oven is a monoid over food (Burned pizza doesn't concern us, here: Food stays food, even if you don't want to eat it.), a monad is a monoid object in a category of endofunctors: return is the unit, and join is the binary operation. It couldn't be more simple. If that confuses you, it might be helpful to see a Monad as a lax functor from a terminal bicategory.<br />
<br />
==Monads are not a replacement for applicative functors==<br />
Instead, every monad ''is'' an applicative functor (as well as a functor). It is considered good practice not to use >>= if all you need is <*>, or even fmap.<br />
<br />
Not confusing which features of monads are specific to monads only and which stem from applicative functors is vitally important for a deeper understanding of monads. As an example, the applicative functor interface of parser libraries can parse context-free grammars (and look just like EBNF), while the monadic interface can parse context-sensitive grammars: Monads allow you to influence further processing by inspecting the result of your parse. To understand why, have a look at the type of >>=. To understand why applicative functors by themselves are sufficient to track the current parsing position, have a look at the [http://www.cs.uu.nl/research/techreps/repo/CS-2008/2008-044.pdf uu-parsinglib tutorial (pdf)].<br />
<br />
The exact differences are elaborated in even greater detail in Brent Yorgey's excellent [[Typeclassopedia]].<br />
<br />
==Monads are not about ordering/sequencing==<br />
Monads are commonly used to order sequences of computations. But this is misleading. Just as you can use monads for state, or strictness, you can use them to order computations. But there are also commutative monads, like Maybe, that don't order anything. So ordering is not in any way essential to what a monad is.<br />
<br />
Let's have a look at what's meant by ordering. Consider an expression like<br />
<br />
<haskell><br />
let x = a<br />
y = b<br />
in f x y<br />
</haskell><br />
<br />
That gives the same result as<br />
<br />
<haskell><br />
let y = b<br />
x = a<br />
in f x y<br />
</haskell><br />
<br />
It doesn't matter what order we write the two assignments. But for doing I/O we'd like ordering. Monads allow use to express<br />
<br />
<haskell><br />
do<br />
x <- getChar<br />
y <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
and have it be different from<br />
<br />
<haskell><br />
do<br />
y <- getChar<br />
x <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
The second example returns a pair of characters in the opposite order to which they were entered.<br />
<br />
However, there are monads for which swapping the order of lines like this makes no difference. For example the Maybe monad.<br />
<br />
So while it is correct to say that monads can be used to order operations, it would be wrong to say that monads are a mechanism for ordering operations.<br />
<br />
This notion of commutativity looks superficially very different from the familiar one in vanilla algebra where a+b=b+a. It's not about the fact that<br />
<br />
<haskell><br />
(Just 2 >> Just 3) == Just 3<br />
</haskell><br />
, implying <br />
<haskell><br />
(Just 2 >> Just 3) /= (Just 3 >> Just 2)<br />
</haskell><br />
<br />
This shouldn't be too surprising, though, as >> isn't the binary operation of some monoid: the algebraic properties of '''''join''''' are very close to those of + and incidentally, '''''join''''' is also the operation true category theorists tend to work with. They also know of bind, but don't use it a lot because, unlike programmers, they don't do any actual productive work.<br />
<br />
(It took long to explain that, maybe someone can edit this down.)<br />
<br />
==See also==<br />
<br />
* [[Do notation considered harmful]]<br />
<br />
[[Category:FAQ]]</div>Ksfhttps://wiki.haskell.org/index.php?title=What_a_Monad_is_not&diff=40701What a Monad is not2011-06-30T02:14:55Z<p>Ksf: /* Haskell doesn't need Monads */</p>
<hr />
<div>==Warning==<br />
This page is currently an unprocessed braindump. Feel free to dump additional stuff or massage stuff into didactic pleasures.<br />
<br />
Also, don't be surprised if you leave this page more confused than before. That just means that it has successfully destroyed your false assumptions, or that you've fallen for some horrible inside joke. Beware of [[Zygohistomorphic prepromorphisms]]. Go for [http://ertes.de/articles/monads.html warm and fuzzy], instead.<br />
<br />
==Monads are not a good choice as topic for your first Haskell blog entry==<br />
...just accept that they're [http://blog.plover.com/prog/burritos.html burritos], and wait until later.<br />
<br />
==Monads are not a language feature==<br />
Really. They are defined in terms of Haskell, not Haskell in terms of them. Conversely,<br />
<br />
==Haskell doesn't need Monads==<br />
...well, apart from the current Haskell standard defining the way IO is done in terms of Monads: It could be done differently and still work.<br />
<br />
==Monads are not impure==<br />
...In no way whatsoever. You don't even need flexible morals to claim it. To be more specific, it's IO that's impure. That makes the IO monad impure. But that's not a general property of monads - just IO. And even then, we can pretend that Haskell is a purely functional description language for imperative programs. But we didn't want to employ flexible morals, now did we?<br />
<br />
==Monads are not about state==<br />
While it is certainly possible to abstract away explicit state passing by using a Monad, that's not what a monad is.<br />
<br />
(some elaboration needed -- Well, which monad most obviously uses no state at all?)<br />
<br />
==Monads are not about strictness==<br />
Monad operations (bind and return) have to be [[Non-strict semantics|non-strict]] in fact, always! However<br />
other operations can be specific to each monad.<br />
For instance some are strict (like IO), and some are non-strict (like []). Then there are some that come in multiple flavours, like State.<br />
<br />
Try the following:<br />
<br />
<haskell><br />
runState (sequence . repeat $ state (\x -> (x,x+1))) 0<br />
</haskell><br />
<br />
Having a look at the implementation of fixIO might be helpful, too.<br />
<br />
==Monads are not values==<br />
This point might be driven home best by pointing out that instance Monad Foo where ... is not a data type, but a declaration of a typeclass instance. However, to elaborate:<br />
<br />
Monads are not values in the same sense that addition and multiplication are not numbers, or, for that matter, an oven is not food: They capture a -- very specific -- relationship between values of a specific domain into a common abstraction. We're going to call these values monads manage ''mobits'', somewhat like this:<br />
<br />
<haskell><br />
type Mobit m a = Monad m => m a<br />
</haskell><br />
<br />
The IO monad manages mobits representing side-effects ("IO actions").<br />
<br />
The List monad manages mobits representing multiple values ("[a]")<br />
<br />
The Reader monads manages mobits that are pure computations that use asks to propagate information instead of explicit arguments<br />
<br />
...and while addition and multiplication are both monoids over the positive natural numbers, a monad is a monoid object in a category of endofunctors: return is the unit, and join is the binary operation. It couldn't be more simple. If that confuses you, it might be helpful to see a Monad as a lax functor from a terminal bicategory.<br />
<br />
==Monads are not a replacement for applicative functors==<br />
Instead, every monad ''is'' an applicative functor (as well as a functor). It is considered good practice not to use >>= if all you need is <*>, or even fmap.<br />
<br />
Not confusing which features of monads are specific to monads only and which stem from applicative functors is vitally important for a deeper understanding of monads. As an example, the applicative functor interface of parser libraries can parse context-free grammars (and look just like EBNF), while the monadic interface can parse context-sensitive grammars: Monads allow you to influence further processing by inspecting the result of your parse. To understand why, have a look at the type of >>=. To understand why applicative functors by themselves are sufficient to track the current parsing position, have a look at the [http://www.cs.uu.nl/research/techreps/repo/CS-2008/2008-044.pdf uu-parsinglib tutorial (pdf)].<br />
<br />
The exact differences are elaborated in even greater detail in Brent Yorgey's excellent [[Typeclassopedia]].<br />
<br />
==Monads are not about ordering/sequencing==<br />
Monads are commonly used to order sequences of computations. But this is misleading. Just as you can use monads for state, or strictness, you can use them to order computations. But there are also commutative monads, like Maybe, that don't order anything. So ordering is not in any way essential to what a monad is.<br />
<br />
Let's have a look at what's meant by ordering. Consider an expression like<br />
<br />
<haskell><br />
let x = a<br />
y = b<br />
in f x y<br />
</haskell><br />
<br />
That gives the same result as<br />
<br />
<haskell><br />
let y = b<br />
x = a<br />
in f x y<br />
</haskell><br />
<br />
It doesn't matter what order we write the two assignments. But for doing I/O we'd like ordering. Monads allow use to express<br />
<br />
<haskell><br />
do<br />
x <- getChar<br />
y <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
and have it be different from<br />
<br />
<haskell><br />
do<br />
y <- getChar<br />
x <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
The second example returns a pair of characters in the opposite order to which they were entered.<br />
<br />
However, there are monads for which swapping the order of lines like this makes no difference. For example the Maybe monad.<br />
<br />
So while it is correct to say that monads can be used to order operations, it would be wrong to say that monads are a mechanism for ordering operations.<br />
<br />
This notion of commutativity looks superficially very different from the familiar one in vanilla algebra where a+b=b+a. It's not about the fact that<br />
<br />
<haskell><br />
(Just 2 >> Just 3) == Just 3<br />
</haskell><br />
, implying <br />
<haskell><br />
(Just 2 >> Just 3) /= (Just 3 >> Just 2)<br />
</haskell><br />
<br />
This shouldn't be too surprising, though, as >> isn't the binary operation of some monoid: the algebraic properties of '''''join''''' are very close to those of + and incidentally, '''''join''''' is also the operation true category theorists tend to work with. They also know of bind, but don't use it a lot because, unlike programmers, they don't do any actual productive work.<br />
<br />
(It took long to explain that, maybe someone can edit this down.)<br />
<br />
==See also==<br />
<br />
* [[Do notation considered harmful]]<br />
<br />
[[Category:FAQ]]</div>Ksfhttps://wiki.haskell.org/index.php?title=Vogonism&diff=39498Vogonism2011-04-18T14:33:46Z<p>Ksf: </p>
<hr />
<div>First described by [http://de.wikipedia.org/wiki/Douglas_Adams Douglas Adams] and later [http://wiki.piratenpartei.de/Vogonismus formalised] by the German Pirate Party, Vogonism terms a manner of acting such that information is kept hidden in public sight. In case of complaints about the lack of information available, vogonists usually refer to the public availability of said hidden information.<br />
<br />
A distinctive property of vogonism is the establishment of an inscrutable network of communication channels and modes, as well as inconsistent use of those: In that manner, information is avoided to be present where recipients expect it due to related information already having been transmitted over the same channel.<br />
<br />
In human societies, a vogonic information system excels in limiting the effective use of itself to a small circle of insiders, all the while providing plausible deniability.<br />
<br />
In computer science, the vogonic property can refer to both code that is written so sloppily and without regard to readability that only a tiny number of people (usually the authors, and not even those after a couple of months) can comprehend it, as well as to code that has problems understanding itself. Examples for the latter case would be a high to very high percentage of data type conversions, or functions that become non-total after a (pseudo)random number of uses. Contrast [[Hoare Property]].</div>Ksfhttps://wiki.haskell.org/index.php?title=Vogonism&diff=39497Vogonism2011-04-18T14:32:48Z<p>Ksf: </p>
<hr />
<div>First described by [http://de.wikipedia.org/wiki/Douglas_Adams Douglas Adams] and later [http://wiki.piratenpartei.de/Vogonismus formalised] by the German Pirate Party, Vogonism terms a manner of acting such that information is kept hidden in public sight. In case of complaints about the lack of information available, vogonists usually refer to the public availability of said hidden information.<br />
<br />
A distinctive property of vogonism is the establishment of an inscrutable network of communication channels and modes, as well as inconsistent use of those: In that manner, information is avoided to be present where recipients expect it due to related information already having been transmitted over the same channel.<br />
<br />
In human societies, a vogonic information system excels in limiting the effective use of itself to a small circle of insiders, all the while providing plausible deniability.<br />
<br />
In computer science, the vogonic property can refer to both code that is written so sloppily and without regard to readability that only a tiny number of people (usually the authors, and not even those after a couple of months) can comprehend it, as well as to code that has problems understanding itself. An example for the latter case would be a high to very high percentage of data type conversions, or functions that become non-total after a (pseudo)random number of uses. Contrast [[Hoare Property]].</div>Ksfhttps://wiki.haskell.org/index.php?title=Vogonism&diff=39496Vogonism2011-04-18T14:32:34Z<p>Ksf: </p>
<hr />
<div>First described by [http://de.wikipedia.org/wiki/Douglas_Adams Douglas Adams] and later [http://wiki.piratenpartei.de/Vogonismus formalised] by the German Pirate Party, Vogonism terms a manner of acting such that information is kept hidden in public sight. In case of complaints about the lack of information available, vogonists usually refer to the public availability of said hidden information.<br />
<br />
A distinctive property of Vogonism is the establishment of an inscrutable network of communication channels and modes, as well as inconsistent use of those: In that manner, information is avoided to be present where recipients expect it due to related information already having been transmitted over the same channel.<br />
<br />
In human societies, a vogonic information system excels in limiting the effective use of itself to a small circle of insiders, all the while providing plausible deniability.<br />
<br />
In computer science, the vogonic property can refer to both code that is written so sloppily and without regard to readability that only a tiny number of people (usually the authors, and not even those after a couple of months) can comprehend it, as well as to code that has problems understanding itself. An example for the latter case would be a high to very high percentage of data type conversions, or functions that become non-total after a (pseudo)random number of uses. Contrast [[Hoare Property]].</div>Ksfhttps://wiki.haskell.org/index.php?title=Vogonism&diff=39495Vogonism2011-04-18T14:31:07Z<p>Ksf: </p>
<hr />
<div>First described by [http://de.wikipedia.org/wiki/Douglas_Adams Douglas Adams] and later [http://wiki.piratenpartei.de/Vogonismus formalised] by the German Pirate Party, Vogonism terms a manner of acting such that information is kept hidden in public sight. In case of complaints about the lack of information available, vogonists usually refer to the public availability of said hidden information.<br />
<br />
A distinctive property of vogonism is the establishment of an inscrutable network of communication channels and modes, as well as inconsistent use of those: In that manner, information is avoided to be present where recipients expect it due to related information already having been transmitted over the same channel.<br />
<br />
In human societies, a vogonic information system excels in limiting the effective use of itself to a small circle of insiders, all the while providing plausible deniability.<br />
<br />
In computer science, the vogonic property can refer to both code that is written so sloppily and without regard to readability that only a tiny number of people (usually the authors, and not even those after a couple of months) can comprehend it, as well as to code that has problems understanding itself. An example for the latter case would be a high to very high percentage of data type conversions, or functions that become non-total after a (pseudo)random number of uses. Contrast [[Hoare Property]].</div>Ksfhttps://wiki.haskell.org/index.php?title=Vogonism&diff=39494Vogonism2011-04-18T14:30:45Z<p>Ksf: </p>
<hr />
<div>First described by [http://de.wikipedia.org/wiki/Douglas_Adams Douglas Adams] and later [http://wiki.piratenpartei.de/Vogonismus formalised] by the German Pirate Party, Vogonism terms a manner of acting such that information is kept hidden in public sight. In case of complaints about the lack of information available, vogonists usually refer to the public availability of said hidden information.<br />
<br />
A distinctive property of vogonism is the establishment of an inscrutable network of communication channels and modes, as well as inconsistent use of those: In that manner, information is avoided to be present where recipients expect it due to related information already having been transmitted over the same channel.<br />
<br />
In human societies, a vogonic information system excels in limiting the effective use of itself to a small circle of insiders, all the while providing plausible deniability.<br />
<br />
In computer science, the vogonic property can refer to both code that is written so sloppily and without regard to readability that only a tiny number of people (usually the Authors, and not even those after a couple of months have passed) can comprehend it, as well as to code that has problems understanding itself. An example for the latter case would be a high to very high percentage of data type conversions, or functions that become non-total after a (pseudo)random number of uses. Contrast [[Hoare Property]].</div>Ksfhttps://wiki.haskell.org/index.php?title=Vogonism&diff=39493Vogonism2011-04-18T14:30:24Z<p>Ksf: </p>
<hr />
<div>First described by [http://de.wikipedia.org/wiki/Douglas_Adams Douglas Adams] and later [http://wiki.piratenpartei.de/Vogonismus formalised] by the German Pirate Party, Vogonism terms a manner of acting such that information is kept hidden in public sight. In case of complaints about the lack of information available, vogonists usually refer to the public availability of said hidden information.<br />
<br />
A distinctive property of vogonism is the establishment of an inscrutable network of communication channels and modes, as well as inconsistent use of those: In that manner, information is avoided to be present where recipients expect it due to related information already having been transmitted over the same channel.<br />
<br />
In human societies, a vogonic information system excels in limiting the effective use of it to a small circle of insiders, all the while providing plausible deniability.<br />
<br />
In computer science, the vogonic property can refer to both code that is written so sloppily and without regard to readability that only a tiny number of people (usually the Authors, and not even those after a couple of months have passed) can comprehend it, as well as to code that has problems understanding itself. An example for the latter case would be a high to very high percentage of data type conversions, or functions that become non-total after a (pseudo)random number of uses. Contrast [[Hoare Property]].</div>Ksfhttps://wiki.haskell.org/index.php?title=Vogonism&diff=39492Vogonism2011-04-18T14:27:59Z<p>Ksf: </p>
<hr />
<div>First described by [http://de.wikipedia.org/wiki/Douglas_Adams Douglas Adams] and later [http://wiki.piratenpartei.de/Vogonismus formalised] by the German Pirate Party, Vogonism terms a manner of acting such that information is kept hidden in public sight. In case of complaints about the lack of information available, vogonists usually refer to the public availability of said hidden information.<br />
<br />
A distinctive property of vogonism is the establishment of an inscrutable network of communication channels and modes, as well as inconsistent use of those: In that manner, information is avoided to be present where recipients expect it, even if other, related information already had been transmitted over the same channel.<br />
<br />
In human societies, a vogonic information system excels in limiting the effective use of it to a small circle of insiders, all the while providing plausible deniability.<br />
<br />
In computer science, the vogonic property can refer to both code that is written so sloppily and without regard to readability that only a tiny number of people (usually the Authors, and not even those after a couple of months have passed) can comprehend it, as well as to code that has problems understanding itself. An example for the latter case would be a high to very high percentage of data type conversions, or functions that become non-total after a (pseudo)random number of uses. Contrast [[Hoare Property]].</div>Ksfhttps://wiki.haskell.org/index.php?title=Vogonism&diff=39491Vogonism2011-04-18T14:25:52Z<p>Ksf: </p>
<hr />
<div>First described by [http://de.wikipedia.org/wiki/Douglas_Adams Douglas Adams] and later [http://wiki.piratenpartei.de/Vogonismus formalised] by the German Pirate Party, Vogonism terms a manner of acting such that information is kept hidden in public sight. In case of complaints about the lack of information available, vogonists usually refer to the public availability of said hidden information.<br />
<br />
A distinctive property of vogonism is the establishment of an inscrutable network of communication channels and modes, as well as inconsistent use of those: In that manner, information is avoided to be present where recipients expect it, even if other, related information already had been transmitted over the same channel.<br />
<br />
In human societies, a vogonic information system excels in limiting the effective use of it to a small circle of insiders, all the while providing plausible deniability.<br />
<br />
In computer science, the vogonic property can refer to both code that is written so sloppily and without regard to readability that only a tiny number of people (usually the Authors, and not even those after a couple of months have passed) can comprehend it, as well as to code that has problems understanding itself. An example for the latter case would be a high to very high percentage of data type conversions.<br />
<br />
<br />
Being a universal concept, it applies to code styles and documentation as well as wikis and any other place where you can hang signs saying "Beware of the Tiger". Contrast [[Hoare Property]].</div>Ksfhttps://wiki.haskell.org/index.php?title=Vogonism&diff=39490Vogonism2011-04-18T14:20:23Z<p>Ksf: </p>
<hr />
<div>First described by [http://de.wikipedia.org/wiki/Douglas_Adams Douglas Adams] and later [http://wiki.piratenpartei.de/Vogonismus formalised] by the German Pirate Party, Vogonism terms a manner of acting such that information is kept hidden in public sight. In case of complaints about the lack of information available, vogonists usually refer to the public availability of said hidden information.<br />
<br />
A distinctive property of vogonism is the establishment of an inscrutable network of communication channels and modes, as well as inconsistent use of those: In that manner, information is avoided to be present where recipients expect it, even if other, related information already had been transmitted over the same channel.<br />
<br />
A vogonic information system excels in limiting the effective use of it to a small circle of insiders, all the while providing plausible deniability.<br />
<br />
<br />
Being a universal concept, it applies to code styles and documentation as well as wikis and any other place where you can hang signs saying "Beware of the Tiger". Contrast [[Hoare Property]].</div>Ksfhttps://wiki.haskell.org/index.php?title=Vogonism&diff=39489Vogonism2011-04-18T14:19:24Z<p>Ksf: </p>
<hr />
<div>First described by [http://de.wikipedia.org/wiki/Douglas_Adams Douglas Adams] and later [http://wiki.piratenpartei.de/Vogonismus formalised] by the German Pirate Party, Vogonism terms a manner of acting such that information is kept hidden in public sight. In case of complaints about the lack of information available, vogonists usually refer to the public availability of said hidden information.<br />
<br />
A distinctive property of vogonism is the establishment of an inscrutable network of communication channels and modes, as well as inconsistent use of those: In that manner, information is avoided to be present where recipients expect it, even if other, related information already had been transmitted over the same channel.<br />
<br />
A vogonic information system excels in limiting the effective use of it to a small circle of insiders.<br />
<br />
<br />
Being a universal concept, it applies to code styles and documentation as well as wikis and any other place where you can hang signs saying "Beware of the Tiger". Contrast [[Hoare Property]].</div>Ksfhttps://wiki.haskell.org/index.php?title=Vogonism&diff=39488Vogonism2011-04-18T14:16:52Z<p>Ksf: </p>
<hr />
<div>First described by [http://de.wikipedia.org/wiki/Douglas_Adams Douglas Adams] and later [http://wiki.piratenpartei.de/Vogonismus formalised] by the German Pirate Party, Vogonism terms a manner of acting such that information is kept hidden in public sight. In case of complaints about the lack of information available, vogonists usually refer to the public availability of said hidden information.<br />
<br />
A distinctive property of vogonism is the establishment of an inscrutable network of communication channels and modes, as well as inconsistent use of those: In that manner, information is avoided to be present where recipients expect it, even if other, related information already had been transmitted over the same channel.<br />
<br />
A vogonic information system excels in limiting the effective use of it to a small, inner circle of recipients.<br />
<br />
<br />
Being a universal concept, it applies to code styles and documentation as well as wikis and any other place where you can hang signs saying "Beware of the Tiger". Contrast [[Hoare Property]].</div>Ksfhttps://wiki.haskell.org/index.php?title=Vogonism&diff=39487Vogonism2011-04-18T14:15:50Z<p>Ksf: </p>
<hr />
<div>First described by [http://de.wikipedia.org/wiki/Douglas_Adams Douglas Adams] and later [http://wiki.piratenpartei.de/Vogonismus formalised] by the German Pirate Party, Vogonism describes a manner of acting such that information is kept hidden in public sight. In case of complaints about the lack of information available, vogonists usually refer to the public availability of said hidden information.<br />
<br />
A distinctive property of vogonism is the establishment of an inscrutable network of communication channels and modes, as well as inconsistent use of those: In that manner, information is avoided to be present where recipients expect it, even if other, related information already had been transmitted over the same channel.<br />
<br />
A vogonic information system excels in limiting the effective use of it to a small, inner circle of recipients.<br />
<br />
<br />
Being a universal concept, it applies to code styles and documentation as well as wikis and any other place where you can hang signs saying "Beware of the Tiger". Contrast [[Hoare Property]].</div>Ksfhttps://wiki.haskell.org/index.php?title=Vogonism&diff=39483Vogonism2011-04-18T14:04:20Z<p>Ksf: </p>
<hr />
<div>First discovered by [http://de.wikipedia.org/wiki/Douglas_Adams Douglas Adams] and later [http://wiki.piratenpartei.de/Vogonismus formalised] by the German Pirate Party, Vogonism describes a manner of acting such that information is kept hidden in public sight. In case of complaints about the lack of information available, vogonists usually refer to the public availability of said hidden information.<br />
<br />
A distinctive property of vogonism is the establishment of an inscrutable network of communication channels and modes, as well as inconsistent use of those: In that manner, information is avoided to be present where recipients expect it, even if other, related information already had been transmitted over the same channel.<br />
<br />
A vogonic information system excels in limiting the effective use of it to a small, inner circle of recipients.<br />
<br />
<br />
Being a universal concept, it applies to code styles and documentation as well as wikis and any other place where you can hang signs saying "Beware of the Tiger". Contrast [[Hoare Property]].</div>Ksfhttps://wiki.haskell.org/index.php?title=Vogonism&diff=39482Vogonism2011-04-18T14:00:41Z<p>Ksf: </p>
<hr />
<div>First discovered by [http://de.wikipedia.org/wiki/Douglas_Adams Douglas Adams] and then [http://wiki.piratenpartei.de/Vogonismus formalised] by the German Pirate Party, Vogonism describes a manner of acting such that information is kept hidden in public sight. In case of complaints about the lack of information available, vogonists usually refer to the public availability of said hidden information.<br />
<br />
A distinctive property of vogonism is the establishment of an inscrutable network of communication channels and modes, as well as inconsistent use of those: In that manner, information is avoided to be present where recipients expect it, even if other, related information already had been transmitted over the same channel.<br />
<br />
A vogonic information system excels in limiting the effective use of it to a small, inner circle of recipients.<br />
<br />
<br />
Being a universal concept, it applies to code styles and documentation as well as wikis and any other place where you can hang signs saying "Beware of the Tiger". Contrast [[Hoare Property]].</div>Ksfhttps://wiki.haskell.org/index.php?title=Vogonism&diff=39481Vogonism2011-04-18T14:00:09Z<p>Ksf: </p>
<hr />
<div>First discovered by [http://de.wikipedia.org/wiki/Douglas_Adams Douglas Adams] and then [http://wiki.piratenpartei.de/Vogonismus formalised] by the German Pirate Party, Vogonism describes a manner of acting such that information is kept hidden in public sight. In case of complaints about the lack of information available, vogonists usually refer to the public availability of said hidden information.<br />
<br />
A distinctive property of vogonism is the establishment of an inscrutable network of communication channels and modes, as well as inconsistent use of those: In that manner, information is avoided to be present where recipients expect it, even if other, related information already had been transmitted over the same channel.<br />
<br />
A vogonic information system excels in limiting the effective use of it to a small, inner circle of recipients.<br />
<br />
<br />
Being a general concept, it applies to code styles and documentation as well as wikis and any other place where you can hang signs saying "Beware of the Tiger". Contrast [[Hoare Property]].</div>Ksfhttps://wiki.haskell.org/index.php?title=Vogonism&diff=39480Vogonism2011-04-18T13:50:50Z<p>Ksf: </p>
<hr />
<div>First discovered by [http://de.wikipedia.org/wiki/Douglas_Adams Douglas Adams] and then [http://wiki.piratenpartei.de/Vogonismus formalised] by the German Pirate Party, Vogonism describes a manner of acting such that information is kept hidden in public sight. In case of complaints about the lack of information available, vogonists usually refer to the public availability of said hidden information.<br />
<br />
A distinctive property of vogonism is the establishment of an inscrutable network of communication channels and modes, as well as inconsistent use of those: In that manner, information is avoided to be present where recipients expect it, even if other, related information already had been transmitted over the same channel.<br />
<br />
A vogonic information system excels in limiting the effective use of it to a small, inner circle of recipients.<br />
<br />
<br />
Being a general and absolute truth, it applies to code styles and documentation as well as wikis and any other place where you can hang signs saying "Beware of the Tiger". Contrast [[Hoare Property]].</div>Ksfhttps://wiki.haskell.org/index.php?title=Vogonism&diff=39479Vogonism2011-04-18T13:48:30Z<p>Ksf: New page: First discovered by [http://de.wikipedia.org/wiki/Douglas_Adams Douglas Adams] and then [http://wiki.piratenpartei.de/Vogonismus formalised] by the German Pirate Party, Vogonism describes ...</p>
<hr />
<div>First discovered by [http://de.wikipedia.org/wiki/Douglas_Adams Douglas Adams] and then [http://wiki.piratenpartei.de/Vogonismus formalised] by the German Pirate Party, Vogonism describes a manner of acting such that information is kept hidden in public sight. In case of complaints about the lack of information available, vogonists usually refer to the public availability of said hidden information.<br />
<br />
A distinctive property of vogonism is the establishment of an inscrutable network of communication channels and modes, as well as inconsistent use of those: In that manner, information is avoided to be present where recipients expect it, even if other, related information already had been transmitted over the same channel.<br />
<br />
A vogonic information system excels in limiting the effective use of it to a small, inner circle of recipients.<br />
<br />
<br />
Being a general and absolute truth, it applies to code styles and documentation as well as wikis and any other place where you can hang signs saying "Beware of the Tiger".</div>Ksfhttps://wiki.haskell.org/index.php?title=Hoare_Property&diff=39478Hoare Property2011-04-18T13:37:23Z<p>Ksf: New page: The Hoare Property is a code metric based upon a quote by [http://en.wikipedia.org/wiki/Tony_Hoare Tony Hoare]: There are two ways to write code: write code so simple there are obviously ...</p>
<hr />
<div>The Hoare Property is a code metric based upon a quote by [http://en.wikipedia.org/wiki/Tony_Hoare Tony Hoare]:<br />
<br />
There are two ways to write code: write code so simple there are obviously no bugs in it, or write code so complex that there are no obvious bugs in it.<br />
<br />
Code adhering to the former is said to have the Hoare property, code adhering to the latter could be considered to be a case of [[Vogonism]].</div>Ksfhttps://wiki.haskell.org/index.php?title=What_a_Monad_is_not&diff=38809What a Monad is not2011-02-17T00:40:54Z<p>Ksf: /* Monads are not about strictness */</p>
<hr />
<div>==Warning==<br />
This page is currently an unprocessed braindump. Feel free to dump additional stuff or massage stuff into didactic pleasures.<br />
<br />
Also, don't be surprised if you leave this page more confused than before. That just means that it has successfully destroyed your false assumptions, or that you've fallen for some horrible inside joke. Beware of [[Zygohistomorphic prepromorphisms]]. Go for [http://ertes.de/articles/monads.html warm and fuzzy], instead.<br />
<br />
==Monads are not a good choice as topic for your first Haskell blog entry==<br />
...just accept that they're [http://blog.plover.com/prog/burritos.html burritos], and wait until later.<br />
<br />
==Monads are not a language feature==<br />
Really. They are defined in terms of Haskell, not Haskell in terms of them. Conversely,<br />
<br />
==Haskell doesn't need Monads==<br />
...well, apart from the Haskell standard defining the way IO is done in terms of Monads: It could be done differently and still work.<br />
<br />
==Monads are not impure==<br />
...In no way whatsoever. You don't even need flexible morals to claim it. To be more specific, it's IO that's impure. That makes the IO monad impure. But that's not a general property of monads - just IO. And even then, we can pretend that Haskell is a purely functional description language for imperative programs. But we didn't want to employ flexible morals, now did we?<br />
<br />
==Monads are not about state==<br />
While it is certainly possible to abstract away explicit state passing by using a Monad, that's not what a monad is.<br />
<br />
(some elaboration needed -- Well, which monad most obviously uses no state at all?)<br />
<br />
==Monads are not about strictness==<br />
Monad operations (bind and return) have to be [[Non-strict semantics|non-strict]] in fact, always! However<br />
other operations can be specific to each monad.<br />
For instance some are strict (like IO), and some are non-strict (like []). Then there are some that come in multiple flavours, like State.<br />
<br />
Try the following:<br />
<br />
<haskell><br />
runState (sequence . repeat $ state (\x -> (x,x+1))) 0<br />
</haskell><br />
<br />
Having a look at the implementation of fixIO might be helpful, too.<br />
<br />
==Monads are not values==<br />
This point might be driven home best by pointing out that instance Monad Foo where ... is not a data type, but a declaration of a typeclass instance. However, to elaborate:<br />
<br />
Monads are not values in the same sense that addition and multiplication are not numbers, or, for that matter, an oven is not food: They capture a -- very specific -- relationship between values of a specific domain into a common abstraction. We're going to call these values monads manage ''mobits'', somewhat like this:<br />
<br />
<haskell><br />
type Mobit m a = Monad m => m a<br />
</haskell><br />
<br />
The IO monad manages mobits representing side-effects ("IO actions").<br />
<br />
The List monad manages mobits representing multiple values ("[a]")<br />
<br />
The Reader monads manages mobits that are pure computations that use asks to propagate information instead of explicit arguments<br />
<br />
...and while addition and multiplication are both monoids over the positive natural numbers, a monad is a monoid object in a category of endofunctors: return is the unit, and join is the binary operation. It couldn't be more simple. If that confuses you, it might be helpful to see a Monad as a lax functor from a terminal bicategory.<br />
<br />
==Monads are not a replacement for applicative functors==<br />
Instead, every monad ''is'' an applicative functor (as well as a functor). It is considered good practice not to use >>= if all you need is <*>, or even fmap.<br />
<br />
Not confusing which features of monads are specific to monads only and which stem from applicative functors is vitally important for a deeper understanding of monads. As an example, the applicative functor interface of parser libraries can parse context-free grammars (and look just like EBNF), while the monadic interface can parse context-sensitive grammars: Monads allow you to influence further processing by inspecting the result of your parse. To understand why, have a look at the type of >>=. To understand why applicative functors by themselves are sufficient to track the current parsing position, have a look at the [http://www.cs.uu.nl/research/techreps/repo/CS-2008/2008-044.pdf uu-parsinglib tutorial (pdf)].<br />
<br />
The exact differences are elaborated in even greater detail in Brent Yorgey's excellent [[Typeclassopedia]].<br />
<br />
==Monads are not about ordering/sequencing==<br />
Monads are commonly used to order sequences of computations. But this is misleading. Just as you can use monads for state, or strictness, you can use them to order computations. But there are also commutative monads, like Maybe, that don't order anything. So ordering is not in any way essential to what a monad is.<br />
<br />
Let's have a look at what's meant by ordering. Consider an expression like<br />
<br />
<haskell><br />
let x = a<br />
y = b<br />
in f x y<br />
</haskell><br />
<br />
That gives the same result as<br />
<br />
<haskell><br />
let y = b<br />
x = a<br />
in f x y<br />
</haskell><br />
<br />
It doesn't matter what order we write the two assignments. But for doing I/O we'd like ordering. Monads allow use to express<br />
<br />
<haskell><br />
do<br />
x <- getChar<br />
y <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
and have it be different from<br />
<br />
<haskell><br />
do<br />
y <- getChar<br />
x <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
The second example returns a pair of characters in the opposite order to which they were entered.<br />
<br />
However, there are monads for which swapping the order of lines like this makes no difference. For example the Maybe monad.<br />
<br />
So while it is correct to say that monads can be used to order operations, it would be wrong to say that monads are a mechanism for ordering operations.<br />
<br />
This notion of commutativity looks superficially very different from the familiar one in vanilla algebra where a+b=b+a. It's not about the fact that<br />
<br />
<haskell><br />
(Just 2 >> Just 3) == Just 3<br />
</haskell><br />
, implying <br />
<haskell><br />
(Just 2 >> Just 3) /= (Just 3 >> Just 2)<br />
</haskell><br />
<br />
This shouldn't be too surprising, though, as >> isn't the binary operation of some monoid: the algebraic properties of '''''join''''' are very close to those of + and incidentally, '''''join''''' is also the operation true category theorists tend to work with. They also know of bind, but don't use it a lot because, unlike programmers, they don't do any actual productive work.<br />
<br />
(It took long to explain that, maybe someone can edit this down.)<br />
<br />
==See also==<br />
<br />
* [[Do notation considered harmful]]<br />
<br />
[[Category:FAQ]]</div>Ksfhttps://wiki.haskell.org/index.php?title=What_a_Monad_is_not&diff=38458What a Monad is not2011-02-03T12:52:00Z<p>Ksf: /* Monads are not values */</p>
<hr />
<div>==Warning==<br />
This page is currently an unprocessed braindump. Feel free to dump additional stuff or massage stuff into didactic pleasures.<br />
<br />
Also, don't be surprised if you leave this page more confused than before. That just means that it has successfully destroyed your false assumptions, or that you've fallen for some horrible inside joke. Beware of [[Zygohistomorphic prepromorphisms]]. Go for [http://ertes.de/articles/monads.html warm and fuzzy], instead.<br />
<br />
==Monads are not a good choice as topic for your first Haskell blog entry==<br />
...just accept that they're [http://blog.plover.com/prog/burritos.html burritos], and wait until later.<br />
<br />
==Monads are not a language feature==<br />
Really. They are defined in terms of Haskell, not Haskell in terms of them. Conversely,<br />
<br />
==Haskell doesn't need Monads==<br />
...well, apart from the Haskell standard defining the way IO is done in terms of Monads: It could be done differently and still work.<br />
<br />
==Monads are not impure==<br />
...In no way whatsoever. You don't even need flexible morals to claim it. To be more specific, it's IO that's impure. That makes the IO monad impure. But that's not a general property of monads - just IO. And even then, we can pretend that Haskell is a purely functional description language for imperative programs. But we didn't want to employ flexible morals, now did we?<br />
<br />
==Monads are not about state==<br />
While it is certainly possible to abstract away explicit state passing by using a Monad, that's not what a monad is.<br />
<br />
(some elaboration needed -- Well, which monad most obviously uses no state at all?)<br />
<br />
==Monads are not about strictness==<br />
Monad operations (bind and return) have to be [[Non-strict semantics|lazy]] in fact, always! However<br />
other operations can be specific to each monad.<br />
For instance some are strict (like IO), and some are lazy (like []). Then there are some that come in multiple flavours, like State.<br />
<br />
Try the following:<br />
<br />
<haskell><br />
runState (sequence . repeat $ State (\x -> (x,x+1))) 0<br />
</haskell><br />
<br />
Having a look at the implementation of fixIO might be helpful, too.<br />
<br />
==Monads are not values==<br />
This point might be driven home best by pointing out that instance Monad Foo where ... is not a data type, but a declaration of a typeclass instance. However, to elaborate:<br />
<br />
Monads are not values in the same sense that addition and multiplication are not numbers, or, for that matter, an oven is not food: They capture a -- very specific -- relationship between values of a specific domain into a common abstraction. We're going to call these values monads manage ''mobits'', somewhat like this:<br />
<br />
<haskell><br />
type Mobit m a = Monad m => m a<br />
</haskell><br />
<br />
The IO monad manages mobits representing side-effects ("IO actions").<br />
<br />
The List monad manages mobits representing multiple values ("[a]")<br />
<br />
The Reader monads manages mobits that are pure computations that use asks to propagate information instead of explicit arguments<br />
<br />
...and while addition and multiplication are both monoids over the positive natural numbers, a monad is a monoid object in a category of endofunctors: return is the unit, and join is the binary operation. It couldn't be more simple. If that confuses you, it might be helpful to see a Monad as a lax functor from a terminal bicategory.<br />
<br />
==Monads are not a replacement for applicative functors==<br />
Instead, every monad ''is'' an applicative functor (as well as a functor). It is considered good practice not to use >>= if all you need is <*>, or even fmap.<br />
<br />
Not confusing which features of monads are specific to monads only and which stem from applicative functors is vitally important for a deeper understanding of monads. As an example, the applicative functor interface of parser libraries can parse context-free grammars (and look just like EBNF), while the monadic interface can parse context-sensitive grammars: Monads allow you to influence further processing by inspecting the result of your parse. To understand why, have a look at the type of >>=. To understand why applicative functors by themselves are sufficient to track the current parsing position, have a look at the [http://www.cs.uu.nl/research/techreps/repo/CS-2008/2008-044.pdf uu-parsinglib tutorial (pdf)].<br />
<br />
The exact differences are elaborated in even greater detail in Brent Yorgey's excellent [[Typeclassopedia]].<br />
<br />
==Monads are not about ordering/sequencing==<br />
Monads are commonly used to order sequences of computations. But this is misleading. Just as you can use monads for state, or strictness, you can use them to order computations. But there are also commutative monads, like Maybe, that don't order anything. So ordering is not in any way essential to what a monad is.<br />
<br />
Let's have a look at what's meant by ordering. Consider an expression like<br />
<br />
<haskell><br />
let x = a<br />
y = b<br />
in f x y<br />
</haskell><br />
<br />
That gives the same result as<br />
<br />
<haskell><br />
let y = b<br />
x = a<br />
in f x y<br />
</haskell><br />
<br />
It doesn't matter what order we write the two assignments. But for doing I/O we'd like ordering. Monads allow use to express<br />
<br />
<haskell><br />
do<br />
x <- getChar<br />
y <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
and have it be different from<br />
<br />
<haskell><br />
do<br />
y <- getChar<br />
x <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
The second example returns a pair of characters in the opposite order to which they were entered.<br />
<br />
However, there are monads for which swapping the order of lines like this makes no difference. For example the Maybe monad.<br />
<br />
So while it is correct to say that monads can be used to order operations, it would be wrong to say that monads are a mechanism for ordering operations.<br />
<br />
This notion of commutativity looks superficially very different from the familiar one in vanilla algebra where a+b=b+a. It's not about the fact that<br />
<br />
<haskell><br />
(Just 2 >> Just 3) == Just 3<br />
</haskell><br />
, implying <br />
<haskell><br />
(Just 2 >> Just 3) /= (Just 3 >> Just 2)<br />
</haskell><br />
<br />
This shouldn't be too surprising, though, as >> isn't the binary operation of some monoid: the algebraic properties of '''''join''''' are very close to those of + and incidentally, '''''join''''' is also the operation true category theorists tend to work with. They also know of bind, but don't use it a lot because, unlike programmers, they don't do any actual productive work.<br />
<br />
(It took long to explain that, maybe someone can edit this down.)<br />
<br />
==See also==<br />
<br />
* [[Do notation considered harmful]]<br />
<br />
[[Category:FAQ]]</div>Ksfhttps://wiki.haskell.org/index.php?title=What_a_Monad_is_not&diff=36576What a Monad is not2010-08-27T01:40:16Z<p>Ksf: </p>
<hr />
<div>==Warning==<br />
This page is currently an unprocessed braindump. Feel free to dump additional stuff or massage stuff into didactic pleasures.<br />
<br />
Also, don't be surprised if you leave this page more confused than before. That just means that it has successfully destroyed your false assumptions, or that you've fallen for some horrible inside joke. Beware of [[Zygohistomorphic prepromorphisms]]. Go for [http://ertes.de/articles/monads.html warm and fuzzy], instead.<br />
<br />
==Monads are not a good choice as topic for your first Haskell blog entry==<br />
...just accept that they're [http://blog.plover.com/prog/burritos.html burritos], and wait until later.<br />
<br />
==Monads are not a language feature==<br />
Really. They are defined in terms of Haskell, not Haskell in terms of them. Conversely,<br />
<br />
==Haskell doesn't need Monads==<br />
...well, apart from the Haskell standard defining the way IO is done in terms of Monads: It could be done differently and still work.<br />
<br />
==Monads are not impure==<br />
...In no way whatsoever. You don't even need flexible morals to claim it. To be more specific, it's IO that's impure. That makes the IO monad impure. But that's not a general property of monads - just IO. And even then, we can pretend that Haskell is a purely functional description language for imperative programs. But we didn't want to employ flexible morals, now did we?<br />
<br />
==Monads are not about state==<br />
While it is certainly possible to abstract away explicit state passing by using a Monad, that's not what a monad is.<br />
<br />
(some elaboration needed -- Well, which monad most obviously uses no state at all?)<br />
<br />
==Monads are not about strictness==<br />
Monad operations (bind and return) have to be [[Non-strict semantics|lazy]] in fact, always! However<br />
other operations can be specific to each monad.<br />
For instance some are strict (like IO), and some are lazy (like []). Then there are some that come in multiple flavours, like State.<br />
<br />
Try the following:<br />
<br />
<haskell><br />
runState (sequence . repeat $ State (\x -> (x,x+1))) 0<br />
</haskell><br />
<br />
Having a look at the implementation of fixIO might be helpful, too.<br />
<br />
==Monads are not values==<br />
This point might be driven home best by pointing out that instance Monad Foo where ... is not a data type, but a declaration of a typeclass instance. However, to elaborate:<br />
<br />
Monads are not values in the same sense that addition and multiplication are not numbers: They capture a -- very specific -- relationship between values of a specific domain into a common abstraction. We're going to call these values monads manage ''mobits'', somewhat like this:<br />
<br />
<haskell><br />
type Mobit m a = Monad m => m a<br />
</haskell><br />
<br />
The IO monad manages mobits representing side-effects ("IO actions").<br />
<br />
The List monad manages mobits representing multiple values ("[a]")<br />
<br />
The Reader monads manages mobits that are pure computations that use asks to propagate information instead of explicit arguments<br />
<br />
...and while addition and multiplication are both monoids over the positive natural numbers, a monad is a monoid object in a category of endofunctors: return is the unit, and join is the binary operation. It couldn't be more simple. If that confuses you, it might be helpful to see a Monad as a lax functor from a terminal bicategory.<br />
<br />
<br />
<br />
==Monads are not a replacement for applicative functors==<br />
Instead, every monad ''is'' an applicative functor (as well as a functor). It is considered good practice not to use >>= if all you need is <*>, or even fmap.<br />
<br />
Not confusing which features of monads are specific to monads only and which stem from applicative functors is vitally important for a deeper understanding of monads. As an example, the applicative functor interface of parser libraries can parse context-free grammars (and look just like EBNF), while the monadic interface can parse context-sensitive grammars: Monads allow you to influence further processing by inspecting the result of your parse. To understand why, have a look at the type of >>=. To understand why applicative functors by themselves are sufficient to track the current parsing position, have a look at the [http://www.cs.uu.nl/research/techreps/repo/CS-2008/2008-044.pdf uu-parsinglib tutorial (pdf)].<br />
<br />
The exact differences are elaborated in even greater detail in Brent Yorgey's excellent [[Typeclassopedia]].<br />
<br />
==Monads are not about ordering/sequencing==<br />
Monads are commonly used to order sequences of computations. But this is misleading. Just as you can use monads for state, or strictness, you can use them to order computations. But there are also commutative monads, like Maybe, that don't order anything. So ordering is not in any way essential to what a monad is.<br />
<br />
Let's have a look at what's meant by ordering. Consider an expression like<br />
<br />
<haskell><br />
let x = a<br />
y = b<br />
in f x y<br />
</haskell><br />
<br />
That gives the same result as<br />
<br />
<haskell><br />
let y = b<br />
x = a<br />
in f x y<br />
</haskell><br />
<br />
It doesn't matter what order we write the two assignments. But for doing I/O we'd like ordering. Monads allow use to express<br />
<br />
<haskell><br />
do<br />
x <- getChar<br />
y <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
and have it be different from<br />
<br />
<haskell><br />
do<br />
y <- getChar<br />
x <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
The second example returns a pair of characters in the opposite order to which they were entered.<br />
<br />
However, there are monads for which swapping the order of lines like this makes no difference. For example the Maybe monad.<br />
<br />
So while it is correct to say that monads can be used to order operations, it would be wrong to say that monads are a mechanism for ordering operations.<br />
<br />
This notion of commutativity looks superficially very different from the familiar one in vanilla algebra where a+b=b+a. It's not about the fact that<br />
<br />
<haskell><br />
(Just 2 >> Just 3) == Just 3<br />
</haskell><br />
, implying <br />
<haskell><br />
(Just 2 >> Just 3) /= (Just 3 >> Just 2)<br />
</haskell><br />
<br />
This shouldn't be too surprising, though, as >> isn't the binary operation of some monoid: the algebraic properties of join are very close to those of + and incidentally, join is also the operation true category theorists tend to work with. They also know of bind, but don't use it a lot because, unlike programmers, they don't do any actual productive work.<br />
<br />
(It took long to explain that, maybe someone can edit this down.)<br />
<br />
==See also==<br />
<br />
* [[Do notation considered harmful]]<br />
<br />
[[Category:FAQ]]</div>Ksfhttps://wiki.haskell.org/index.php?title=File:Ghc-head.torrent&diff=34250File:Ghc-head.torrent2010-03-22T17:21:21Z<p>Ksf: </p>
<hr />
<div></div>Ksfhttps://wiki.haskell.org/index.php?title=What_a_Monad_is_not&diff=34036What a Monad is not2010-03-12T18:27:30Z<p>Ksf: </p>
<hr />
<div>==Warning==<br />
This page is currently an unprocessed braindump. Feel free to dump additional stuff or massage stuff into didactic pleasures.<br />
<br />
Also, don't be surprised if you leave this page more confused than before. That just means that it has successfully destroyed your false assumptions, or that you've fallen for some horrible inside joke. Beware of [[Zygohistomorphic prepromorphisms]]. Go for [http://ertes.de/articles/monads.html warm and fuzzy], instead.<br />
<br />
==Monads are not a good choice as topic for your first Haskell blog entry==<br />
...just accept that they're [http://blog.plover.com/prog/burritos.html burritos], and wait until later.<br />
<br />
==Monads are not a language feature==<br />
Really. They are defined in terms of Haskell, not Haskell in terms of them. Conversely,<br />
<br />
==Haskell doesn't need Monads==<br />
...well, apart from the Haskell standard defining the way IO is done in terms of Monads: It could be done differently and still work.<br />
<br />
==Monads are not impure==<br />
...In no way whatsoever. You don't even need flexible morals to claim it. To be more specific, it's IO that's impure. That makes the IO monad impure. But that's not a general property of monads - just IO. And even then, we can pretend that Haskell is a purely functional description language for imperative programs. But we didn't want to employ flexible morals, now did we?<br />
<br />
==Monads are not about state==<br />
While it is certainly possible to abstract away explicit state passing by using a Monad, that's not what a monad is.<br />
<br />
(some elaboration needed -- Well, which monad most obviously uses no state at all?)<br />
<br />
==Monads are not about strictness==<br />
Monad operations (bind and return) have to be [[Non-strict semantics|lazy]] in fact, always! However<br />
other operations can be specific to each monad.<br />
For instance some are strict (like IO), and some are lazy (like []). Then there are some that come in multiple flavours, like State.<br />
<br />
Try the following:<br />
<br />
<haskell><br />
runState (sequence . repeat $ State (\x -> (x,x+1))) 0<br />
</haskell><br />
<br />
Having a look at the implementation of fixIO might be helpful, too.<br />
<br />
==Monads are not values==<br />
This point might be driven home best by pointing out that instance Monad Foo where ... is not a data type, but a declaration of a typeclass instance. However, to elaborate:<br />
<br />
Monads are not values in the same sense that addition and multiplication are not numbers: They capture a -- very specific -- relationship between values of a specific domain into a common abstraction. We're going to call these values monads manage ''mobits'', somewhat like this:<br />
<br />
<haskell><br />
type Mobit m a = Monad m => m a<br />
</haskell><br />
<br />
The IO monad manages mobits representing side-effects ("IO actions").<br />
<br />
The List monad manages mobits representing multiple values ("[a]")<br />
<br />
The Reader monads manages mobits that are pure computations that use asks to propagate information instead of explicit arguments<br />
<br />
...and while addition and multiplication are both monoids over the positive natural numbers, a monad is a monoid object in a category of endofunctors: return is the unit, and join is the binary operation. It couldn't be more simple. If that confuses you, it might be helpful to see a Monad as a lax functor from a terminal bicategory.<br />
<br />
<br />
<br />
==Monads are not a replacement for applicative functors==<br />
Instead, every monad ''is'' an applicative functor (as well as a functor). It is considered good practice not to use >>= if all you need is <*>, or even fmap.<br />
<br />
Not confusing which features of monads are specific to monads only and which stem from applicative functors is vitally important for a deeper understanding of monads. As an example, the applicative functor interface of parser libraries can parse context-free grammars (and look just like EBNF), while the monadic interface can parse context-sensitive grammars: Monads allow you to influence further processing by inspecting the result of your parse. To understand why, have a look at the type of >>=. To understand why applicative functors by themselves are sufficient to track the current parsing position, have a look at the [http://www.cs.uu.nl/research/techreps/repo/CS-2008/2008-044.pdf uu-parsinglib tutorial (pdf)].<br />
<br />
The exact differences are elaborated in even greater detail in Brent Yorgey's excellent [[Typeclassopedia]].<br />
<br />
==Monads are not about ordering/sequencing==<br />
Monads are commonly used to order sequences of computations. But this is misleading. Just as you can use monads for state, or strictness, you can use them to order computations. But there are also commutative monads, like Maybe, that don't order anything. So ordering is not in any way essential to what a monad is.<br />
<br />
I'll try to explain what's meant by ordering. Consider an expression like<br />
<br />
<haskell><br />
let x = a<br />
y = b<br />
in f x y<br />
</haskell><br />
<br />
That gives the same result as<br />
<br />
<haskell><br />
let y = b<br />
x = a<br />
in f x y<br />
</haskell><br />
<br />
It doesn't matter what order we write the two assignments. But for doing I/O we'd like ordering. Monads allow use to express<br />
<br />
<haskell><br />
do<br />
x <- getChar<br />
y <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
and have it be different from<br />
<br />
<haskell><br />
do<br />
y <- getChar<br />
x <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
The second example returns a pair of characters in the opposite order to which they were entered.<br />
<br />
However, there are monads for which swapping the order of lines like this makes no difference. For example the Maybe monad.<br />
<br />
So while it is correct to say that monads can be used to order operations, it would be wrong to say that monads are a mechanism for ordering operations.<br />
<br />
This notion of commutativity looks superficially very different from the familiar one in vanilla algebra where a+b=b+a. It's not about the fact that<br />
<br />
<haskell><br />
(Just 2 >> Just 3) == Just 3<br />
</haskell><br />
, implying <br />
<haskell><br />
(Just 2 >> Just 3) /= (Just 3 >> Just 2)<br />
</haskell><br />
<br />
This shouldn't be too surprising, though, as >> isn't the binary operation of some monoid: the algebraic properties of join are very close to those of + and incidentally, join is also the operation true category theorists tend to work with. They also know of bind, but don't use it a lot because, unlike programmers, they don't do any actual productive work.<br />
<br />
(It took long to explain that, maybe someone can edit this down.)<br />
<br />
==See also==<br />
<br />
* [[Do notation considered harmful]]<br />
<br />
[[Category:FAQ]]</div>Ksfhttps://wiki.haskell.org/index.php?title=What_a_Monad_is_not&diff=34035What a Monad is not2010-03-12T18:26:27Z<p>Ksf: </p>
<hr />
<div>==Warning==<br />
This page is currently an unprocessed braindump. Feel free to dump additional stuff or massage stuff into didactic pleasures.<br />
<br />
Also, don't be surprised if you leave this page more confused than before. That just means that it has successfully destroyed your false assumptions, or that you've fallen for some horrible inside joke. Beware of [[Zygohistomorphic prepromorphisms]]. Go for [http://ertes.de/articles/monads.html warm and fuzzy], instead.<br />
<br />
==Monads are not a good choice as topic for your first Haskell blog entry==<br />
...just accept that they're [http://blog.plover.com/prog/burritos.html burritos], and wait until later.<br />
<br />
==Monads are not a language feature==<br />
Really. They are defined in terms of Haskell, not Haskell in terms of them. Conversely,<br />
<br />
==Haskell doesn't need Monads==<br />
...well, apart from the Haskell standard defining the way IO is done in terms of Monads: It could be done differently and still work.<br />
<br />
==Monads are not impure==<br />
...In no way whatsoever. You don't even need flexible morals to claim it. To be more specific, it's IO that's impure. That makes the IO monad impure. But that's not a general property of monads - just IO. And even then, we can pretend that Haskell is a purely functional description language for imperative programs. But we didn't want to employ flexible morals, now did we?<br />
<br />
==Monads are not about state==<br />
While it is certainly possible to abstract away explicit state passing by using a Monad, that's not what a monad is.<br />
<br />
(some elaboration needed -- Well, which monad most obviously uses no state at all?)<br />
<br />
==Monads are not about strictness==<br />
Monad operations (bind and return) have to be [[Non-strict semantics|lazy]] in fact, always! However<br />
other operations can be specific to each monad.<br />
For instance some are strict (like IO), and some are lazy (like []). Then there are some that come in multiple flavours, like State.<br />
<br />
Try the following:<br />
<br />
<haskell><br />
runState (sequence . repeat $ State (\x -> (x,x+1))) 0<br />
</haskell><br />
<br />
Having a look at the implementation of fixIO might be helpful, too.<br />
<br />
==Monads are not values==<br />
This point might be driven home best by pointing out that instance Monad Foo where ... is not a data type, but a declaration of a typeclass instance. However, to elaborate:<br />
<br />
Monads are not values in the same sense that addition and multiplication are not numbers: They capture a -- very specific -- relationship between values of a specific domain into a common abstraction. We're going to call these values monads manage ''mobits'', somewhat like this:<br />
<br />
<haskell><br />
type Mobit m a = Monad m => m a<br />
</haskell><br />
<br />
The IO monad manages mobits representing side-effects ("IO actions").<br />
<br />
The List monad manages mobits representing multiple values ("[a]")<br />
<br />
The Reader monads manages mobits that are pure computations that use asks to propagate information instead of explicit arguments<br />
<br />
...and while addition and multiplication are both monoids over the positive natural numbers, a monad is a monoid object in a category of endofunctors: return is the unit, and join is the binary operation. It couldn't be more simple. If that confuses you, it might be helpful to see a Monad as a lax functor from a terminal bicategory.<br />
<br />
<br />
<br />
==Monads are not a replacement for applicative functors==<br />
Instead, every monad ''is'' an applicative functor (as well as a functor). It is considered good practice not to use >>= if all you need is <*>, or even fmap.<br />
<br />
Not confusing which features of monads are specific to monads only and which stem from applicative functors is vitally important for a deeper understanding of monads. As an example, the applicative functor interface of parser libraries can parse context-free grammars (and look just like EBNF), while the monadic interface can parse context-sensitive grammars: Monads allow you to influence further processing by inspecting the result of your parse. To understand why, have a look at the type of >>=. To understand why applicative functors by themselves are sufficient to track the current parsing position, have a look at the [http://www.cs.uu.nl/research/techreps/repo/CS-2008/2008-044.pdf uu-parsinglib tutorial (pdf)].<br />
<br />
The exact differences are elaborated in even greater detail in Brent Yorgey's excellent [[Typeclassopedia]].<br />
<br />
==Monads are not about ordering/sequencing==<br />
Monads are commonly used to order sequences of computations. But this is misleading. Just as you can use monads for state, or strictness, you can use them to order computations. But there are also commutative monads, like Maybe, that don't order anything. So ordering is not in any way essential to what a monad is.<br />
<br />
I'll try to explain what's meant by ordering. Consider an expression like<br />
<br />
<haskell><br />
let x = a<br />
y = b<br />
in f x y<br />
</haskell><br />
<br />
That gives the same result as<br />
<br />
<haskell><br />
let y = b<br />
x = a<br />
in f x y<br />
</haskell><br />
<br />
It doesn't matter what order we write the two assignments. But for doing I/O we'd like ordering. Monads allow use to express<br />
<br />
<haskell><br />
do<br />
x <- getChar<br />
y <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
and have it be different from<br />
<br />
<haskell><br />
do<br />
y <- getChar<br />
x <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
The second example returns a pair of characters in the opposite order to which they were entered.<br />
<br />
However, there are monads for which swapping the order of lines like this makes no difference. For example the Maybe monad.<br />
<br />
So while it is correct to say that monads can be used to order operations, it would be wrong to say that monads are a mechanism for ordering operations.<br />
<br />
This notion of commutativity looks superficially very different from the familiar one in vanilla algebra where a+b=b+a. It's not about the fact that<br />
<br />
<haskell><br />
(Just 2 >> Just 3) == Just 3<br />
</haskell><br />
, implying <br />
<haskell><br />
(Just 2 >> Just 3) /= (Just 3 >> Just 2)<br />
</haskell><br />
<br />
This shouldn't be too surprising, though, as >> isn't the binary operation of some monoid: the algebraic properties of join are very close to those of + and incidentally is the operation true category theorists work with. They also know of bind, but don't use it a lot because, unlike programmers, they don't do any actual productive work.<br />
<br />
(It took long to explain that, maybe someone can edit this down.)<br />
<br />
==See also==<br />
<br />
* [[Do notation considered harmful]]<br />
<br />
[[Category:FAQ]]</div>Ksfhttps://wiki.haskell.org/index.php?title=What_a_Monad_is_not&diff=34034What a Monad is not2010-03-12T18:19:43Z<p>Ksf: </p>
<hr />
<div>==Warning==<br />
This page is currently an unprocessed braindump. Feel free to dump additional stuff or massage stuff into didactic pleasures.<br />
<br />
Also, don't be surprised if you leave this page more confused than before. That just means that it has successfully destroyed your false assumptions, or that you've fallen for some horrible inside joke. Beware of [[Zygohistomorphic prepromorphisms]]. Go for [http://ertes.de/articles/monads.html warm and fuzzy], instead.<br />
<br />
==Monads are not a good choice as topic for your first Haskell blog entry==<br />
...just accept that they're [http://blog.plover.com/prog/burritos.html burritos], and wait until later.<br />
<br />
==Monads are not a language feature==<br />
Really. They are defined in terms of Haskell, not Haskell in terms of them. Conversely,<br />
<br />
==Haskell doesn't need Monads==<br />
...well, apart from the Haskell standard defining the way IO is done in terms of Monads: It could be done differently and still work.<br />
<br />
==Monads are not impure==<br />
...In no way whatsoever. You don't even need flexible morals to claim it. To be more specific, it's IO that's impure. That makes the IO monad impure. But that's not a general property of monads - just IO. And even then, we can pretend that Haskell is a purely functional description language for imperative programs. But we didn't want to employ flexible morals, now did we?<br />
<br />
==Monads are not about state==<br />
While it is certainly possible to abstract away explicit state passing by using a Monad, that's not what a monad is.<br />
<br />
(some elaboration needed -- Well, which monad most obviously uses no state at all?)<br />
<br />
==Monads are not about strictness==<br />
Monad operations (bind and return) have to be [[Non-strict semantics|lazy]] in fact, always! However<br />
other operations can be specific to each monad.<br />
For instance some are strict (like IO), and some are lazy (like []). Then there are some that come in multiple flavours, like State.<br />
<br />
Try the following:<br />
<br />
<haskell><br />
runState (sequence . repeat $ State (\x -> (x,x+1))) 0<br />
</haskell><br />
<br />
Having a look at the implementation of fixIO might be helpful, too.<br />
<br />
==Monads are not values==<br />
This point might be driven home best by pointing out that instance Monad Foo where ... is not a data type, but a declaration of a typeclass instance. However, to elaborate:<br />
<br />
Monads are not values in the same sense that addition and multiplication are not numbers: They capture a -- very specific -- relationship between values of a specific domain into a common abstraction. We're going to call these values monads manage ''mobits'', somewhat like this:<br />
<br />
<haskell><br />
type Mobit m a = Monad m => m a<br />
</haskell><br />
<br />
The IO monad manages mobits representing side-effects ("IO actions").<br />
<br />
The List monad manages mobits representing multiple values ("[a]")<br />
<br />
The Reader monads manages mobits that are pure computations that use asks to propagate information instead of explicit arguments<br />
<br />
...and while addition and multiplication are both monoids over the positive natural numbers, a monad is a monoid object in a category of endofunctors: return is the unit, and join is the binary operation. It couldn't be more simple. If that confuses you, it might be helpful to see a Monad as a lax functor from a terminal bicategory.<br />
<br />
<br />
<br />
==Monads are not a replacement for applicative functors==<br />
Instead, every monad ''is'' an applicative functor (as well as a functor). It is considered good practice not to use >>= if all you need is <*>, or even fmap.<br />
<br />
Not confusing which features of monads are specific to monads only and which stem from applicative functors is vitally important for a deeper understanding of monads. As an example, the applicative functor interface of parser libraries can parse context-free grammars (and look just like EBNF), while the monadic interface can parse context-sensitive grammars: Monads allow you to influence further processing by inspecting the result of your parse. To understand why, have a look at the type of >>=. To understand why applicative functors by themselves are sufficient to track the current parsing position, have a look at the [http://www.cs.uu.nl/research/techreps/repo/CS-2008/2008-044.pdf uu-parsinglib tutorial (pdf)].<br />
<br />
The exact differences are elaborated in even greater detail in Brent Yorgey's excellent [[Typeclassopedia]].<br />
<br />
==Monads are not about ordering/sequencing==<br />
Monads are commonly used to order sequences of computations. But this is misleading. Just as you can use monads for state, or strictness, you can use them to order computations. But there are also commutative monads, like Maybe, that don't order anything. So ordering is not in any way essential to what a monad is.<br />
<br />
I'll try to explain what's meant by ordering. Consider an expression like<br />
<br />
<haskell><br />
let x = a<br />
y = b<br />
in f x y<br />
</haskell><br />
<br />
That gives the same result as<br />
<br />
<haskell><br />
let y = b<br />
x = a<br />
in f x y<br />
</haskell><br />
<br />
It doesn't matter what order we write the two assignments. But for doing I/O we'd like ordering. Monads allow use to express<br />
<br />
<haskell><br />
do<br />
x <- getChar<br />
y <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
and have it be different from<br />
<br />
<haskell><br />
do<br />
y <- getChar<br />
x <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
The second example returns a pair of characters in the opposite order to which they were entered.<br />
<br />
However, there are monads for which swapping the order of lines like this makes no difference. For example the Maybe monad.<br />
<br />
So while it is correct to say that monads can be used to order operations, it would be wrong to say that monads are a mechanism for ordering operations.<br />
<br />
This notion of commutativity is syntactically very different from the familiar one in vanilla algebra where a+b=b+a. So it's not about the fact that<br />
<br />
<haskell><br />
(Just 2 >> Just 3) == Just 3<br />
</haskell><br />
, implying <br />
<haskell><br />
(Just 2 >> Just 3) /= (Just 3 >> Just 2)<br />
</haskell><br />
<br />
This shouldn't be too surprising, though, as >> isn't the binary operation of some monoid (join is).<br />
<br />
(It took long to explain that, maybe someone can edit this down.)<br />
<br />
==See also==<br />
<br />
* [[Do notation considered harmful]]<br />
<br />
[[Category:FAQ]]</div>Ksfhttps://wiki.haskell.org/index.php?title=What_a_Monad_is_not&diff=34033What a Monad is not2010-03-12T18:12:33Z<p>Ksf: </p>
<hr />
<div>==Warning==<br />
This page is currently an unprocessed braindump. Feel free to dump additional stuff or massage stuff into didactic pleasures.<br />
<br />
Also, don't be surprised if you leave this page more confused than before. That just means that it has successfully destroyed your false assumptions, or that you've fallen for some horrible inside joke. Beware of [[Zygohistomorphic prepromorphisms]]. Go for [http://ertes.de/articles/monads.html warm and fuzzy], instead.<br />
<br />
==Monads are not a good choice as topic for your first Haskell blog entry==<br />
...just accept that they're [http://blog.plover.com/prog/burritos.html burritos], and wait until later.<br />
<br />
==Monads are not a language feature==<br />
Really. They are defined in terms of Haskell, not Haskell in terms of them. Conversely,<br />
<br />
==Haskell doesn't need Monads==<br />
...well, apart from the Haskell standard defining the way IO is done in terms of Monads: It could be done differently and still work.<br />
<br />
==Monads are not impure==<br />
...In no way whatsoever. You don't even need flexible morals to claim it. To be more specific, it's IO that's impure. That makes the IO monad impure. But that's not a general property of monads - just IO. And even then, we can pretend that Haskell is a purely functional description language for imperative programs. But we didn't want to employ flexible morals, now did we?<br />
<br />
==Monads are not about state==<br />
While it is certainly possible to abstract away explicit state passing by using a Monad, that's not what a monad is.<br />
<br />
(some elaboration needed -- Well, which monad most obviously uses no state at all?)<br />
<br />
==Monads are not about strictness==<br />
Monad operations (bind and return) have to be [[Non-strict semantics|lazy]] in fact, always! However<br />
other operations can be specific to each monad.<br />
For instance some are strict (like IO), and some are lazy (like []). Then there are some that come in multiple flavours, like State.<br />
<br />
Try the following:<br />
<br />
<haskell><br />
runState (sequence . repeat $ State (\x -> (x,x+1))) 0<br />
</haskell><br />
<br />
Having a look at the implementation of fixIO might be helpful, too.<br />
<br />
==Monads are not values==<br />
This point might be driven home best by pointing out that instance Monad Foo where ... is not a data type, but a declaration of a typeclass instance. However, to elaborate:<br />
<br />
Monads are not values in the same sense that addition and multiplication are not numbers: They capture a -- very specific -- relationship between values of a specific domain into a common abstraction. We're going to call these values monads manage ''mobits'', somewhat like this:<br />
<br />
<haskell><br />
type Mobit m a = Monad m => m a<br />
</haskell><br />
<br />
The IO monad manages mobits representing side-effects ("IO actions").<br />
<br />
The List monad manages mobits representing multiple values ("[a]")<br />
<br />
The Reader monads manages mobits that are pure computations that use asks to propagate information instead of explicit arguments<br />
<br />
...and while addition and multiplication are both monoids over the positive natural numbers, a monad is a monoid object in a category of endofunctors: return is the unit, and join is the binary operation. It couldn't be more simple. If that confuses you, it might be helpful to see a Monad as a lax functor from a terminal bicategory.<br />
<br />
<br />
<br />
==Monads are not a replacement for applicative functors==<br />
Instead, every monad ''is'' an applicative functor (as well as a functor). It is considered good practice not to use >>= if all you need is <*>, or even fmap.<br />
<br />
Not confusing which features of monads are specific to monads only and which stem from applicative functors is vitally important for a deeper understanding of monads. As an example, the applicative functor interface of parser libraries can parse context-free grammars (and look just like EBNF), while the monadic interface can parse context-sensitive grammars: Monads allow you to influence further processing by inspecting the result of your parse. To understand why, have a look at the type of >>=. To understand why applicative functors by themselves are sufficient to track the current parsing position, have a look at the [http://www.cs.uu.nl/research/techreps/repo/CS-2008/2008-044.pdf uu-parsinglib tutorial (pdf)].<br />
<br />
The exact differences are elaborated in even greater detail in Brent Yorgey's excellent [[Typeclassopedia]].<br />
<br />
==Monads are not about ordering/sequencing==<br />
Monads are commonly used to order sequences of computations. But this is misleading. Just as you can use monads for state, or strictness, you can use them to order computations. But there are also commutative monads, like Maybe, that don't order anything. So ordering is not in any way essential to what a monad is.<br />
<br />
I'll try to explain what's meant by ordering. Consider an expression like<br />
<br />
<haskell><br />
let x = a<br />
y = b<br />
in f x y<br />
</haskell><br />
<br />
That gives the same result as<br />
<br />
<haskell><br />
let y = b<br />
x = a<br />
in f x y<br />
</haskell><br />
<br />
It doesn't matter what order we write the two assignments. But for doing I/O we'd like ordering. Monads allow use to express<br />
<br />
<haskell><br />
do<br />
x <- getChar<br />
y <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
and have it be different from<br />
<br />
<haskell><br />
do<br />
y <- getChar<br />
x <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
The second example returns a pair of characters in the opposite order to which they were entered.<br />
<br />
However, there are monads for which swapping the order of lines like this makes no difference. For example the Maybe monad.<br />
<br />
So while it is correct to say that monads can be used to order operations, it would be wrong to say that monads are a mechanism for ordering operations.<br />
<br />
This notion of commutativity is different from the familiar the one in algebra where a+b=b+a. So it's not about the fact that<br />
<br />
<haskell><br />
(Just 2 >> Just 3) == Just 3<br />
</haskell><br />
<br />
(It took long to explain that, maybe someone can edit this down.)<br />
<br />
==See also==<br />
<br />
* [[Do notation considered harmful]]<br />
<br />
[[Category:FAQ]]</div>Ksfhttps://wiki.haskell.org/index.php?title=What_a_Monad_is_not&diff=34032What a Monad is not2010-03-12T18:09:23Z<p>Ksf: </p>
<hr />
<div>==Warning==<br />
This page is currently an unprocessed braindump. Feel free to dump additional stuff or massage stuff into didactic pleasures.<br />
<br />
Also, don't be surprised if you leave this page more confused than before. That just means that it has successfully destroyed your false assumptions, or that you've fallen for some horrible inside joke. Beware of [[Zygohistomorphic prepromorphisms]]. Go for [http://ertes.de/articles/monads.html warm and fuzzy], instead.<br />
<br />
==Monads are not a good choice as topic for your first Haskell blog entry==<br />
...just accept that they're [http://blog.plover.com/prog/burritos.html burritos], and wait until later.<br />
<br />
==Monads are not a language feature==<br />
Really. They are defined in terms of Haskell, not Haskell in terms of them. Conversely,<br />
<br />
==Haskell doesn't need Monads==<br />
...well, apart from the Haskell standard defining the way IO is done in terms of Monads: It could be done differently and still work.<br />
<br />
==Monads are not impure==<br />
...In no way whatsoever. You don't even need flexible morals to claim it. To be more specific, it's IO that's impure. That makes the IO monad impure. But that's not a general property of monads - just IO. And even then, we can pretend that Haskell is a purely functional description language for imperative programs. But we didn't want to employ flexible morals, now did we?<br />
<br />
==Monads are not about state==<br />
While it is certainly possible to abstract away explicit state passing by using a Monad, that's not what a monad is.<br />
<br />
(some elaboration needed -- Well, which monad most obviously uses no state at all?)<br />
<br />
==Monads are not about strictness==<br />
Monad operations (bind and return) have to be [[Non-strict semantics|lazy]] in fact, always! However<br />
other operations can be specific to each monad.<br />
For instance some are strict (like IO), and some are lazy (like []). Then there are some that come in multiple flavours, like State.<br />
<br />
Try the following:<br />
<br />
<haskell><br />
runState (sequence . repeat $ State (\x -> (x,x+1))) 0<br />
</haskell><br />
<br />
Having a look at the implementation of fixIO might be helpful, too.<br />
<br />
==Monads are not values==<br />
This point might be driven home best by pointing out that instance Monad Foo where ... is not a data type, but a declaration of a typeclass instance. However, to elaborate:<br />
<br />
Monads are not values in the same sense that addition and multiplication are not numbers: They capture a -- very specific -- relationship between values of a specific domain into a common abstraction. We're going to call these values monads manage ''mobits'', somewhat like this:<br />
<br />
<haskell><br />
type Mobit m a = Monad m => m a<br />
</haskell><br />
<br />
The IO monad manages mobits representing side-effects ("IO actions").<br />
<br />
The List monad manages mobits representing multiple values ("[a]")<br />
<br />
The Reader monads manages mobits that are pure computations that use asks to propagate information instead of explicit arguments<br />
<br />
...and while addition and multiplication are both monoids over the positive natural numbers, a monad is a monoid object in a category of endofunctors: return is the unit, and join is the binary operation. It couldn't be more simple. If that confuses you, it might be helpful to see a Monad as a lax functor from a terminal bicategory.<br />
<br />
<br />
<br />
==Monads are not a replacement for applicative functors==<br />
Instead, every monad ''is'' an applicative functor (as well as a functor). It is considered good practice not to use >>= if all you need is <*>, or even fmap.<br />
<br />
Not confusing which features of monads are specific to monads only and which stem from applicative functors is vitally important for a deeper understanding of monads. As an example, the applicative functor interface of parser libraries can parse context-free grammars (and look just like EBNF), while the monadic interface can parse context-sensitive grammars: Monads allow you to influence further processing by inspecting the result of your parse. To understand why, have a look at the type of >>=. To understand why applicative functors by themselves are sufficient to track the current parsing position, have a look at the uu-parsinglib tutorial.<br />
<br />
The exact differences are elaborated in even greater detail in Brent Yorgey's excellent [[Typeclassopedia]].<br />
<br />
==Monads are not about ordering/sequencing==<br />
Monads are commonly used to order sequences of computations. But this is misleading. Just as you can use monads for state, or strictness, you can use them to order computations. But there are also commutative monads, like Maybe, that don't order anything. So ordering is not in any way essential to what a monad is.<br />
<br />
I'll try to explain what's meant by ordering. Consider an expression like<br />
<br />
<haskell><br />
let x = a<br />
y = b<br />
in f x y<br />
</haskell><br />
<br />
That gives the same result as<br />
<br />
<haskell><br />
let y = b<br />
x = a<br />
in f x y<br />
</haskell><br />
<br />
It doesn't matter what order we write the two assignments. But for doing I/O we'd like ordering. Monads allow use to express<br />
<br />
<haskell><br />
do<br />
x <- getChar<br />
y <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
and have it be different from<br />
<br />
<haskell><br />
do<br />
y <- getChar<br />
x <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
The second example returns a pair of characters in the opposite order to which they were entered.<br />
<br />
However, there are monads for which swapping the order of lines like this makes no difference. For example the Maybe monad.<br />
<br />
So while it is correct to say that monads can be used to order operations, it would be wrong to say that monads are a mechanism for ordering operations.<br />
<br />
This notion of commutativity is different from the familiar the one in algebra where a+b=b+a. So it's not about the fact that<br />
<br />
<haskell><br />
(Just 2 >> Just 3) == Just 3<br />
</haskell><br />
<br />
(It took long to explain that, maybe someone can edit this down.)<br />
<br />
==See also==<br />
<br />
* [[Do notation considered harmful]]<br />
<br />
[[Category:FAQ]]</div>Ksfhttps://wiki.haskell.org/index.php?title=What_a_Monad_is_not&diff=34031What a Monad is not2010-03-12T18:04:44Z<p>Ksf: </p>
<hr />
<div>==Warning==<br />
This page is currently an unprocessed braindump. Feel free to dump additional stuff or massage stuff into didactic pleasures.<br />
<br />
Also, don't be surprised if you leave this page more confused than before. That just means that it has successfully destroyed your false assumptions, or that you've fallen for some horrible inside joke. Beware of [[Zygohistomorphic prepromorphisms]]. Go for [http://ertes.de/articles/monads.html warm and fuzzy], instead.<br />
<br />
==Monads are not a good choice as topic for your first Haskell blog entry==<br />
...just accept that they're [http://blog.plover.com/prog/burritos.html burritos], and wait until later.<br />
<br />
==Monads are not a language feature==<br />
Really. They are defined in terms of Haskell, not Haskell in terms of them. Conversely,<br />
<br />
==Haskell doesn't need Monads==<br />
...well, apart from the Haskell standard defining the way IO is done in terms of Monads: It could be done differently and still work.<br />
<br />
==Monads are not impure==<br />
...In no way whatsoever. You don't even need flexible morals to claim it. To be more specific, it's IO that's impure. That makes the IO monad impure. But that's not a general property of monads - just IO. And even then, we can pretend that Haskell is a purely functional description language for imperative programs. But we didn't want to employ flexible morals, now did we?<br />
<br />
==Monads are not about state==<br />
While it is certainly possible to abstract away explicit state passing by using a Monad, that's not what a monad is.<br />
<br />
(some elaboration needed)<br />
<br />
==Monads are not about strictness==<br />
Monad operations (bind and return) have to be [[Non-strict semantics|lazy]] in fact, always! However<br />
other operations can be specific to each monad.<br />
For instance some are strict (like IO), and some are lazy (like []). Then there are some that come in multiple flavours, like State.<br />
<br />
Try the following:<br />
<br />
<haskell><br />
runState (sequence . repeat $ State (\x -> (x,x+1))) 0<br />
</haskell><br />
<br />
Having a look at the implementation of fixIO might be helpful, too.<br />
<br />
==Monads are not values==<br />
This point might be driven home best by pointing out that instance Monad Foo where ... is not a data type, but a declaration of a typeclass instance. However, to elaborate:<br />
<br />
Monads are not values in the same sense that addition and multiplication are not numbers: They capture a -- very specific -- relationship between values of a specific domain into a common abstraction. We're going to call these values monads manage ''mobits'', somewhat like this:<br />
<br />
<haskell><br />
type Mobit m a = Monad m => m a<br />
</haskell><br />
<br />
The IO monad manages mobits representing side-effects ("IO actions").<br />
<br />
The List monad manages mobits representing multiple values ("[a]")<br />
<br />
The Reader monads manages mobits that are pure computations that use asks to propagate information instead of explicit arguments<br />
<br />
...and while addition and multiplication are both monoids over the positive natural numbers, a monad is a monoid object in a category of endofunctors: return is the unit, and join is the binary operation. It couldn't be more simple. If that confuses you, it might be helpful to see a Monad as a lax functor from a terminal bicategory.<br />
<br />
<br />
<br />
==Monads are not a replacement for applicative functors==<br />
Instead, every monad ''is'' an applicative functor (as well as a functor). It is considered good practice not to use >>= if all you need is <*>, or even fmap.<br />
<br />
Not confusing which features of monads are specific to monads only and which stem from applicative functors is vitally important for a deeper understanding of monads. As an example, the applicative functor interface of parser libraries can parse context-free grammars (and look just like EBNF), while the monadic interface can parse context-sensitive grammars: Monads allow you to influence further processing by inspecting the result of your parse. To understand why, have a look at the type of >>=. To understand why applicative functors by themselves are sufficient to track the current parsing position, have a look at the uu-parsinglib tutorial.<br />
<br />
The exact differences are elaborated in even greater detail in Brent Yorgey's excellent [[Typeclassopedia]].<br />
<br />
==Monads are not about ordering/sequencing==<br />
Monads are commonly used to order sequences of computations. But this is misleading. Just as you can use monads for state, or strictness, you can use them to order computations. But there are also commutative monads, like Maybe, that don't order anything. So ordering is not in any way essential to what a monad is.<br />
<br />
I'll try to explain what's meant by ordering. Consider an expression like<br />
<br />
<haskell><br />
let x = a<br />
y = b<br />
in f x y<br />
</haskell><br />
<br />
That gives the same result as<br />
<br />
<haskell><br />
let y = b<br />
x = a<br />
in f x y<br />
</haskell><br />
<br />
It doesn't matter what order we write the two assignments. But for doing I/O we'd like ordering. Monads allow use to express<br />
<br />
<haskell><br />
do<br />
x <- getChar<br />
y <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
and have it be different from<br />
<br />
<haskell><br />
do<br />
y <- getChar<br />
x <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
The second example returns a pair of characters in the opposite order to which they were entered.<br />
<br />
However, there are monads for which swapping the order of lines like this makes no difference. For example the Maybe monad.<br />
<br />
So while it is correct to say that monads can be used to order operations, it would be wrong to say that monads are a mechanism for ordering operations.<br />
<br />
This notion of commutativity is different from the familiar the one in algebra where a+b=b+a. So it's not about the fact that<br />
<br />
<haskell><br />
(Just 2 >> Just 3) == Just 3<br />
</haskell><br />
<br />
(It took long to explain that, maybe someone can edit this down.)<br />
<br />
==See also==<br />
<br />
* [[Do notation considered harmful]]<br />
<br />
[[Category:FAQ]]</div>Ksfhttps://wiki.haskell.org/index.php?title=What_a_Monad_is_not&diff=34030What a Monad is not2010-03-12T18:04:21Z<p>Ksf: </p>
<hr />
<div>==Warning==<br />
This page is currently an unprocessed braindump. Feel free to dump additional stuff or massage stuff into didactic pleasures.<br />
<br />
Also, don't be surprised if you leave this page more confused than before. That just means that it has successfully destroyed your false assumptions, or that you've fallen for some horrible inside joke. Beware of [[Zygohistomorphic prepromorphisms]]. Go for [http://ertes.de/articles/monads.html warm and fuzzy], instead.<br />
<br />
==Monads are not a good choice as topic for your first Haskell blog entry==<br />
...just accept that they're [http://blog.plover.com/prog/burritos.html burritos], and wait until later.<br />
<br />
==Monads are not a language feature==<br />
Really. They are defined in terms of Haskell, not Haskell in terms of them. Conversely,<br />
<br />
==Haskell doesn't need Monads==<br />
...well, apart from the Haskell standard defining the way IO is done in terms of Monads: It could be done differently and still work.<br />
<br />
==Monads are not impure==<br />
...In no way whatsoever. You don't even need flexible morals to claim it. To be more specific, it's IO that's impure. That makes the IO monad impure. But that's not a general property of monads - just IO. And even then, we can pretend that Haskell is a purely functional description language for imperative programs. But we didn't want to employ flexible morals, now did we?<br />
<br />
==Monads are not about state==<br />
While it is certainly possible to abstract away explicit state passing by using a Monad, that's not what a monad is.<br />
<br />
(some elaboration needed)<br />
<br />
==Monads are not about strictness==<br />
Monad operations (bind and return) have to be [[Non-strict semantics|lazy]] in fact, always! However<br />
other operations can be specific to each monad.<br />
For instance some are strict (like IO), and some are lazy (like []). Then there are some that come in multiple flavours, like State.<br />
<br />
Try the following:<br />
<br />
<haskell><br />
runState (sequence . repeat $ State (\x -> (x,x+1))) 0<br />
</haskell><br />
<br />
Having a look at the implementation of <haskell>fixIO</haskell> might be helpful, too.<br />
<br />
==Monads are not values==<br />
This point might be driven home best by pointing out that instance Monad Foo where ... is not a data type, but a declaration of a typeclass instance. However, to elaborate:<br />
<br />
Monads are not values in the same sense that addition and multiplication are not numbers: They capture a -- very specific -- relationship between values of a specific domain into a common abstraction. We're going to call these values monads manage ''mobits'', somewhat like this:<br />
<br />
<haskell><br />
type Mobit m a = Monad m => m a<br />
</haskell><br />
<br />
The IO monad manages mobits representing side-effects ("IO actions").<br />
<br />
The List monad manages mobits representing multiple values ("[a]")<br />
<br />
The Reader monads manages mobits that are pure computations that use asks to propagate information instead of explicit arguments<br />
<br />
...and while addition and multiplication are both monoids over the positive natural numbers, a monad is a monoid object in a category of endofunctors: return is the unit, and join is the binary operation. It couldn't be more simple. If that confuses you, it might be helpful to see a Monad as a lax functor from a terminal bicategory.<br />
<br />
<br />
<br />
==Monads are not a replacement for applicative functors==<br />
Instead, every monad ''is'' an applicative functor (as well as a functor). It is considered good practice not to use >>= if all you need is <*>, or even fmap.<br />
<br />
Not confusing which features of monads are specific to monads only and which stem from applicative functors is vitally important for a deeper understanding of monads. As an example, the applicative functor interface of parser libraries can parse context-free grammars (and look just like EBNF), while the monadic interface can parse context-sensitive grammars: Monads allow you to influence further processing by inspecting the result of your parse. To understand why, have a look at the type of >>=. To understand why applicative functors by themselves are sufficient to track the current parsing position, have a look at the uu-parsinglib tutorial.<br />
<br />
The exact differences are elaborated in even greater detail in Brent Yorgey's excellent [[Typeclassopedia]].<br />
<br />
==Monads are not about ordering/sequencing==<br />
Monads are commonly used to order sequences of computations. But this is misleading. Just as you can use monads for state, or strictness, you can use them to order computations. But there are also commutative monads, like Maybe, that don't order anything. So ordering is not in any way essential to what a monad is.<br />
<br />
I'll try to explain what's meant by ordering. Consider an expression like<br />
<br />
<haskell><br />
let x = a<br />
y = b<br />
in f x y<br />
</haskell><br />
<br />
That gives the same result as<br />
<br />
<haskell><br />
let y = b<br />
x = a<br />
in f x y<br />
</haskell><br />
<br />
It doesn't matter what order we write the two assignments. But for doing I/O we'd like ordering. Monads allow use to express<br />
<br />
<haskell><br />
do<br />
x <- getChar<br />
y <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
and have it be different from<br />
<br />
<haskell><br />
do<br />
y <- getChar<br />
x <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
The second example returns a pair of characters in the opposite order to which they were entered.<br />
<br />
However, there are monads for which swapping the order of lines like this makes no difference. For example the Maybe monad.<br />
<br />
So while it is correct to say that monads can be used to order operations, it would be wrong to say that monads are a mechanism for ordering operations.<br />
<br />
This notion of commutativity is different from the familiar the one in algebra where a+b=b+a. So it's not about the fact that<br />
<br />
<haskell><br />
(Just 2 >> Just 3) == Just 3<br />
</haskell><br />
<br />
(It took long to explain that, maybe someone can edit this down.)<br />
<br />
==See also==<br />
<br />
* [[Do notation considered harmful]]<br />
<br />
[[Category:FAQ]]</div>Ksfhttps://wiki.haskell.org/index.php?title=What_a_Monad_is_not&diff=34029What a Monad is not2010-03-12T18:00:17Z<p>Ksf: </p>
<hr />
<div>==Warning==<br />
This page is currently an unprocessed braindump. Feel free to dump additional stuff or massage stuff into didactic pleasures.<br />
<br />
Also, don't be surprised if you leave this page more confused than before. That just means that it has successfully destroyed your false assumptions, or that you've fallen for some horrible inside joke. Beware of [[Zygohistomorphic prepromorphisms]]. Go for [http://ertes.de/articles/monads.html warm and fuzzy], instead.<br />
<br />
==Monads are not a good choice as topic for your first Haskell blog entry==<br />
...just accept that they're [http://blog.plover.com/prog/burritos.html burritos], and wait until later.<br />
<br />
==Monads are not a language feature==<br />
Really. They are defined in terms of Haskell, not Haskell in terms of them. Conversely,<br />
<br />
==Haskell doesn't need Monads==<br />
...well, apart from the Haskell standard defining the way IO is done in terms of Monads: It could be done differently and still work.<br />
<br />
==Monads are not impure==<br />
...In no way whatsoever. You don't even need flexible morals to claim it. To be more specific, it's IO that's impure. That makes the IO monad impure. But that's not a general property of monads - just IO. And even then, we can pretend that Haskell is a purely functional description language for imperative programs. But we didn't want to employ flexible morals, now did we?<br />
<br />
==Monads are not about state==<br />
While it is certainly possible to abstract away explicit state passing by using a Monad, that's not what a monad is.<br />
<br />
(some elaboration needed)<br />
<br />
==Monads are not about strictness==<br />
Monad operations (bind and return) have to be [[Non-strict semantics|lazy]] in fact, always! However<br />
other operations can be specific to each monad.<br />
For instance some are strict (like IO), and some are lazy (like []). Then there are some that come in multiple flavours, like State.<br />
<br />
Try the following:<br />
<br />
<haskell><br />
runState (sequence . repeat $ State (\x -> (x,x+1))) 0<br />
</haskell><br />
<br />
==Monads are not values==<br />
This point might be driven home best by pointing out that instance Monad Foo where ... is not a data type, but a declaration of a typeclass instance. However, to elaborate:<br />
<br />
Monads are not values in the same sense that addition and multiplication are not numbers: They capture a -- very specific -- relationship between values of a specific domain into a common abstraction. We're going to call these values monads manage ''mobits'', somewhat like this:<br />
<br />
<haskell><br />
type Mobit m a = Monad m => m a<br />
</haskell><br />
<br />
The IO monad manages mobits representing side-effects ("IO actions").<br />
<br />
The List monad manages mobits representing multiple values ("[a]")<br />
<br />
The Reader monads manages mobits that are pure computations that use asks to propagate information instead of explicit arguments<br />
<br />
...and while addition and multiplication are both monoids over the positive natural numbers, a monad is a monoid object in a category of endofunctors: return is the unit, and join is the binary operation. It couldn't be more simple. If that confuses you, it might be helpful to see a Monad as a lax functor from a terminal bicategory.<br />
<br />
<br />
<br />
==Monads are not a replacement for applicative functors==<br />
Instead, every monad ''is'' an applicative functor (as well as a functor). It is considered good practice not to use >>= if all you need is <*>, or even fmap.<br />
<br />
Not confusing which features of monads are specific to monads only and which stem from applicative functors is vitally important for a deeper understanding of monads. As an example, the applicative functor interface of parser libraries can parse context-free grammars (and look just like EBNF), while the monadic interface can parse context-sensitive grammars: Monads allow you to influence further processing by inspecting the result of your parse. To understand why, have a look at the type of >>=. To understand why applicative functors by themselves are sufficient to track the current parsing position, have a look at the uu-parsinglib tutorial.<br />
<br />
The exact differences are elaborated in even greater detail in Brent Yorgey's excellent [[Typeclassopedia]].<br />
<br />
==Monads are not about ordering/sequencing==<br />
Monads are commonly used to order sequences of computations. But this is misleading. Just as you can use monads for state, or strictness, you can use them to order computations. But there are also commutative monads, like Maybe, that don't order anything. So ordering is not in any way essential to what a monad is.<br />
<br />
I'll try to explain what's meant by ordering. Consider an expression like<br />
<br />
<haskell><br />
let x = a<br />
y = b<br />
in f x y<br />
</haskell><br />
<br />
That gives the same result as<br />
<br />
<haskell><br />
let y = b<br />
x = a<br />
in f x y<br />
</haskell><br />
<br />
It doesn't matter what order we write the two assignments. But for doing I/O we'd like ordering. Monads allow use to express<br />
<br />
<haskell><br />
do<br />
x <- getChar<br />
y <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
and have it be different from<br />
<br />
<haskell><br />
do<br />
y <- getChar<br />
x <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
The second example returns a pair of characters in the opposite order to which they were entered.<br />
<br />
However, there are monads for which swapping the order of lines like this makes no difference. For example the Maybe monad.<br />
<br />
So while it is correct to say that monads can be used to order operations, it would be wrong to say that monads are a mechanism for ordering operations.<br />
<br />
This notion of commutativity is different from the familiar the one in algebra where a+b=b+a. So it's not about the fact that<br />
<br />
<haskell><br />
(Just 2 >> Just 3) == Just 3<br />
</haskell><br />
<br />
(It took long to explain that, maybe someone can edit this down.)<br />
<br />
==See also==<br />
<br />
* [[Do notation considered harmful]]<br />
<br />
[[Category:FAQ]]</div>Ksfhttps://wiki.haskell.org/index.php?title=Monad_tutorials_timeline&diff=33569Monad tutorials timeline2010-02-12T13:11:27Z<p>Ksf: </p>
<hr />
<div>[[Category:History]]<br />
[[Category:Monad]]<br />
[[Category:Tutorials]]<br />
<br />
This timeline covers not just monad tutorials, but interesting events in monad tutorial history. Please update this list! Don't worry about getting dates, authors, blurbs unless you really want to. We can fix it later.<br />
<br />
Older tutorials are especially interesting.<br />
<br />
== before 2000 ==<br />
<br />
* 1992-08 [http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/baastad.pdf Monads for Functional Programming] - Phil Wadler<br />
*: "Shall I be pure or impure?" One of the earliest papers on monads by the man hiself. Has been called the "''ne plus ultra'' of approachable, useful introductions to monads". It's pretty hefty (31 pages), which is a good thing!<br />
* 1999-02 [http://www-users.mat.uni.torun.pl/~fly/materialy/fp/haskell-doc/Monads.html What the hell are Monads?] Noel Winstanley<br />
*: Written when 'what is a monad' started becoming an FAQ. Very short and sweet, advertised as more examples than theory. "Once upon a time, people wrote their Haskell programs by sequencing together operations in an ad-hoc way."<br />
* 1999-Spring [http://www.engr.mun.ca/~theo/Misc/haskell_and_monads.htm Monads for the working Haskell Programmer] - Theodore S. Norvell<br />
*: One of the original tutorials, originally written for Gofer and eventually "updated for Haskell98"<br />
<br />
== year 2002 ==<br />
<br />
* 2002 [http://en.wikibooks.org/wiki/Haskell/YAHT Yet Another Haskell Tutorial] - Hal Daumé III<br />
*: The most recommended Haskell tutorial ever. Not a monad tutorial per se, but it does address the topic<br />
<br />
== year 2003 ==<br />
<br />
* 2003-08 [http://www.haskell.org/all_about_monads/html/ All about Monads] - Jeff Newbern<br />
*: A comprehensive introduction to monads, covering also "advanced" topics like monad transformers and use of some common monads. There is an appendix which presents monads as assembly lines.<br />
<br />
== year 2004 ==<br />
<br />
* 2004-07 [http://www.ccs.neu.edu/home/dherman/research/tutorials/monads-for-schemers.txt A Schemer's Introduction to Monads]<br />
*: "This will be an introduction to monads from a Lisp/Scheme perspective, with the assumption that the reader is comfortable with continuations, CPS, accumulators, and accumulator-passing style."<br />
* 2004-07 [[Monads as Containers]] - Cale Gibbard<br />
*: Presents monads as boxes. Uses <hask>fmap</hask> and <hask>join</hask>. "If you will give me a blueberry for each apple I give you <hask>(a -> b)</hask>, and I have a box of apples <hask>(f a)</hask>, then I can get a box of blueberries <hask>(f b)</hask>."<br />
* 2004-08 [http://sleepingsquirrel.org/monads/monads.html Monads in Perl] - Greg Buchholz<br />
*: Written in the spirit of TMTOWTDI<br />
<br />
== year 2005 ==<br />
<br />
* 2005-07 [http://moonbase.rydia.net/mental/writings/programming/monads-in-ruby/00introduction.html Monads in Ruby] - MenTaLguY<br />
*: Presents monads in a friendly language, starting from Identity and building on up<br />
* 2005-11 [http://www.loria.fr/~kow/monads Of monads and space suits] - Eric Kow<br />
*: Functions are space stations, parameters are astronauts and monads are space suits that let us safely travel from one function to another.<br />
<br />
== year 2006 ==<br />
<br />
* 2006-03 [http://en.wikibooks.org/w/index.php?title=Haskell/Understanding_monads&oldid=933545 Understanding Monads] - Eric Kow<br />
*: Monads as nuclear waste containers, an adaptation of monads as space suits with a new metaphor suggested by Paul Johnson<br />
* 2006-07 [[The Monadic Way]] - Andrea Rossato<br />
*: A two-part tutorial. The first part shows you how build a simple evaluator, and the second part shows you how to "take the complexity" out of it by using techniques such as monad transformers<br />
* 2006-08 [http://sigfpe.blogspot.com/2006/08/you-could-have-invented-monads-and.html You could have invented monads! (and maybe you already have)] - Dan Piponi<br />
*: "Writing introductions to monads seems to have developed into an industry," Dan (sigfpe) observes. He argues that monads are not "something esoteric in need of explanation", but walks you through the process of reinventing monads to solve some very basic and practical problems.<br />
* 2006-09 [[Meet Bob The Monadic Lover]] - Andrea Rossato<br />
*: Bob embarks upon a series of romantic conquests... bind bind bind, Paula, Luisa, Antonia<br />
* 2006-10 [http://www.grabmueller.de/martin/www/pub/Transformers.en.html Monad Transformers Step by Step] - Martin Grabmüller<br />
** Monad transformers are rarely covered in introductory tutorials. This "is not a paper about implementing transformers, but about using them to write elegant, clean and powerful programs in Haskell". Available as a 12 page PDF or .lhs file.<br />
* 2006-11 [http://www.haskell.org/pipermail/haskell-cafe/2006-November/019190.html There's a Monster in my Haskell!] Andrew Pimlott<br />
*: This delightful "tutorial" presents monads as monsters which devour values, use them to feed other monsters and regurgitate them when slain.<br />
* 2006-12 [http://blog.tmorris.net/maybe-monad-in-java/ Maybe Monad in Java] - Tony Morris<br />
*: Monads can also be useful in Java!<br />
<br />
== year 2007 ==<br />
<br />
* 2007-01 [http://koweycode.blogspot.com/2007/01/think-of-monad.html Think of a monad] - Don Stewart (reposted on Eric Kow's blog)<br />
*: Don integrates some pre-existing monadic metaphors, shedding light on monads in a truly comprehensive manner (illustration by Eric)<br />
* 2007-02 [http://kawagner.blogspot.com/2007/02/understanding-monads-for-real.html Understanding Monads. For Real] - Karsten Wagner<br />
*: A monad is like a macro<br />
* 2007-02 [http://patryshev.com/monad/m-intro.html Crash Course in Monads] Monads for Mathematicians<br />
*:Author's Description: This crash course starts with an EASY! introduction to categories and functors, then we define a monad, then give some basic examples of monads in categories, then present monadic terminology as used in programming languages.<br />
*: Then I lie down in a dark room with a warm wet cloth over my eyes.<br />
* 2007-04 [http://saxophone.jpberlin.de/MonadTransformer?source=http%3A%2F%2Fwww%2Ehaskell%2Eorg%2Fhaskellwiki%2FCategory%3AMonad&language=English The Real Monad Transformer] - Henning Thielemann<br />
*: Not a tutorial either, but an important aid in demystifying monads<br />
* 2007-03 [http://www.randomhacks.net/articles/2007/03/12/monads-in-15-minutes Monads in 15 Minutes] - Eric Kidd<br />
*: Eric boils monads down to 15 minutes, using backtracking and Maybe as motivating examples. Eric uses <hask>join</hask>, which seems quite rare for monad tutorials (cf Cale's ''Monads as containers'')<br />
* 2007-07 [http://ahamsandwich.wordpress.com/2007/07/26/monads-and-why-monad-tutorials-are-all-awful/ Monads! (and why monad tutorials are all awful)] - Colin Gordon?<br />
*: Csgordon reports that monad tutorials tend to "get horribly botched" and says "[they] either bored me to tears, struck me as completely inane, or simply confused me". He uncovers the early Phil Wadler's paper, ''Monads for Functional Programming'', which not only gives a clear explanation but provides ''non-trivial'' motivating examples<br />
* 2007-08 [[Monads as computation]] - Cale Gibbard<br />
*: A very straightforward presentation of monads. Notable for its "The whole point" section, which conveys why we bother with all this monad business.<br />
* 2007-08 [http://en.wikibooks.org/wiki/Haskell/Understanding%20monads Understanding Monads] (2) - Apfelmus<br />
*: Wikibook rewrite of the original monads tutorial. Less fluff, more pedagogy. [In progress at the time of this writing].<br />
* 2007-08 [[Monad (sans metaphors)]] - Claus Reinke<br />
*: From a discussion about monad tutorials on Haskell Café (the name is due to haskellwiki user 'Green tea').<br />
<br />
== year 2008 ==<br />
* 2008-06 [http://spbhug.folding-maps.org/wiki/Monads Monads] (in Russian) and [http://spbhug.folding-maps.org/wiki/MonadsEn Monads] (in English) - Yet another monad tutorial, by Eugene Kirpichov; fairly advanced but skips monad transformers. Oriented towards a broader understanding of monads than just IO and Maybe.<br />
<br />
== year 2009 ==<br />
* 2009-01 [http://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ Abstraction, intuition, and the “monad tutorial fallacy”] Not a monad tutorial itself, but a comment on monad tutorials and why many of them are so unhelpful.<br />
<br />
* 2009-03 [http://onclojure.com/2009/03/05/a-monad-tutorial-for-clojure-programmers-part-1/ A Monad Tutorial for Clojure Programmers] An interesting perspective on monads .<br />
<br />
* 2009-11 [[What a Monad is not]] A desperate attempt to end the eternal chain of monad tutorials</div>Ksfhttps://wiki.haskell.org/index.php?title=What_a_Monad_is_not&diff=33568What a Monad is not2010-02-12T12:26:53Z<p>Ksf: </p>
<hr />
<div>==Warning==<br />
This page is currently an unprocessed braindump. Feel free to dump additional stuff or massage stuff into didactic pleasures.<br />
<br />
Also, don't be surprised if you leave this page more confused than before. That just means that it has successfully destroyed your false assumptions, or that you've fallen for some horrible inside joke. Beware of [[Zygohistomorphic prepromorphisms]]. Go for [http://ertes.de/articles/monads.html warm and fuzzy], instead.<br />
<br />
==Monads are not a good choice as topic for your first Haskell blog entry==<br />
...just accept that they're [http://blog.plover.com/prog/burritos.html burritos], and wait until later.<br />
<br />
==Monads are not a language feature==<br />
Really. They are defined in terms of Haskell, not Haskell in terms of them. Conversely,<br />
<br />
==Haskell doesn't need Monads==<br />
...well, apart from the Haskell standard defining the way IO is done in terms of Monads: It could be done differently and still work.<br />
<br />
==Monads are not impure==<br />
...In no way whatsoever. You don't even need flexible morals to claim it. To be more specific, it's IO that's impure. That makes the IO monad impure. But that's not a general property of monads - just IO. And even then, we can pretend that Haskell is a purely functional description language for imperative programs. But we didn't want to employ flexible morals, now did we?<br />
<br />
==Monads are not about state==<br />
While it is certainly possible to abstract away explicit state passing by using a Monad, that's not what a monad is.<br />
<br />
(some elaboration needed)<br />
<br />
==Monads are not about strictness==<br />
Monad operations (bind and return) have to be [[Non-strict semantics|lazy]] in fact, always! However<br />
other operations can be specific to each monad.<br />
For instance some are strict (like IO), and some are lazy (like []). Then there are some that come in multiple flavours, like State.<br />
<br />
==Monads are not values==<br />
This point might be driven home best by pointing out that instance Monad Foo where ... is not a data type, but a declaration of a typeclass instance. However, to elaborate:<br />
<br />
Monads are not values in the same sense that addition and multiplication are not numbers: They capture a -- very specific -- relationship between values of a specific domain into a common abstraction. We're going to call these values monads manage ''mobits'', somewhat like this:<br />
<br />
<haskell><br />
type Mobit m a = Monad m => m a<br />
</haskell><br />
<br />
The IO monad manages mobits representing side-effects ("IO actions").<br />
<br />
The List monad manages mobits representing multiple values ("[a]")<br />
<br />
The Reader monads manages mobits that are pure computations that use asks to propagate information instead of explicit arguments<br />
<br />
...and while addition and multiplication are both monoids over the positive natural numbers, a monad is a monoid object in a category of endofunctors: return is the unit, and join is the binary operation. It couldn't be more simple. If that confuses you, it might be helpful to see a Monad as a lax functor from a terminal bicategory.<br />
<br />
<br />
<br />
==Monads are not a replacement for applicative functors==<br />
Instead, every monad ''is'' an applicative functor (as well as a functor). It is considered good practice not to use >>= if all you need is <*>, or even fmap.<br />
<br />
Not confusing which features of monads are specific to monads only and which stem from applicative functors is vitally important for a deeper understanding of monads. As an example, the applicative functor interface of parser libraries can parse context-free grammars (and look just like EBNF), while the monadic interface can parse context-sensitive grammars: Monads allow you to influence further processing by inspecting the result of your parse. To understand why, have a look at the type of >>=. To understand why applicative functors by themselves are sufficient to track the current parsing position, have a look at the uu-parsinglib tutorial.<br />
<br />
The exact differences are elaborated in even greater detail in Brent Yorgey's excellent [[Typeclassopedia]].<br />
<br />
==Monads are not about ordering/sequencing==<br />
Monads are commonly used to order sequences of computations. But this is misleading. Just as you can use monads for state, or strictness, you can use them to order computations. But there are also commutative monads, like Maybe, that don't order anything. So ordering is not in any way essential to what a monad is.<br />
<br />
I'll try to explain what's meant by ordering. Consider an expression like<br />
<br />
<haskell><br />
let x = a<br />
y = b<br />
in f x y<br />
</haskell><br />
<br />
That gives the same result as<br />
<br />
<haskell><br />
let y = b<br />
x = a<br />
in f x y<br />
</haskell><br />
<br />
It doesn't matter what order we write the two assignments. But for doing I/O we'd like ordering. Monads allow use to express<br />
<br />
<haskell><br />
do<br />
x <- getChar<br />
y <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
and have it be different from<br />
<br />
<haskell><br />
do<br />
y <- getChar<br />
x <- getChar<br />
return (x,y)<br />
</haskell><br />
<br />
The second example returns a pair of characters in the opposite order to which they were entered.<br />
<br />
However, there are monads for which swapping the order of lines like this makes no difference. For example the Maybe monad.<br />
<br />
So while it is correct to say that monads can be used to order operations, it would be wrong to say that monads are a mechanism for ordering operations.<br />
<br />
This notion of commutativity is different from the familiar the one in algebra where a+b=b+a. So it's not about the fact that<br />
<br />
<haskell><br />
(Just 2 >> Just 3) == Just 3<br />
</haskell><br />
<br />
(It took long to explain that, maybe someone can edit this down.)<br />
<br />
==See also==<br />
<br />
* [[Do notation considered harmful]]<br />
<br />
[[Category:FAQ]]</div>Ksfhttps://wiki.haskell.org/index.php?title=Yhc/Building&diff=33467Yhc/Building2010-02-05T10:31:14Z<p>Ksf: Fixed darcs link, removed stale http interface link</p>
<hr />
<div>{{Yhc}}<br />
<br />
== Requirements ==<br />
<br />
You need a C compiler - both gcc and MS Visual C are known to be OK.<br />
<br />
You need [http://www.scons.org/ scons], which in turn requires [http://www.python.org/ Python] to be installed. We require Python 2.3 or later to be installed.<br />
<br />
The process of building Yhc requires [http://haskell.org/ghc/ ghc-6.4] or later and [http://darcs.net/ darcs].<br />
<br />
== Getting the code ==<br />
<br />
The source code is stored in a [http://www.darcs.net/ darcs] repo, to get the code do:<br />
<br />
darcs get --partial http://darcs.haskell.org/york-compiler98/<br />
<br />
There is a buildbot script that runs on every change, the results of which are available [http://www.indiegigs.co.uk:8010/ here]. If the build is busted, hopefully the developers will fix it soon. If your build is busted, but the buildbot succeeds, [[Yhc/Buildbot| consider adding your machine as a buildbot slave]] - then it will never get broken again.<br />
<br />
== Building ==<br />
<br />
To build yhc simply type 'scons' into a console Window. This should automatically detect your build environment and place the Yhc binaries into inst/<br />
<br />
To build parts of Yhc separately the following commands can be used:<br />
* scons configure - Just configure.<br />
* scons build - Don't update dependencies, just build.<br />
* scons build yhi - Only build the interpretor.<br />
* scons build yhc - Only build the compiler.<br />
* scons build library - Only build the libraries.<br />
<br />
Other commands available are:<br />
* scons clean - Remove temporary files.<br />
* scons fullclean - Completely wipe everything created by the build process.<br />
* scons depends - Download or update the dependencies<br />
* scons help - Show a help message<br />
<br />
To test Yhc has been build correctly type 'scons test'.<br />
<br />
Please report any problems you have to the mailing list.<br />
<br />
<small><br />
Please also note that these steps do not currently build the Javascript backend; please refer to [[Yhc/Javascript/Users_guide|Yhc/Javascript/Users guide]] for information how to build '''ycr2js'''.<br />
</small><br />
<br />
== Scons options ==<br />
<br />
Options can be given to scons by either passing the flags on the command line 'core=1' or by creating a file called options.txt in the root Yhc directory. The available flags are:<br />
<br />
* core=1 (default=1) - generate Yhc Core files for each file in the libraries<br />
* arch=X86 (default=calculated) - override the arch, useful for building 32 bit version on a 64 bit kernel.<br />
* type=release/debug/normal (default=normal) - enables debug information or optimisation<br />
* threads=0 (default=1, except on ppc where the default is 0) - disables threading<br />
<br />
== If something goes wrong ==<br />
<br />
If the build fails for any reason, try the following steps:<br />
<br />
; scons fullclean<br />
; scons depends<br />
<br />
Then try building again.<br />
<br />
== Build options ==<br />
<br />
"scons help" shows some options for the build process.<br />
<br />
To build with additional library/header paths, e.g. for GMP:<br />
<br />
CCFLAGS="-I/.../include" LIBPATH=/.../lib scons</div>Ksfhttps://wiki.haskell.org/index.php?title=File:Ksf-Yi.svg&diff=32769File:Ksf-Yi.svg2009-12-27T05:14:27Z<p>Ksf: </p>
<hr />
<div></div>Ksfhttps://wiki.haskell.org/index.php?title=What_a_Monad_is_not&diff=32689What a Monad is not2009-12-21T15:46:19Z<p>Ksf: Changed the burrito link</p>
<hr />
<div>==Warning==<br />
This page is currently an unprocessed braindump. Feel free to dump additional stuff or massage stuff into didactic pleasures.<br />
<br />
Also, don't be surprised if you leave this page more confused than before. That just means that it has successfully destroyed your false assumptions, or that you've fallen for some horrible inside joke. Beware of [[Zygohistomorphic prepromorphisms]]. Go for [http://ertes.de/articles/monads.html warm and fuzzy], instead.<br />
<br />
==Monads are not a good choice as topic for your first Haskell blog entry==<br />
...just accept that they're [http://blog.plover.com/prog/burritos.html burritos], and wait until later.<br />
<br />
==Monads are not a language feature==<br />
Really. They are defined in terms of Haskell, not Haskell in terms of them. Conversely,<br />
<br />
==Haskell doesn't need Monads==<br />
...well, apart from the Haskell standard defining the way IO is done in terms of Monads: It could be done differently and still work.<br />
<br />
==Monads are not impure==<br />
...In no way whatsoever. You don't even need flexible morals to claim it. To be more specific, it's IO that's impure. That makes the IO monad impure. But that's not a general property of monads - just IO. And even then, we can pretend that Haskell is a purely functional description language for imperative programs. But we didn't want to employ flexible morals, now did we?<br />
<br />
==Monads are not about state==<br />
While it is certainly possible to abstract away explicit state passing by using a Monad, that's not what a monad is.<br />
<br />
(some elaboration needed)<br />
<br />
==Monads are not about strictness==<br />
Monad operations (bind and return) have to be lazy in fact, always! However<br />
other operations can be specific to each monad.<br />
For instance some are strict (like IO), and some are lazy (like []). Then there are some that come in multiple flavours, like State.<br />
<br />
==Monads are not values==<br />
This point might be driven home best by pointing out that instance Monad Foo where ... is not a data type, but a declaration of a typeclass instance. However, to elaborate:<br />
<br />
Monads are not values in the same sense that addition and multiplication are not numbers: They capture a -- very specific -- relationship between values of a specific domain into a common abstraction. We're going to call these values monads manage ''mobits'', somewhat like this:<br />
<br />
type Mobit m a = Monad m => m a<br />
<br />
The IO monad manages mobits representing side-effects ("IO actions").<br />
<br />
The List monad manages mobits representing multiple values ("[a]")<br />
<br />
The Reader monads manages mobits that are pure computations that use asks to propagate information instead of explicit arguments<br />
<br />
...and while addition and multiplication are both monoids over the positive natural numbers, a monad is a monoid object in a category of endofunctors: return is the unit, and join is the binary operation. It couldn't be more simple.<br />
<br />
<br />
<br />
==Monads are not a replacement for applicative functors==<br />
Instead, every monad ''is'' an applicative functor (as well as a functor). It is considered good practice not to use >>= if all you need is <*>, or even fmap.<br />
<br />
Not confusing which features of monads are specific to monads only and which stem from applicative functors is vitally important for a deeper understanding of monads. As an example, the applicative functor interface of parser libraries can parse context-free grammars (and look just like EBNF), while the monadic interface can parse context-sensitive grammars: Monads allow you to influence further processing by inspecting the result of your parse. To understand why, have a look at the type of >>=. To understand why applicative functors by themselves are sufficient to track the current parsing position, have a look at the uu-parsinglib tutorial.<br />
<br />
The exact differences are elaborated in even greater detail in Brent Yorgey's excellent [[Typeclassopedia]].<br />
<br />
==Monads are not about ordering==<br />
Monads are commonly used to order sequences of computations. But this is misleading. Just as you can use monads for state, or strictness, you can use them to order computations. But there are also commutative monads, like Maybe, that don't order anything. So ordering is not in any way essential to what a monad is.<br />
<br />
I'll try to explain what's meant by ordering. Consider an expression like<br />
<br />
let x = a<br />
y = b<br />
in f x y<br />
<br />
That gives the same result as<br />
<br />
let y = b<br />
x = a<br />
in f x y<br />
<br />
It doesn't matter what order we write the two assignments. But for doing I/O we'd like ordering. Monads allow use to express<br />
<br />
do<br />
x <- getChar<br />
y <- getChar<br />
return (x,y)<br />
<br />
and have it be different from<br />
<br />
do<br />
y <- getChar<br />
x <- getChar<br />
return (x,y)<br />
<br />
The second example returns a pair of characters in the opposite order to which they were entered.<br />
<br />
However, there are monads for which swapping the order of lines like this makes no difference. For example the Maybe monad.<br />
<br />
So while it is correct to say that monads can be used to order operations, it would be wrong to say that monads are a mechanism for ordering operations.<br />
<br />
This notion of commutativity is different from the familiar the one in algebra where a+b=b+a. So it's not about the fact that<br />
<br />
(Just 2 >> Just 3) == Just 3<br />
<br />
(It took long to explain that, maybe someone can edit this down.)</div>Ksfhttps://wiki.haskell.org/index.php?title=What_a_Monad_is_not&diff=31958What a Monad is not2009-11-26T10:15:31Z<p>Ksf: </p>
<hr />
<div>==Warning==<br />
This page is currently an unprocessed braindump. Feel free to dump additional stuff or massage stuff into didactic pleasures.<br />
<br />
Also, don't be surprised if you leave this page more confused than before. That just means that it has successfully destroyed your false assumptions, or that you've fallen for some horrible inside joke. Beware of [[Zygohistomorphic prepromorphisms]]. Go for [http://ertes.de/articles/monads.html warm and fuzzy], instead.<br />
<br />
==Monads are not a good choice as topic for your first Haskell blog entry==<br />
...just accept that they're [http://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ burritos], and wait until later.<br />
<br />
==Monads are not a language feature==<br />
Really. They are defined in terms of Haskell, not Haskell in terms of them. Conversely,<br />
<br />
==Haskell doesn't need Monads==<br />
...well, apart from the Haskell standard defining the way IO is done in terms of Monads: It could be done differently and still work.<br />
<br />
==Monads are not impure==<br />
...In no way whatsoever. You don't even need flexible morals to claim it. To be more specific, it's IO that's impure. That makes the IO monad impure. But that's not a general property of monads - just IO. And even then, we can pretend that Haskell is a purely functional description language for imperative programs. But we didn't want to employ flexible morals, now did we?<br />
<br />
==Monads are not about state==<br />
While it is certainly possible to abstract away explicit state passing by using a Monad, that's not what a monad is.<br />
<br />
(some elaboration needed)<br />
<br />
==Monads are not about strictness==<br />
Monad operations (bind and return) have to be lazy in fact, always! However<br />
other operations can be specific to each monad.<br />
For instance some are strict (like IO), and some are lazy (like []). Then there are some that come in multiple flavours, like State.<br />
<br />
==Monads are not values==<br />
This point might be driven home best by pointing out that instance Monad Foo where ... is not a data type, but a declaration of a typeclass instance. However, to elaborate:<br />
<br />
Monads are not values in the same sense that addition and multiplication are not numbers: They capture a -- very specific -- relationship between values of a specific domain into a common abstraction. We're going to call these values monads manage ''mobits'', somewhat like this:<br />
<br />
type Mobit m a = Monad m => m a<br />
<br />
The IO monad manages mobits representing side-effects ("IO actions").<br />
<br />
The List monad manages mobits representing multiple values ("[a]")<br />
<br />
The Reader monads manages mobits that are pure computations that use asks to propagate information instead of explicit arguments<br />
<br />
...and while addition and multiplication are both monoids over the positive natural numbers, a monad is a monoid object in a category of endofunctors: return is the unit, and join is the binary operation. It couldn't be more simple.<br />
<br />
<br />
<br />
==Monads are not a replacement for applicative functors==<br />
Instead, every monad ''is'' an applicative functor (as well as a functor). It is considered good practice not to use >>= if all you need is <*>, or even fmap.<br />
<br />
Not confusing what features of monads are specific to monads only and which stem from applicative functors are vitally important for a deeper understanding of monads. As an example, the applicative functor interface of parser libraries can parse context-free grammars (and look just like EBNF), while the monadic interface can parse context-sensitive grammars: Monads allow you to influence further processing by inspecting the result of your parse. To understand why, have a look at the type of >>=. To understand why applicative functors by themselves are sufficient to track the current parsing position, have a look at the uu-parsinglib tutorial.<br />
<br />
The exact differences are elaborated in even greater detail in Brent Yorgey's excellent [[Typeclassopedia]].<br />
<br />
==Monads are not about ordering==<br />
It's a commonplace that monads are about ordering sequences of computations. But this is misleading. Just as you can use monads for state, or strictness, you can use them to order computations. But there are also commutative monads, like Maybe, that don't order anything. So ordering is not in any way essential to what a monad is.<br />
<br />
I'll try to explain what's meant by ordering. Consider an expression like<br />
<br />
let x = a<br />
y = b<br />
in f x y<br />
<br />
That gives the same result as<br />
<br />
let y = b<br />
x = a<br />
in f x y<br />
<br />
It doesn't matter what order we write the two assignments. But for doing I/O we'd like ordering. Monads allow use to express<br />
<br />
do<br />
x <- getChar<br />
y <- getChar<br />
return (x,y)<br />
<br />
and have it be different to<br />
<br />
do<br />
y <- getChar<br />
x <- getChar<br />
return (x,y)<br />
<br />
The second example returns a pair of characters in the opposite order to which they were entered.<br />
<br />
However, there are monads for which swapping the order of lines like this makes no difference. For example the Maybe monad.<br />
<br />
So while it is correct to say that monads can be used to order operations, it would be wrong to say that monads are a mechanism for ordering operations.<br />
<br />
This notion of commutativity is different from the familiar the one in algebra where a+b=b+a. So it's not about the fact that<br />
<br />
(Just 2 >> Just 3) == Just 3<br />
<br />
(It took long to explain that, maybe someone can edit this down.)</div>Ksf