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

On Mon, 24 Sep 2007, Neil Mitchell wrote: Hi In this world, use length (take 11 [1..]) 10... not (null (drop 10 [1..])) is surely faster (not tested...) Faster? There might be a few microseconds in it. Clearer? Possibly... ;-) lengthNat [1..] 10 Couldn't be clearer, and can be made

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

Vimal wrote: From the wiki: If you write it, you force Haskell to create all list nodes. ... Alright. Now, lets look at the definition again: length [] = 0 length (x:xs) = 1 + length xs We see that the value of *x* isnt needed at all. So, why does GHC allocate so much memory creating all

[Haskell-cafe] Shouldnt this be lazy too?

Hi all, 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..] ? -- -- Vimal

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

Hi Vimal, I was surprised to find out that the following piece of code: length [1..] 10 isnt lazily evaluated! The problem is that Int and Integer are both eager. It is possible to write a lazy peano number based data type, but I'm not aware of anyone who has - I have half the code (in

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

Vimal wrote: Hi all, 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..] I

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

Vimal wrote: Hi all, 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

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

On Mon, 24 Sep 2007, Vimal wrote: Hi all, 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:

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

On Mon, 24 Sep 2007, Vimal wrote: Hi all, I was surprised to find out that the following piece of code: length [1..] 10 isnt lazily evaluated! http://www.haskell.org/haskellwiki/Things_to_avoid#Don.27t_ask_for_the_length_of_a_list_when_you_don.27t_need_it

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

Wow, half an hour, about 7 replies :) I dont know which one to quote! Okay. So, why is GHC finding it difficult to conclude that length is always 0? Suppose I define length like: length [] = 0 length (x:xs) = 1 + length xs Hmm, well, I think the fact that we, as humans, expecting GHC to infer

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

From the wiki: If you write it, you force Haskell to create all list nodes. ... Alright. Now, lets look at the definition again: length [] = 0 length (x:xs) = 1 + length xs We see that the value of *x* isnt needed at all. So, why does GHC allocate so much memory creating all those *x*s?

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

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: No. You want GHC to deduce that length would only increase in future. This property is relatively complex and

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

On Mon, 2007-09-24 at 17:35 +0100, Andrew Coppin wrote: Vimal wrote: Hi all, 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

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

Hi In this world, use length (take 11 [1..]) 10... not (null (drop 10 [1..])) is surely faster (not tested...) Faster? There might be a few microseconds in it. Clearer? Possibly... ;-) lengthNat [1..] 10 Couldn't be clearer, and can be made to work perfectly. If anyone does want to

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

Jonathan Cast wrote: On Mon, 2007-09-24 at 17:35 +0100, Andrew Coppin wrote: In an ideal world, yes. In this world, use length (take 11 [1..]) 10... not (null (drop 10 [1..])) is surely faster (not tested...) Faster? There might be a few microseconds in it. Clearer?

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

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

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

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

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

Neil Mitchell wrote: Hi Um... isn't a lazy natural just a list with no data, where the list length encodes a number? Pretty much, yes. So I just need to write newtype LazyNatural = LazyNatural [()] and then add some suitable instances. ;-) (Woah... that's one bizzare-looking

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

Hi Pretty much, yes. So I just need to write newtype LazyNatural = LazyNatural [()] or data Nat = Zero | Succ Nat it's your choice really. and then add some suitable instances. ;-) Yes. Lots of them. Lots of instances and lots of methods. Hey, the length function would then just

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

Neil Mitchell wrote: Hi Pretty much, yes. So I just need to write newtype LazyNatural = LazyNatural [()] or data Nat = Zero | Succ Nat it's your choice really. I'm guessing there's going to be fairly minimal performance difference. (Or maybe there is. My way uses

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

Hi I'm guessing there's going to be fairly minimal performance difference. (Or maybe there is. My way uses a few additional pointers. But it also allows me to elegantly recycle existing Prelude list functions, so...) I think we can safely assume that people using peano numbers aren't actually

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

On Mon, 24 Sep 2007, Vimal wrote: Wow, half an hour, about 7 replies :) I dont know which one to quote! Okay. So, why is GHC finding it difficult to conclude that length is always 0? Suppose I define length like: length [] = 0 length (x:xs) = 1 + length xs Hmm, well, I think the fact

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

Since natural numbers are trivial to implement (inefficiently) I took 15 minutes and added them to my numbers package in Hackage. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/numbers-2007.9.24 -- Lennart On 9/24/07, Andrew Coppin [EMAIL PROTECTED] wrote: Neil Mitchell wrote:

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

PS. Prelude Data.List Data.Number.Natural genericLength [1..] (10 :: Natural) True On 9/24/07, Lennart Augustsson [EMAIL PROTECTED] wrote: Since natural numbers are trivial to implement (inefficiently) I took 15 minutes and added them to my numbers package in Hackage.