I was under the impression that operations performed in monads (in this
case, the IO monad) were lazy. (Certainly, every time I make the
opposite assumption, my code fails :P .) Which doesn't explain why the
following code fails to terminate:
iRecurse :: (Num a) = IO a
iRecurse = do
Suppose iRecurse looks like this:
iRecurse = do
x - launchMissiles
r - iRecurse
return 1
As x is never needed, launchMissiles will never execute. It obviously is
not what is needed.
But in Haskell, standart file input|output is often lazy. It's a
combination of buffering and
On 05/31/2011 04:20 PM, Artyom Kazak wrote:
Suppose iRecurse looks like this:
iRecurse = do
x - launchMissiles
r - iRecurse
return 1
As x is never needed, launchMissiles will never execute. It obviously is
not what is needed.
Prelude let launchMissiles = putStrLn UH OH
On Tue, May 31, 2011 at 3:49 PM, Scott Lawrence byt...@gmail.com wrote:
I was under the impression that operations performed in monads (in this
case, the IO monad) were lazy. (Certainly, every time I make the
opposite assumption, my code fails :P .) Which doesn't explain why the
following code
No, I think Artyom meant assuming IO is lazy.
He intended to show that, indeed, it is not, or else side-effects would
never be performed
2011/5/31 Scott Lawrence byt...@gmail.com
On 05/31/2011 04:20 PM, Artyom Kazak wrote:
Suppose iRecurse looks like this:
iRecurse = do
x -
Scott Lawrence byt...@gmail.com писал(а) в своём письме Tue, 31 May 2011
23:29:49 +0300:
On 05/31/2011 04:20 PM, Artyom Kazak wrote:
Suppose iRecurse looks like this:
iRecurse = do
x - launchMissiles
r - iRecurse
return 1
As x is never needed, launchMissiles will never
On 5/31/11 12:49 PM, Scott Lawrence wrote:
I was under the impression that operations performed in monads (in this
case, the IO monad) were lazy.
Whether they are lazy or not depends entirely on the definition of the
monad. For example, if you look up the ST and State monads you will
find
On 05/31/2011 04:48 PM, Artyom Kazak wrote:
Oh, sorry. I was unclear. I have meant assuming IO is lazy, as Yves
wrote.
Ah, ok. That makes more sense.
And saying some hacks I meant unsafeInterleaveIO, which lies beneath
the laziness of, for example, getContents.
Which explains why
On Tuesday 31 May 2011 22:35:26, Yves Parès wrote:
He intended to show that, indeed, it is not, or else side-effects would
never be performed
On the other hand, IO is lazy in the values it produces.
Going with the IO a = State RealWorld a fiction, IO is state-strict but
value-lazy. The
2011/5/31 Scott Lawrence byt...@gmail.com:
Evaluation here also doesn't terminate (or, (head $ unfoldM (return .
head)) doesn't), although I can't figure out why. fmap shouldn't need to
fully evaluate a list to prepend an element, right?
I'm afriad fmap doesn't get to choose - if the monad is
Apparently:
Prelude let r = (fmap (1:) r) :: IO [Integer]
Prelude fmap (take 5) r
*** Exception: stack overflow
Thanks - I'll just have to stay out of IO for this, then.
On Tue, May 31, 2011 at 17:05, Stephen Tetley stephen.tet...@gmail.com wrote:
2011/5/31 Scott Lawrence byt...@gmail.com:
On Tue, May 31, 2011 at 2:49 PM, Scott Lawrence byt...@gmail.com wrote:
I was under the impression that operations performed in monads (in this
case, the IO monad) were lazy. (Certainly, every time I make the
opposite assumption, my code fails :P .) Which doesn't explain why the
following code
On Tue, May 31, 2011 at 6:10 PM, Antoine Latter aslat...@gmail.com wrote:
You could use a different type:
type IOStream a = (a, IO (IOStream a))
unfold :: ([a] - IO a) - IO (IOStream a)
unfold f =
let go prev = do
next - f prev
return (next, go (next:prev))
On a tangent, not doing IO, but food for thought:
{-# LANGUAGE FlexibleContexts #-}
import Control.Monad.State.Lazy as N
import Control.Monad.State.Strict as S
gen :: (MonadState [()] m) = m ()
gen = do
gen
modify (() :)
many = take 3 (N.execState gen [])
none = take 3 (S.execState gen
14 matches
Mail list logo
