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

[C K Kashyap]

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?

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?


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/82d2f943/attachment.html