https://wiki.haskell.org/api.php?action=feedcontributions&user=Sigfpe&feedformat=atomHaskellWiki - User contributions [en]2021-02-25T07:00:09ZUser contributionsMediaWiki 1.27.4https://wiki.haskell.org/index.php?title=What_a_Monad_is_not&diff=31787What a Monad is not2009-11-23T22:43:45Z<p>Sigfpe: </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 />
==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 in a category of endofunctors. It's all very 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>Sigfpehttps://wiki.haskell.org/index.php?title=What_a_Monad_is_not&diff=31765What a Monad is not2009-11-23T18:59:29Z<p>Sigfpe: Monads and ordering computations</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 />
==Monads are not a good choice to write your first Haskell blog about: They're more like burritos.==<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 />
==Monads are not about strictness==<br />
There are monads that are strict (like IO), and monads that 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 in a category of endofunctors. It's all very 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.</div>Sigfpehttps://wiki.haskell.org/index.php?title=Haskell_Cafe_migration&diff=14422Haskell Cafe migration2007-07-16T17:12:43Z<p>Sigfpe: </p>
<hr />
<div>Often people post wonderful material to the mailing lists, hpaste.org or<br />
on #haskell. This can later be hard to find. The goal of this page is to<br />
collect a list of people who are happy for their contributions to the<br />
Haskell community, in any media, to be added directly to the Haskell wiki.<br />
<br />
If you are happy for your contributions (both new and old posts) on <br />
''any media that are part of the Haskell community'', including:<br />
<br />
* [[Mailing_lists|The mailing lists]] (haskell-cafe@, libraries@ and others)<br />
* [[IRC_channel|The IRC channel]]<br />
* [http://hpaste.org/ The Haskell Paste Bin]: hpaste.org<br />
* [[HaWiki_migration|The Old Haskell Wiki]]<br />
* And the new wiki.<br />
<br />
that ''are not specifically licensed'' to be treated as having been<br />
released under a [[HaskellWiki:Copyrights|Simple Permissive License]].<br />
please add your name to this list, so that others may move your<br />
contributions around haskell.org without fear.<br />
<br />
''Contributions will be licensed specifically under a<br />
[[HaskellWiki:Copyrights|Simple Permissive License]]''.<br />
<br />
* Andrew Bromage (aka Pseudonym)<br />
* Arthur van Leeuwen (aka earthy)<br />
* Bernie Pope<br />
* Brandon Allbery<br />
* [[User:BrettGiles | Brett Giles]]<br />
* Bulat Ziganshin<br />
* Cale Gibbard<br />
* Chris Smith (cdsmith; blog also fair game)<br />
* Conor McBride<br />
* Conrad Parker<br />
* Dan Doel<br />
* Dan Piponi (aka sigfpe)<br />
* Derek Elkins<br />
* Dominic Steinitz<br />
* Don Stewart<br />
* Eric Kow (kowey; blog too)<br />
* Henk-Jan van Tuyl<br />
* Ian Lynagh (Igloo)<br />
* Jonathan Cast<br />
* Neil Mitchell (ndm)<br />
* Richard Kelsall<br />
* Richard O'Keefe<br />
* Samuel Bronson (SamB)<br />
* Stefan O'Rear<br />
* Thorkil Naur<br />
* Tim Chevalier (aka Kirsten)<br />
* Tom Conway<br />
<br />
[[Category:Community]]</div>Sigfpe