StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
7884975
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
3
CommunityOwnedDate
CreationDate
2011-10-25T05:15:17.667
FavoriteCount
0
LastActivityDate
2011-10-25T05:15:17.667
LastEditDate
LastEditorUserId
0
OwnerUserId
1011414
ParentId
7840126
PostTypeId
2
Score
29
ViewCount
0
LastEditorDisplayName
text
Body
<blockquote> The point is so there can be clean error handling in a chain of functions, containers, and side effects. Is this a correct interpretation? </blockquote> Not really. You've mentioned a lot of concepts that people cite when trying to explain monads, including side effects, error handling and non-determinism, but it sounds like you've gotten the incorrect sense that all of these concepts apply to all monads. But there's one concept you mentioned that does: chaining. There are two different flavors of this, so I'll explain it two different ways: one without side effects, and one with side effects. <h1>No Side Effects:</h1> Take the following example: <pre><code>addM :: (Monad m, Num a) => m a -> m a -> m a addM ma mb = do a <- ma b <- mb return (a + b) </code></pre> This function adds two numbers, with the twist that they are wrapped in some monad. Which monad? Doesn't matter! In all cases, that special <code>do</code> syntax de-sugars to the following: <pre><code>addM ma mb = ma >>= \a -> mb >>= \b -> return (a + b) </code></pre> ... or, with operator precedence made explicit: <pre><code>ma >>= (\a -> mb >>= (\b -> return (a + b))) </code></pre> Now you can really see that this is a chain of little functions, all composed together, and its behavior will depend on how <code>>>=</code> and <code>return</code> are defined for each monad. If you're familiar with polymorphism in object-oriented languages, this is essentially the same thing: one common interface with multiple implementations. It's slightly more mind-bending than your average OOP interface, since the interface represents a computation policy rather than, say, an animal or a shape or something. Okay, let's see some examples of how <code>addM</code> behaves across different monads. The <code>Identity</code> monad is a decent place to start, since its definition is trivial: <pre><code>instance Monad Identity where return a = Identity a -- create an Identity value (Identity a) >>= f = f a -- apply f to a </code></pre> So what happens when we say: <pre><code>addM (Identity 1) (Identity 2) </code></pre> Expanding this, step by step: <pre><code>(Identity 1) >>= (\a -> (Identity 2) >>= (\b -> return (a + b))) (\a -> (Identity 2) >>= (\b -> return (a + b)) 1 (Identity 2) >>= (\b -> return (1 + b)) (\b -> return (1 + b)) 2 return (1 + 2) Identity 3 </code></pre> Great. Now, since you mentioned clean error handling, let's look at the <code>Maybe</code> monad. Its definition is only slightly trickier than <code>Identity</code>: <pre><code>instance Monad Maybe where return a = Just a -- same as Identity monad! (Just a) >>= f = f a -- same as Identity monad again! Nothing >>= _ = Nothing -- the only real difference from Identity </code></pre> So you can imagine that if we say <code>addM (Just 1) (Just 2)</code> we'll get <code>Just 3</code>. But for grins, let's expand <code>addM Nothing (Just 1)</code> instead: <pre><code>Nothing >>= (\a -> (Just 1) >>= (\b -> return (a + b))) Nothing </code></pre> Or the other way around, <code>addM (Just 1) Nothing</code>: <pre><code>(Just 1) >>= (\a -> Nothing >>= (\b -> return (a + b))) (\a -> Nothing >>= (\b -> return (a + b)) 1 Nothing >>= (\b -> return (1 + b)) Nothing </code></pre> So the <code>Maybe</code> monad's definition of <code>>>=</code> was tweaked to account for failure. When a function is applied to a <code>Maybe</code> value using <code>>>=</code>, you get what you'd expect. Okay, so you mentioned non-determinism. Yes, the list monad can be thought of as modeling non-determinism in a sense... It's a little weird, but think of the list as representing alternative possible values: <code>[1, 2, 3]</code> is not a collection, it's a single non-deterministic number that could be either one, two or three. That sounds dumb, but it starts to make some sense when you think about how <code>>>=</code> is defined for lists: it applies the given function to each possible value. So <code>addM [1, 2] [3, 4]</code> is actually going to compute all possible sums of those two non-deterministic values: <code>[4, 5, 5, 6]</code>. Okay, now to address your second question... <h1>Side Effects:</h1> Let's say you apply <code>addM</code> to two values in the <code>IO</code> monad, like: <pre><code>addM (return 1 :: IO Int) (return 2 :: IO Int) </code></pre> You don't get anything special, just 3 in the <code>IO</code> monad. <code>addM</code> does not read or write any mutable state, so it's kind of no fun. Same goes for the <code>State</code> or <code>ST</code> monads. No fun. So let's use a different function: <pre><code>fireTheMissiles :: IO Int -- returns the number of casualties </code></pre> Clearly the world will be different each time missiles are fired. Clearly. Now let's say you're trying to write some totally innocuous, side effect free, non-missile-firing code. Perhaps you're trying once again to add two numbers, but this time without any monads flying around: <pre><code>add :: Num a => a -> a -> a add a b = a + b </code></pre> and all of a sudden your hand slips, and you accidentally typo: <pre><code>add a b = a + b + fireTheMissiles </code></pre> An honest mistake, really. The keys were so close together. Fortunately, because <code>fireTheMissiles</code> was of type <code>IO Int</code> rather than simply <code>Int</code>, the compiler is able to avert disaster. Okay, totally contrived example, but the point is that in the case of <code>IO</code>, <code>ST</code> and friends, the type system keeps effects isolated to some specific context. It doesn't magically eliminate side effects, making code referentially transparent that shouldn't be, but it does make it clear at compile time what scope the effects are limited to. So getting back to the original point: what does this have to do with chaining or composition of functions? Well, in this case, it's just a handy way of expressing a sequence of effects: <pre><code>fireTheMissilesTwice :: IO () fireTheMissilesTwice = do a <- fireTheMissiles print a b <- fireTheMissiles print b </code></pre> <h1>Summary:</h1> A monad represents some policy for chaining computations. <code>Identity</code>'s policy is pure function composition, <code>Maybe</code>'s policy is function composition with failure propogation, <code>IO</code>'s policy is impure function composition and so on.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POWhy monads? How does it resolve side-effects?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USmergeconflict
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. CO+1 Because of fireTheMissiles :).
 singulars
 PostPostId
 PO
 UserUserId
 USkeep_learning

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.