[Haskell-cafe] A question about State Monad and Monad in general

[David Leimbach]

On Thu, Jul 15, 2010 at 10:34 AM, C K Kashyap <ckkashyap at gmail.com> wrote:

> Thanks David for the detailed explanation.
>
> A couple of quick clarifications -
>
> 1. Even the "invisible" state that gets modified during the monadic
> evaluation is referred to as side effect right?
>

If the state is free of types that allow for side effects then the state
threaded through a state monad is also free from side effects.  If the state
contains some IO type, which allows for side effects, for example, that
state is affected by outside influences and is no longer pure.

Non-monadic example:

foo :: Int
foo = let state1  = 1
             state2 = state1 + 3
             state3 = state2 + state1
         in state3 + 9

Each of those states are really just labels on a stage of computation that's
been done so far up to a final expression which is the result of the
function foo being called.   In the end, this function is just a fancy way
of saying 14 is an Int and foo could have been replaced with a let foo=14 in
some other expression.

This is a pure function with what looks like states updating a value to
produce a new state.  That's more akin to what happen in the state monad.
 At no time is a previous state truly "overwritten" as that could be
considered a side effect.

Here's a state monad like example of the same:

foo :: Int
foo = (flip execState) 1 $ do {
          state1 <- get;
          modify (+3);
          state2 <- get;
          put (state2 + state1);
          modify (+9)
        }


> 2. I am a little unclear about "in-place" - does pure Haskell let one do
> such a thing-  or does it need to be done using FFI only?
>
>
Pure haskell does not allow for in place update of values because that would
violate the definition of purity.  That said, there are ways to update
values in place with Haskell, ideally with Monads to control and sequence
those side effects.

Example here:
http://www.haskell.org/haskellwiki/Monad/ST

The ST monad allows one to describe a thread of computation which can update
some mutable state and then exchange it with the "pure world" of normal
Haskell computation.

Dave

>
>
> On Thu, Jul 15, 2010 at 10:48 PM, David Leimbach <leimy2k at gmail.com>wrote:
>
>>
>>
>> On Thu, Jul 15, 2010 at 9:02 AM, C K Kashyap <ckkashyap at gmail.com> wrote:
>>
>>> Hi,
>>> I looked at State Monad yesterday and this question popped into my mind.
>>> From what I gather State Monad essentially allows the use of Haskell's do
>>> notation to "invisibly" pass around a state. So, does the use of Monadic
>>> style fetch us more than syntactic convenience?
>>> Again, if I understand correctly, in Mutable Arrays also, is anything
>>> getting modified in place really? If not, what is the real reason for better
>>> efficiency?
>>>
>>
>> Syntactic convenience is important, and allows for the separation of logic
>> into different modular pieces.  The do notation is totally independent of
>> the Monad in question's behavior.  You can even roll your own Monad if you
>> wish, and the do notation will work.  Consider if you had a big data
>> structure that you had to pass around all the different versions of in a
>> series of functions.   Then consider what happens when you decide that some
>> of your data has to change later as your program evolves over time.  Having
>> to change the state that's being threaded around is quite a pain when it can
>> be done transparently at the Monad definition level.
>>
>> Monads let you define the stuff that's going on between statements of do
>> syntax.  Some say it's the equivalent of overriding a fictional ";" operator
>> for sequencing imperative looking code statements.  There's much power to be
>> had here, and because of this analogy, it's easy to see why Monads are a
>> good place to implement an embedded specific sublanguage in Haskell.
>>
>> I also think that because you're writing the glue between statements when
>> you implement a Monad that it could be why some people (myself included)
>> sometimes have a difficult time thinking of how to implement a particular
>> Monad.
>>
>> Monads also allow you to package up pure data values with some
>> computational activities that might have side effects and logically separate
>> them.  This allows one to unwrap a value from a monadic environment and pass
>> it to pure functions for computation, then re-inject it back into the
>> monadic environment.
>>
>> Monads are a good place to store side-effectful code, because they allow
>> you to get away with causing a side effect and using some of those unwrapped
>> monadic values in your pure code.  They are an interface between two worlds
>> in this respect.  Monads are a good place, therefore, to implement code that
>> does do in-place updates of values because they help the functional
>> programmer deal with the issues of sequencing as well as interfacing
>> side-effect-having and pure code and how to express dependencies between
>> these two worlds.
>>
>> Dave
>>
>>
>>> --
>>> Regards,
>>> Kashyap
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>
>>>
>>
>
>
> --
> Regards,
> Kashyap
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100715/61657f67/attachment.html