Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt

On Sat, 2009-01-17 at 10:47 +0100, david48 wrote:

On Fri, Jan 16, 2009 at 4:04 PM, Jonathan Cast wrote:

...

On Fri, 2009-01-16 at 14:16 +0100, david48 wrote:

...

Part of the problem is that something like a monoid is so general that I can't wrap my head around why going so far in the abstraction. For example, the writer monad works with a monoid; using the writer monad with strings makes sense because the mappend operation for lists is (++), now why should I care that I can use the writer monad with numbers which it will sum ?

To accumulate a running count, maybe? A fairly common pattern for counting in imperative languages is

int i = 0; while (<get a value>) i+= <count of something in value>

Using the writer monad, this turns into

execWriter $ mapM_ (write . countFunction) $ getValues

well thank you for the example, if I may ask something: why would I need to write a running count this way instead of, for example, a non monadic fold, which would probably result in clearer and faster code (IMHO) ?

I agree with you, for this special case. (Did I remember to post the simpler solution: sum $ map countFunction $ getValues somewhere in this thread?) But, just like the (utterly useless) C++ example translated to Haskell in another thread, the monadic form provides a framework you can fill out with larger code fragments. So if the while loop above was replaced with a larger control structure, maybe recursion over a custom tree type, then standard recusion operators, such as folds, may be inapplicable. In that case, moving to a Writer monad can get you some of the advantage back, so you don't end up passing your accumulator around everywhere by hand. jcc