[Haskell-cafe] Re: Shouldnt this be lazy too?
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 spirit, but you still need the right integer type for that :) I mean, Haskell does not magically detect that the 32(64)-bit integer (10 + length [11..]) :: Int is bigger than 10 :: Int . But by using peano numbers, the comparison function can detect that, see also http://article.gmane.org/gmane.comp.lang.haskell.cafe/26329 Regards, apfelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Shouldnt this be lazy too?
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 false, e.g. on a 32bit machine: Prelude 10 + length (replicate maxBound 'a') -2147483639 Thanks Ian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Shouldnt this be lazy too?
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 http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Shouldnt this be lazy too?
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 a lazy natural just a list with no data, where the list length encodes a number? That's one particularly simple representation, yes. Lazy Unary. One can also construct other representations that may be more efficient in certain situations. -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
