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

[David Leimbach]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100715/8bf9cbee/attachment.html