On Jul 26, 3:00 pm, Vo Minh Thu wrote:

Also, just like with IO, maybe restructuring the code to separate monadic code would help.

The specific monad I am dealing with carries state around inside it. I could revert to a pure system in many cases by simply passing the state as a parameter but then that defeats the point of the monad and clutters up my function calls. Also, in other cases, I am using a module that defines its own monads and have no choice but to use them. I think I would prefer a style of programming where monads are equal citizens to pure function calls. There are various hints that such a style of programming is possible but as I say, I have not found any clear tutorials on it.

On Jul 26, 3:19 pm, Vo Minh Thu wrote:

Maybe you missed the part of my answer hinting to applicative style?

No, I saw that but as I mentioned, I am looking for a tutorial. The source code alone means little to me.

LYAH has a chapter about it[0].

Thanks for the pointer. I have read LYAH before (perhaps an earlier version) and did not notice that chapter. I'll take a look at it. Kevin

On Jul 26, 3:26 pm, Bill Atkins wrote:

Can you post an example of your code?

Without getting into the complexities, one simple example is a fold where the step function returns results in a monad. I have taken to replacing the fold in that case with a recursive function, which surely is the wrong approach. I think foldM might do the job but am unsure. But as I said, that is just an example. I keep wanting to apply the usual list tools but find that they do not work inside a monad. I find myself wishing that f (m [a]) just automatically returned m f([a]) without me needing to do anything but I expect that there are reasons why that is not a good idea. Kevin

The answer is still applicative. :) On Monday Jul 26, 2010, at 10:06 AM, Kevin Jardine wrote:

On Jul 26, 3:49 pm, Kevin Jardine wrote:

...

I find myself wishing that f (m [a]) just automatically returned m f([a]) without me needing to do anything but I expect that there are reasons why that is not a good idea.

Or is there a monadic list module where f(m [a]) = m f ([a]) ?

It occurs to me that Haskell provides the tools to construct such a module (I think) so probably one exists?

Kevin _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Kevin Jardine wrote:

But as I said, that is just an example. I keep wanting to apply the usual list tools but find that they do not work inside a monad. I find myself wishing that f (m [a]) just automatically returned m f([a])

Are you looking for these? import Data.Traversable as T T.sequence :: (T.Traversable t, Monad m) => t (m a) -> m (t a) T.mapM :: (T.Traversable t, Monad m) => (a -> m b) -> t a -> m (t b) -- N.B. T.mapM ~ (T.sequence . fmap)

without me needing to do anything but I expect that there are reasons why that is not a good idea.

Not all functors can be distributed over arbitrary monads, so "not a good idea" is more like "not always possible" or "here be dragons" (fluffy, intriguing, and pretty dragons to be sure; but probably deeper than the answer you were looking for). In addition to Applicative, the Traversable and Foldable classes should be key tools in your toolbox. They take a number of functions typically restricted to lists and generalize them to different functors, often with Applicatives or Monads involved. The Typeclassopedia should have more on them. -- Live well, ~wren

On 07/26/2010 08:13 AM, Kevin Jardine wrote:

On Jul 26, 3:00 pm, Vo Minh Thu wrote:

...

Also, just like with IO, maybe restructuring the code to separate monadic code would help.

The specific monad I am dealing with carries state around inside it.

I could revert to a pure system in many cases by simply passing the state as a parameter but then that defeats the point of the monad and clutters up my function calls.

Also, in other cases, I am using a module that defines its own monads and have no choice but to use them.

I think I would prefer a style of programming where monads are equal citizens to pure function calls. There are various hints that such a style of programming is possible but as I say, I have not found any clear tutorials on it.

It's not much of a tutorial, but Software Tools in Haskell[1][2] apparently uses monads more than some people are comfortable with, including stacks of monad transformers in the later chapters. [1] http://www.crsr.net/Programming_Languages/SoftwareTools/index.html [2] Heck, the later chapters are only marginally readable. -- Tommy M. McGuire mcguire@crsr.net