[Haskell-cafe] Re: Shouldnt this be lazy too?

2007-09-24 Thread apfelmus
Vimal wrote: I was surprised to find out that the following piece of code: length [1..] 10 isnt lazily evaluated! I wouldnt expect this to be a bug, but in this case, shouldnt the computation end when the length function evaluation goes something like: 10 + length [11..] That's the

Re: [Haskell-cafe] Re: Shouldnt this be lazy too?

2007-09-24 Thread Ian Lynagh
On Mon, Sep 24, 2007 at 06:28:59PM +0200, apfelmus wrote: I mean, Haskell does not magically detect that the 32(64)-bit integer (10 + length [11..]) :: Int is bigger than 10 :: Int . That's partly because it's not true. There are arbitrarily large finite lists for which the equivalent is

Re: [Haskell-cafe] Re: Shouldnt this be lazy too?

2007-09-24 Thread Vimal
Prelude 10 + length (replicate maxBound 'a') -2147483639 Ah, nice example! If you note, this doesnt allocate memory at all! Very less footprint! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org

[Haskell-cafe] Re: Shouldnt this be lazy too?

2007-09-24 Thread Aaron Denney
On 2007-09-24, Andrew Coppin [EMAIL PROTECTED] wrote: Neil Mitchell wrote: Hi lengthNat [1..] 10 Couldn't be clearer, and can be made to work perfectly. If anyone does want to pick up the lazy naturals work, I can send over the code (or write it yourself - its not hard!) Um... isn't