Re: [Haskell-cafe] couple of questions on monads
On Mon, 2008-10-13 at 13:37 -0700, Daryoush Mehrtash wrote: Question 1: Why are there lazy and strict modules of some monads? (e.g. Control.Monad.State) Because both are useful, for different purposes. (For the same reason that it's helpful, in general, to have both eager and lazy evaluation in the same language --- sometimes one version is more efficient, sometimes the other one is). Question 2: If I define a new monad (say XYZ), does it have to be as Control.Monad.XYZ module? No. Haskell has neither a requirement nor a convention that monads go in Control.Monad. Control.Monad.* is simply the home of the MTL library, which contains a number of exceptionally useful monads; new monads that aren't as exceptionally general-purpose as MTL probably shouldn't go there, to reduce clutter. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] couple of questions on monads
Is there a write up on what makes an implementation lazy vs strict? I like to better understand the trade off between the two and use cases where one is better than the other. I noticed that some functions in the lazy implementation uses ~ .For example evalStateT :: (Monad m) = StateT s m a - s - m a evalStateT m s = do ~(a, _) - runStateT m s return a What does ~ do? thanks, Daryoush On Mon, Oct 13, 2008 at 1:34 PM, Jonathan Cast [EMAIL PROTECTED]wrote: On Mon, 2008-10-13 at 13:37 -0700, Daryoush Mehrtash wrote: Question 1: Why are there lazy and strict modules of some monads? (e.g. Control.Monad.State) Because both are useful, for different purposes. (For the same reason that it's helpful, in general, to have both eager and lazy evaluation in the same language --- sometimes one version is more efficient, sometimes the other one is). Question 2: If I define a new monad (say XYZ), does it have to be as Control.Monad.XYZ module? No. Haskell has neither a requirement nor a convention that monads go in Control.Monad. Control.Monad.* is simply the home of the MTL library, which contains a number of exceptionally useful monads; new monads that aren't as exceptionally general-purpose as MTL probably shouldn't go there, to reduce clutter. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] couple of questions on monads
2008/10/13 Daryoush Mehrtash [EMAIL PROTECTED]: Is there a write up on what makes an implementation lazy vs strict? I would be interested in seeing this, too! I like to better understand the trade off between the two and use cases where one is better than the other. I noticed that some functions in the lazy implementation uses ~ .For example evalStateT :: (Monad m) = StateT s m a - s - m a evalStateT m s = do ~(a, _) - runStateT m s return a What does ~ do? Here's one I can answer. ~ causes Haskell to do the pattern match lazily. Normally, when you write (a,_) - runStateT m s it eagerly evaluates the runStateT m s far enough to determine that the result is in fact a tuple in the underlying monad (as opposed to, say, fail). Adding the ~ tells Haskell to not do any computation until it actually needs the value of a. You can find a better explanation and examples at http://en.wikibooks.org/wiki/Haskell/Laziness Cheers, steve ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] couple of questions on monads
Hello, On Mon, Oct 13, 2008 at 3:16 PM, Stephen Hicks [EMAIL PROTECTED] wrote: 2008/10/13 Daryoush Mehrtash [EMAIL PROTECTED]: Is there a write up on what makes an implementation lazy vs strict? I would be interested in seeing this, too! Typically it has to do with the strictness of the bind operation. Here is an example to illustrate the difference. evalState (undefined return True) undefined When you evaluate this in the context of Control.Monad.State, the result is True, while if you evaluate it in the context of Control.Monad.State.Strict you will get undefined. It may be interesting to compare MTL's approach to what's done in monadLib (another monad transformer library). In monadLib, transformers like state inherit the strictness of their bind operation from the underlying monad. There are two base level monads: Id, which is lazy, and Lift which is strict. So to get a strict state monad in monadLIb, you would write StateT s Lift, and to get the lazy version you would use StateT s Id. Hope that this helps, Iavor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
