Send Beginners mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.haskell.org/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: Trying to grasp Monads - IO and delayed actions (Gesh)
2. Re: Trying to grasp Monads - IO and delayed actions
(John M. Dlugosz)
----------------------------------------------------------------------
Message: 1
Date: Sun, 06 Apr 2014 12:47:54 +0300
From: Gesh <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] Trying to grasp Monads - IO and
delayed actions
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
On April 6, 2014 10:41:41 AM GMT+03:00, "John M. Dlugosz"
<[email protected]> wrote:
>A spiral approach to learning: you understand, then you learn more, and
>then you are more
>confused than ever.
>
Excellent characterization of learning. Mind if I use it?
>I recall that a function in the IO Monad just combines actions to make
>a big action list,
>and doesn't actually do the side-effect-laden "work" until it is later
>triggered, normally
>because the program is defined to evaluate main.
>
>Depending on the time of day and which example I pick, I can sometimes
>follow what's
>"really happening" in the definition of >>=. But here are some
>specific questions:
>
>In <http://www.haskell.org/haskellwiki/Monads_as_computation>
>
>> What is a for-each loop really? It's something which performs some
>action based on each
>> element of a list. So we might imagine a function with the type:
>>
>> forM :: (Monad m) => [a] -> (a -> m b) -> m [b]
>>
>> (as an added bonus, we'll have it collect the results of each
>iteration).
>>
>> We can write this with sequence and map:
>>
>> forM xs f = sequence (map f xs)
>>
>> we apply the function to each element of the list to construct the
>action for that
>> iteration, and then sequence the actions together into a single
>computation.
>>
>
>So map by itself produces a [m b]. Why does it need to be turned into
>m [b]? What does
>the 'sequence' accomplish, other than restructuring the results that
>already exist?
>
In essence, what a value of type Monad m => [m a] means is that you have a list
full of monadic actions. It's a bit like having a list of functions - while you
can certainly use the actions and functions, respectively, they haven't been
evaluated *yet*. Whereas a value of type Monad m => m [a] represents a monadic
action returning some list of values. Thus, sequence is collecting the values
computed by each action. This is all made clear by the implementation of
sequence:
sequence ms = foldr k (return []) ms
where k m m' = do { x <- m; xs <- m'; return (x:xs) }
Note that lists aren't special, Data.Traversable defines sequence for all
traversable values:
sequence = unwrapMonad . traverse . WrapMonad
>The reason I asked about (#?#) is because I wanted to see what IO was
>really doing, to see
>what the difference was between using >>= initially and then somehow
>"cranking" it later.
>
><http://hackage.haskell.org/package/base-4.6.0.1/docs/src/GHC-Base.html#%3E%3E%3D>
>lists
>> instance Monad IO where
>> {-# INLINE return #-}
>> {-# INLINE (>>) #-}
>> {-# INLINE (>>=) #-}
>> m >> k = m >>= \ _ -> k
>> return = returnIO
>> (>>=) = bindIO
>> fail s = failIO s
>>
>> returnIO :: a -> IO a
>> returnIO x = IO $ \ s -> (# s, x #)
>>
>> bindIO :: IO a -> (a -> IO b) -> IO b
>> bindIO (IO m) k = IO $ \ s -> case m s of (# new_s, a #) -> unIO (k
>a) new_s
>>
>> thenIO :: IO a -> IO b -> IO b
>> thenIO (IO m) k = IO $ \ s -> case m s of (# new_s, _ #) -> unIO k
>new_s
>>
>> unIO :: IO a -> (State# RealWorld -> (# State# RealWorld, a #))
>> unIO (IO a) = a
>
>where bindIO is the function of interest. In a chain of commands,
>getLine might be the
>'k' argument to bindIO. Somewhere there's a real machine function
>called to do the
>reading from the file, right?
Yes. I don't know enough about GHC's implementation of the Prelude, but
basically, what's going on here is that IO works a bit like State, except it
uses unboxed tuples and doesn't have an evalState function. getLine and its ilk
are all probably defined using primitive operations. That basically sums up my
knowledge of how IO works.
Hoping to help,
Gesh
------------------------------
Message: 2
Date: Sun, 06 Apr 2014 05:04:23 -0500
From: "John M. Dlugosz" <[email protected]>
To: [email protected]
Subject: Re: [Haskell-beginners] Trying to grasp Monads - IO and
delayed actions
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 4/6/2014 4:47 AM, Gesh wrote:
> On April 6, 2014 10:41:41 AM GMT+03:00, "John M. Dlugosz"
> <[email protected]> wrote:
>> A spiral approach to learning: you understand, then you learn more, and
>> then you are more
>> confused than ever.
>>
> Excellent characterization of learning. Mind if I use it?
By my guest. See <http://www.dlugosz.com/zeta/?p=241>
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 70, Issue 13
*****************************************
