StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
17412402
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
1
CommunityOwnedDate
CreationDate
2013-07-01T19:42:34.717
FavoriteCount
0
LastActivityDate
2013-07-01T19:42:34.717
LastEditDate
2017-05-23T12:26:35.830
LastEditorUserId
-1
OwnerUserId
237428
ParentId
17409260
PostTypeId
2
Score
21
ViewCount
0
LastEditorDisplayName
text
Body
<a href="https://stackoverflow.com/questions/17409260/what-advantage-does-monad-give-us-over-an-applicative#comment25280636_17409260">As Stephen Tetley said in a comment</a>, that example doesn't actually use context-sensitivity. One way to think about context-sensitivity is that it lets use choose which actions to take depending on monadic values. Applicative computations must always have the same "shape", in a certain sense, regardless of the values involved; monadic computations need not. I personally think this is easier to understand with a concrete example, so let's look at one. Here's two versions of a simple program which ask you to enter a password, check that you entered the right one, and print out a response depending on whether or not you did. <pre><code>import Control.Applicative checkPasswordM :: IO () checkPasswordM = do putStrLn "What's the password?" pass <- getLine if pass == "swordfish" then putStrLn "Correct. The secret answer is 42." else putStrLn "INTRUDER ALERT! INTRUDER ALERT!" checkPasswordA :: IO () checkPasswordA = if' . (== "swordfish") <$> (putStrLn "What's the password?" *> getLine) <*> putStrLn "Correct. The secret answer is 42." <*> putStrLn "INTRUDER ALERT! INTRUDER ALERT!" if' :: Bool -> a -> a -> a if' True t _ = t if' False _ f = f </code></pre> Let's load this into GHCi and check what happens with the monadic version: <pre><code>*Main> checkPasswordM What's the password? swordfish Correct. The secret answer is 42. *Main> checkPasswordM What's the password? zvbxrpl INTRUDER ALERT! INTRUDER ALERT! </code></pre> So far, so good. But if we use the applicative version: <pre><code>*Main> checkPasswordA What's the password? hunter2 Correct. The secret answer is 42. INTRUDER ALERT! INTRUDER ALERT! </code></pre> We entered the wrong password, but we still got the secret! And an intruder alert! This is because <code><$></code> and <code><*></code>, or equivalently <code>liftAn</code>/<code>liftMn</code>, always execute the effects of all their arguments. The applicative version translates, in <code>do</code> notation, to <pre><code>do pass <- putStrLn "What's the password?" *> getLine) unit1 <- putStrLn "Correct. The secret answer is 42." unit2 <- putStrLn "INTRUDER ALERT! INTRUDER ALERT!" pure $ if' (pass == "swordfish") unit1 unit2 </code></pre> And it should be clear why this has the wrong behavior. In fact, every use of applicative functors is equivalent to monadic code of the form <pre><code>do val1 <- app1 val2 <- app2 ... valN <- appN pure $ f val1 val2 ... valN </code></pre> (where some of the <code>appI</code> are allowed to be of the form <code>pure xI</code>). And equivalently, any monadic code in that form can be rewritten as <pre><code>f <$> app1 <*> app2 <*> ... <*> appN </code></pre> or equivalently as <pre><code>liftAN f app1 app2 ... appN </code></pre> To think about this, consider <code>Applicative</code>'s methods: <pre><code>pure :: a -> f a (<$>) :: (a -> b) -> f a -> f b (<*>) :: f (a -> b) -> f a -> f b </code></pre> And then consider what <code>Monad</code> adds: <pre><code>(=<<) :: (a -> m b) -> m a -> m b join :: m (m a) -> m a </code></pre> (Remember that you only need one of those.) Handwaving a lot, if you think about it, the only way we can put together the applicative functions is to construct chains of the form <code>f <$> app1 <*> ... <*> appN</code>, and possibly nest those chains (e.g., <code>f <$> (g <$> x <*> y) <*> z</code>). However, <code>(=<<)</code> (or <code>(>>=)</code>) allows us to take a value and produce different monadic computations depending on that value, that could be constructed on the fly. This is what we use to decide whether to compute "print out the secret", or compute "print out an intruder alert", and why we can't make that decision with applicative functors alone; none of the types for applicative functions allow you to consume a plain value. You can think about <code>join</code> in concert with <code>fmap</code> in a similar way: <a href="https://stackoverflow.com/questions/17409260/what-advantage-does-monad-give-us-over-an-applicative#comment25285244_17409567">as I mentioned in a comment</a>, you can do something like <pre><code>checkPasswordFn :: String -> IO () checkPasswordFn pass = if pass == "swordfish" then putStrLn "Correct. The secret answer is 42." else putStrLn "INTRUDER ALERT! INTRUDER ALERT!" checkPasswordA' :: IO (IO ()) checkPasswordA' = checkPasswordFn <$> (putStrLn "What's the password?" *> getLine) </code></pre> This is what happens when we want to pick a different computation depending on the value, but only have applicative functionality available us. We can pick two different computations to return, but they're wrapped inside the outer layer of the applicative functor. To actually use the computation we've picked, we need <code>join</code>: <pre><code>checkPasswordM' :: IO () checkPasswordM' = join checkPasswordA' </code></pre> And this does the same thing as the previous monadic version (as long as we <code>import Control.Monad</code> first, to get <code>join</code>): <pre><code>*Main> checkPasswordM' What's the password? 12345 INTRUDER ALERT! INTRUDER ALERT! </code></pre>
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POWhat advantage does Monad give us over an Applicative?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USCommunity
UserOwnerUserId
1. USAntal Spector-Zabusky
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. COWhat a pity that i can't accept more than one answer!
 singulars
 PostPostId
 PO
 UserUserId
 USarrowd

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.