lazy-evaluation

Is it possible to write a Haskell function which depends on whether values are calculated already or are thunks? E.g. if lazyShow :: [Int] -> String shows thunks as ? and calculated values normally, in GHCi we would see > let nats = [0..] > lazyShow nats 0 : ? > nats !! 5 5 > lazyShow nats 0 : 1 : 2 : 3 : 4 : ? Clearly, lazyShow cannot have the type you state. If the string should depend on the current state of evaluation, then IO String as a result is the best you can hope for. If all you're interested in is using this for debugging, then I think that the ghc-heap-view package (and

An infinite stream: val ones: Stream[Int] = Stream.cons(1, ones) How is it possible for a value to be used in its own declaration? It seems this should produce a compiler error, yet it works. It's not always a recursive definition. This actually works and produces 1: val a : Int = a + 1 println(a) variable a is created when you type val a: Int , so you can use it in the definition. Int is initialized to 0 by default. A class will be null. As @Chris pointed out, Stream accepts => Stream[A] so a bit another rules are applied, but I wanted to explain general case. The idea is still the same, but

Normally if you create a Stream object, the head will be eagerly evaluated: scala> Stream( {println("evaluating 1"); 1} , 2, 3) evaluating 1 res63: scala.collection.immutable.Stream[Int] = Stream(1, ?) If we create a Stream to which we prepend in the same statement, it seems slightly surprising that the head is not evaluated prior to the concatenation. i.e. scala> 0 #:: Stream( {println("evaluating 1"); 1} , 2, 3) res65: scala.collection.immutable.Stream[Int] = Stream(0, ?) ( #:: is right-associative and is the prepend method on ConsWrapper , which is an implicit class of Stream .) How does

I've compaired the scala version (BigInt(1) to BigInt(50000)).reduce(_ * _) to the python version reduce(lambda x,y: x*y, range(1,50000)) and it turns out, that the scala version took about 10 times longer than the python version. I'm guessing, a big difference is that python can use its native long type instead of creating new BigInt-objects for each number. But is there a workaround in scala? Travis Brown The fact that your Scala code creates 50,000 BigInt objects is unlikely to be making much of a difference here. A bigger issue is the multiplication algorithm— Python's long uses Karatsuba

I'm learning Haskell and currently trying to wrap my head around monads. While playing with some random number generation I got tripped on lazy evaluation once again. In an effort to simplify something close to the: roll :: State StdGen Int roll = do gen <- get let (n, newGen) = randomR (0,1) gen put newGen return n main = do gen <- getStdGen let x = sum $ evalState (replicateM iterations roll) gen print x into something like this: roll' :: IO Int roll' = getStdRandom $ randomR (0,1) main = do x' <- fmap sum $ replicateM iterations roll' print x' on a larger number of iterations , let's say

This FAQ says that The seq operator is seq :: a -> b -> b x seq y will evaluate x, enough to check that it is not bottom, then discard the result and evaluate y. This might not seem useful, but it means that x is guaranteed to be evaluated before y is considered. That's awfully nice of Haskell, but does it mean that in x `seq` f x the cost of evaluating x will be paid twice ("discard the result")? The seq function will discard the value of x , but since the value has been evaluated, all references to x are "updated" to no longer point to the unevaluated version of x , but to instead point to