headers
Daryoush Mehrtash | 13 Oct 22:35

couple of questions on monads

Question 1: Why are there lazy and strict modules of some monads?  (e.g. Control.monad.State)  

Question 2:  If I define a new monad (say xyz), does it have to be as  control.monad.xyz  module?

daryoush


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Permalink | Reply |
headers
Jonathan Cast | 13 Oct 22:34
Favicon

Re: 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
Permalink | Reply |
headers
Daryoush Mehrtash | 13 Oct 23:31

Re: 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 <jonathanccast <at> fastmail.fm> 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 <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Permalink | Reply |
headers
Stephen Hicks | 14 Oct 00:16
Favicon

Re: couple of questions on monads

2008/10/13 Daryoush Mehrtash <dmehrtash <at> gmail.com>:
> 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
Permalink | Reply |
headers
Iavor Diatchki | 14 Oct 01:02

Re: couple of questions on monads

Hello,

On Mon, Oct 13, 2008 at 3:16 PM, Stephen Hicks <sdh33 <at> cornell.edu> wrote:
> 2008/10/13 Daryoush Mehrtash <dmehrtash <at> gmail.com>:
>> 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
Permalink | Reply |

Gmane