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 <leim...@gmail.com> wrote: > > > On Thu, Jul 15, 2010 at 9:02 AM, C K Kashyap <ckkash...@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@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > -- Regards, Kashyap
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe