John Meacham wrote:
> incidentally, I made a very strict and unboxed version of the RWS monad,
> since it is a darn useful one in jhc. right now, it only implements the
> things I needed, but it might be useful to include somewhere common and
> expanded on
>
> http://repetae.net/dw/darcsweb.cgi?r=
incidentally, I made a very strict and unboxed version of the RWS monad,
since it is a darn useful one in jhc. right now, it only implements the
things I needed, but it might be useful to include somewhere common and
expanded on
http://repetae.net/dw/darcsweb.cgi?r=jhc;a=headblob;f=/Util/RWS.hs
On 1/11/07, Yitzchak Gale <[EMAIL PROTECTED]> wrote:
Josef Svenningsson wrote:
>>> Take the state monad for example. Should it be
>>> strict or lazy in the state that it carries
>>> around? What about the value component?
>>> ...both strict and lazy variants are useful.
I wrote:
>> Are those rea
Ross Paterson wrote:
> This (like StateT) gives you strictness in the pair, but doesn't give
> the strictness in the state that the original poster wanted.
I think the OP wanted both. If State is lazy in the pair, a long chain
of the form (a >>= (b >>= (c >>= ... >>= z))) gets build up and blows
Yitzchak Gale wrote:
> You're right, it is not in the docs. I don't think anyone would
> have planned it that way. StateT is strict only because there
> happens to be a line in a do-expression that looks like:
> (a, s') <- runStateT m s
> The tuple pattern-match causes the strictness.
Josef Svenningsson wrote:
Take the state monad for example. Should it be
strict or lazy in the state that it carries
around? What about the value component?
...both strict and lazy variants are useful.
I wrote:
Are those really needed?
...it wouldn't be very convenient, would it?
Sometimes
Iavor Diatchki wrote:
The state transformer inherits its behavior from
the underlying monad.
Ross Paterson wrote:
This (like StateT) gives you strictness in the pair, but doesn't give
the strictness in the state that the original poster wanted.
I think it does - if you run his program with S
Hello,
On 1/10/07, Ross Paterson <[EMAIL PROTECTED]> wrote:
> There is no such distinction in monadLib. The state transformer
> inherits its behavior from the underlying monad. For example: StateT
> Int IO is strict, but StatT Int Id is lazy. One way to get a strict
> state monad with monadLi
haskell is the standard lazy functional language, so strictness ought
to be called out. e.g. StateStrict rather than StateLazy.
The traction that haskell is starting to get (and why I'm spending
time learning it and following haskell-cafe) is not because its
semantics are unsurprising to newbies.
On Wed, Jan 10, 2007 at 10:02:36AM -0800, Iavor Diatchki wrote:
> [Yitzchak Gale:]
> >Unfortunately, the current situation is that State is only
> >available as a lazy monad, and StateT is only available
> >as a strict monad.
>
> There is no such distinction in monadLib. The state transformer
> i
...how would one know that State is lazy and StateT is strict?
I don't see that in the Haddock documentation.
You're right, it is not in the docs. I don't think anyone would
have planned it that way. StateT is strict only because there
happens to be a line in a do-expression that looks like:
hi,
I'm drooling. When can we get stuff like this into MTL?
And maybe it is finally time for me to bite the bullet and
try out monadLib again (is it still CPS? gulp).
version 3 (the current version) implements the transformers in the
usual way (e.g., as in mtl) so no cps (except, of course, fo
Dean Herington wrote:
> Third, isn't it a continuum rather than a binary choice between lazy and
> strict? In my example, I used ($!) in the definition of (>>=), but
> that's just one flavor of strictness that was appropriate to my
> example. Is there some way to parameterize this degree of stri
At 11:02 AM +0200 1/10/07, Yitzchak Gale wrote:
Unfortunately, the current situation is that State is only
available as a lazy monad, and StateT is only available
as a strict monad.
[...]
The obvious solution would be to have available
both a lazy and a strict version of each monad: State,
S
Wow! Now we are talking!
Josef Svenningsson wrote:
So instead of:
newtype State s a = State { runState :: (s -> (a, s)) }
we have:
newtype StateP p s a = StateP { runStateP :: (s -> p a s) }
Now, instantiating this with different pair types with different
strictness properties will give us total
Hello,
Unfortunately, the current situation is that State is only
available as a lazy monad, and StateT is only available
as a strict monad.
There is no such distinction in monadLib. The state transformer
inherits its behavior from the underlying monad. For example: StateT
Int IO is strict, b
On 1/10/07, Yitzchak Gale <[EMAIL PROTECTED]> wrote:
Hi Josef,
Josef Svenningsson wrote:
> ...the fun doesn't end there. There are other strictness properties
> to consider.
Could be. But after using mtl heavily for a few years now,
I find that in practice the only one where have felt the need
Hi Josef,
Josef Svenningsson wrote:
...the fun doesn't end there. There are other strictness properties
to consider.
Could be. But after using mtl heavily for a few years now,
I find that in practice the only one where have felt the need
for control over strictness is >>=, like Dean's example.
Yitzchak,
I agree with you that both lazy and strict monads are important and
that we should have both options in a monad library.
But the fun doesn't end there. There are other strictness properties
to consider. Take the state monad for example. Should it be strict or
lazy in the state that it
Hi Bulat,
I wrote:
[State and StateT] should be consistent. I
would much prefer for them both to be lazy.
Bulat Ziganshin wrote:
imho, lazy monads (as any other lazy things) is a source of beginner's
confusion. therefore it may be better to provide "default" monads as strict
and lazy ones - f
Hello Yitzchak,
Wednesday, January 10, 2007, 12:02:25 PM, you wrote:
> Unfortunately, the current situation is that State is only
> available as a lazy monad, and StateT is only available
> as a strict monad.
> At the very least, the two should be consistent. I
> would much prefer for them both
Dean Herington wrote:
I can't seem to figure out how to achieve strictness
in the context of the State monad.
Unfortunately, the current situation is that State is only
available as a lazy monad, and StateT is only available
as a strict monad.
It seems to me that this should clearly be conside
I can't seem to figure out how to achieve strictness in the context
of the State monad. Consider:
import Control.Monad.State
try count = print final
where (_,final) = runState prog 0
prog = sequence_ (replicate count tick)
tick :: State Int Int
tick = do n <- get
23 matches
Mail list logo
