[Haskell-cafe] A question about State Monad and Monad in general
C K Kashyap
ckkashyap at gmail.com
Thu Jul 15 13:34:59 EDT 2010
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:
>> 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
> 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
> 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.
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe