Re: [Haskell-cafe] curious about sum
OK, I think I went off on a tangent that isn't very useful anyway thanks -Keith On Wed, Jun 17, 2009 at 6:32 PM, Lennart Augustssonlenn...@augustsson.net wrote: The creators of Haskell didn't pick any particular representation for numbers. (Well, literals are kind of In..tegers.) You can pick what types you make instances of Num. Some of them are lazy, some of them are strict. On Wed, Jun 17, 2009 at 11:05 PM, Keith Sheppardkeiths...@gmail.com wrote: In lambda calculus numbers are just functions and you evaluate them just like any other function. Haskell could have chosen the same representation for numbers and all evaluation on numbers would be lazy (assuming normal order evaluation). I think that would have been the Purist Lazy way to go. That is not the way the creators of Haskell designed language though... am i missing something? On Wed, Jun 17, 2009 at 4:05 PM, Lennart Augustssonlenn...@augustsson.net wrote: What do you mean by literals are strict? Strictness is a semantic property of functions, and while literals can be overloaded to be functions I don't know what you mean. On Wed, Jun 17, 2009 at 9:50 PM, Keith Sheppardkeiths...@gmail.com wrote: Haskell's numeric literals are strict. You wouldn't want that to change right? It seems to me that having sum and product be strict is consistent with this. -Keith On Wed, Jun 17, 2009 at 11:15 AM, Thomas Davietom.da...@gmail.com wrote: On 17 Jun 2009, at 13:32, Yitzchak Gale wrote: Henk-Jan van Tuyl wrote: reverse maximum minimum Oh yes, please fix those also! import Prelude.Strict? Honestly, these functions are ones that I've *deffinately* used lazy versions of, in fact, in the cases of minimum/maximum I've even used ones that are super-lazy and parallel using unamb. It would be extremely odd to randomly decide most people would want this to be strict based on no knowledge of what they're actually doing. Instead, why don't we stand by the fact that haskell is a lazy language, and that the functions we get by default are lazy, and then write a strict prelude as I suggest above to complement the lazy version. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- keithsheppard.name ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- keithsheppard.name ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- keithsheppard.name ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
No, I think it's extremely useful. It highlights that numbers can both be lazy and strict, and that the so called useless lazy sum, is in fact, useful. Bob On 18 Jun 2009, at 13:29, Keith Sheppard wrote: OK, I think I went off on a tangent that isn't very useful anyway thanks -Keith On Wed, Jun 17, 2009 at 6:32 PM, Lennart Augustssonlenn...@augustsson.net wrote: The creators of Haskell didn't pick any particular representation for numbers. (Well, literals are kind of In..tegers.) You can pick what types you make instances of Num. Some of them are lazy, some of them are strict. On Wed, Jun 17, 2009 at 11:05 PM, Keith Sheppardkeiths...@gmail.com wrote: In lambda calculus numbers are just functions and you evaluate them just like any other function. Haskell could have chosen the same representation for numbers and all evaluation on numbers would be lazy (assuming normal order evaluation). I think that would have been the Purist Lazy way to go. That is not the way the creators of Haskell designed language though... am i missing something? On Wed, Jun 17, 2009 at 4:05 PM, Lennart Augustssonlenn...@augustsson.net wrote: What do you mean by literals are strict? Strictness is a semantic property of functions, and while literals can be overloaded to be functions I don't know what you mean. On Wed, Jun 17, 2009 at 9:50 PM, Keith Sheppardkeiths...@gmail.com wrote: Haskell's numeric literals are strict. You wouldn't want that to change right? It seems to me that having sum and product be strict is consistent with this. -Keith On Wed, Jun 17, 2009 at 11:15 AM, Thomas Davietom.da...@gmail.com wrote: On 17 Jun 2009, at 13:32, Yitzchak Gale wrote: Henk-Jan van Tuyl wrote: reverse maximum minimum Oh yes, please fix those also! import Prelude.Strict? Honestly, these functions are ones that I've *deffinately* used lazy versions of, in fact, in the cases of minimum/maximum I've even used ones that are super-lazy and parallel using unamb. It would be extremely odd to randomly decide most people would want this to be strict based on no knowledge of what they're actually doing. Instead, why don't we stand by the fact that haskell is a lazy language, and that the functions we get by default are lazy, and then write a strict prelude as I suggest above to complement the lazy version. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- keithsheppard.name ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- keithsheppard.name ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- keithsheppard.name ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
I don't think anyone is calling it useless at this point. I could not see a use for it initially and it was quickly pointed out that there are in fact some infrequent use cases where a lazy sum is the best option. I think this is more a discussion about principle of least surprise or which use case is most frequent. I am pretty new to haskell so I may just be missing something basic (I welcome an explaination for why I am looking at this the wrong way), but if your argument is on consistency then doesn't it follow that number litterals should be defined using a church encoding or some equivalent? -Keith On Thu, Jun 18, 2009 at 7:53 AM, Thomas Davietom.da...@gmail.com wrote: No, I think it's extremely useful. It highlights that numbers can both be lazy and strict, and that the so called useless lazy sum, is in fact, useful. Bob On 18 Jun 2009, at 13:29, Keith Sheppard wrote: OK, I think I went off on a tangent that isn't very useful anyway thanks -Keith On Wed, Jun 17, 2009 at 6:32 PM, Lennart Augustssonlenn...@augustsson.net wrote: The creators of Haskell didn't pick any particular representation for numbers. (Well, literals are kind of In..tegers.) You can pick what types you make instances of Num. Some of them are lazy, some of them are strict. On Wed, Jun 17, 2009 at 11:05 PM, Keith Sheppardkeiths...@gmail.com wrote: In lambda calculus numbers are just functions and you evaluate them just like any other function. Haskell could have chosen the same representation for numbers and all evaluation on numbers would be lazy (assuming normal order evaluation). I think that would have been the Purist Lazy way to go. That is not the way the creators of Haskell designed language though... am i missing something? On Wed, Jun 17, 2009 at 4:05 PM, Lennart Augustssonlenn...@augustsson.net wrote: What do you mean by literals are strict? Strictness is a semantic property of functions, and while literals can be overloaded to be functions I don't know what you mean. On Wed, Jun 17, 2009 at 9:50 PM, Keith Sheppardkeiths...@gmail.com wrote: Haskell's numeric literals are strict. You wouldn't want that to change right? It seems to me that having sum and product be strict is consistent with this. -Keith On Wed, Jun 17, 2009 at 11:15 AM, Thomas Davietom.da...@gmail.com wrote: On 17 Jun 2009, at 13:32, Yitzchak Gale wrote: Henk-Jan van Tuyl wrote: reverse maximum minimum Oh yes, please fix those also! import Prelude.Strict? Honestly, these functions are ones that I've *deffinately* used lazy versions of, in fact, in the cases of minimum/maximum I've even used ones that are super-lazy and parallel using unamb. It would be extremely odd to randomly decide most people would want this to be strict based on no knowledge of what they're actually doing. Instead, why don't we stand by the fact that haskell is a lazy language, and that the functions we get by default are lazy, and then write a strict prelude as I suggest above to complement the lazy version. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- keithsheppard.name ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- keithsheppard.name ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- keithsheppard.name ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- keithsheppard.name ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
Thomas Davie wrote: Not at all, as discussed, there are legitimate uses for a lazy sum, and haskell is a lazy language by default. Haskell is lazy by default, and we have found that to be a big win in most cases. So we don't need to be embarrassed to use strictness when that is the right thing to do. While there are indeed certain very rare situations in which you want foldr or foldl for sum, they are both joltingly wrong as the default for typical usage. In practice, I find this to be a small annoyance that occurs so often that it becomes a major one. Can we please fix it already? Let it be noted that this discussion also applies to product. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
On Wed, 17 Jun 2009 10:38:23 +0200, Yitzchak Gale g...@sefer.org wrote: While there are indeed certain very rare situations in which you want foldr or foldl for sum, they are both joltingly wrong as the default for typical usage. In practice, I find this to be a small annoyance that occurs so often that it becomes a major one. Can we please fix it already? Let it be noted that this discussion also applies to product. Thanks, Yitz I have done some research on functions in the base libraries, whether they can handle large lists; I didn't check them all, because there are so many of them. sum and product are certainly not the only ones having problems. For example: Hugs reverse [1 .. 99] ERROR - C stack overflow An improved reverse function: reverse' = foldl' (flip (:)) [] There is no need for reverse to be lazy, so this one could replace the original one. reverse' is not too strict: Data.List let reverse' = foldl' (flip (:)) [] in head $ reverse' [undefined, 1] 1 Some of the other functions that have problems with large lists are: foldM maximum minimum scanl scanr scanr1 iterate take(in GHCi, not in Hugs) drop(in GHCi, not in Hugs) splitAt (in GHCi, not in Hugs) inits By the way, sum and product are implemented with foldl' in Hugs. -- Met vriendelijke groet, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] curious about sum
Hello Henk-Jan, Wednesday, June 17, 2009, 3:07:41 PM, you wrote: I have done some research on functions in the base libraries, whether they can handle large lists long time ago i had problems with filterM, may be it's still fails -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
On Wed, Jun 17, 2009 at 1:07 PM, Henk-Jan van Tuylhjgt...@chello.nl wrote: On Wed, 17 Jun 2009 10:38:23 +0200, Yitzchak Gale g...@sefer.org wrote: An improved reverse function: reverse' = foldl' (flip (:)) [] There is no need for reverse to be lazy, so this one could replace the original one. reverse' is not too strict: Data.List let reverse' = foldl' (flip (:)) [] in head $ reverse' [undefined, 1] 1 Since reverse' is polymorphic in the type of list elements, the only way it could be strict in the *elements* is if it applied seq to them. --Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
Henk-Jan van Tuyl wrote: reverse maximum minimum Oh yes, please fix those also! scanl scanr scanr1 iterate take drop splitAt inits Hmm, I use those all the time with large lists. They are lazy as expected, and seem to work fine. Do you have examples of problems with them? foldM fliterM (Bulat) No opinion, I hardly use those. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
On 17 Jun 2009, at 13:32, Yitzchak Gale wrote: Henk-Jan van Tuyl wrote: reverse maximum minimum Oh yes, please fix those also! import Prelude.Strict? Honestly, these functions are ones that I've *deffinately* used lazy versions of, in fact, in the cases of minimum/maximum I've even used ones that are super-lazy and parallel using unamb. It would be extremely odd to randomly decide most people would want this to be strict based on no knowledge of what they're actually doing. Instead, why don't we stand by the fact that haskell is a lazy language, and that the functions we get by default are lazy, and then write a strict prelude as I suggest above to complement the lazy version. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
On Wed, 17 Jun 2009 13:32:40 +0200, Yitzchak Gale g...@sefer.org wrote: Henk-Jan van Tuyl wrote: reverse maximum minimum Oh yes, please fix those also! maximum' = foldl' max 0 [1 .. 99] minimum' = foldl' min 0 [1 .. 99] scanl scanr scanr1 iterate take drop splitAt inits Hmm, I use those all the time with large lists. They are lazy as expected, and seem to work fine. Do you have examples of problems with them? A hugs (version: Sep 2006) session: Hugs last $ scanl const 0 [0 .. 10 ^ 6] ERROR - C stack overflow Hugs head $ scanr (+) 0 [1 .. 10 ^ 6] ERROR - C stack overflow Hugs head $ scanr1 (+) [1 .. 10 ^ 6] ERROR - C stack overflow Hugs iterate (+ 1) 0 !! (10 ^ 6) ERROR - C stack overflow Hugs last $ take (10 ^ 6) [1 ..] 100 Hugs head $ drop (10 ^ 6) [1 ..] 101 Hugs head . snd $ splitAt (10 ^ 6) [1 ..] 101 Data.List last $ last $ inits [1 .. 10 ^ 6] ERROR - C stack overflow A GHCi 6.10.1 session: Prelude last $ scanl const 0 [0 .. 10 ^ 6] 0 Prelude head $ scanr (+) 0 [1 .. 10 ^ 6] *** Exception: stack overflow Prelude head $ scanr1 (+) [1 .. 10 ^ 6] *** Exception: stack overflow Prelude iterate (+ 1) 0 !! (10 ^ 6) *** Exception: stack overflow Prelude last $ take (10 ^ 6) [1 ..] 100 Prelude head $ drop (10 ^ 6) [1 ..] 101 Prelude head . snd $ splitAt (10 ^ 6) [1 ..] 101 Prelude :m Data.List Prelude Data.List last $ last $ inits [1 .. 10 ^ 6] ??? (not finished yet) take, drop and splitAt seem to work fine now, but when I did these tests the first time, GHCi generated a stack overflow exception (I think it was GHCi 6.8.3). foldM filterM (Bulat) foldM' f a (x:xs) = do a' - f a x a' `seq` foldM' f a' xs -- Met vriendelijke groet, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
On Wed, 17 Jun 2009 18:22:51 +0200, Henk-Jan van Tuyl hjgt...@chello.nl wrote: On Wed, 17 Jun 2009 13:32:40 +0200, Yitzchak Gale g...@sefer.org wrote: Henk-Jan van Tuyl wrote: reverse maximum minimum Oh yes, please fix those also! maximum' = foldl' max 0 [1 .. 99] minimum' = foldl' min 0 [1 .. 99] Of course I meant: maximum' xs = foldl1' max xs minimum' xs = foldl1' min xs -- Met vriendelijke groet, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
Haskell's numeric literals are strict. You wouldn't want that to change right? It seems to me that having sum and product be strict is consistent with this. -Keith On Wed, Jun 17, 2009 at 11:15 AM, Thomas Davietom.da...@gmail.com wrote: On 17 Jun 2009, at 13:32, Yitzchak Gale wrote: Henk-Jan van Tuyl wrote: reverse maximum minimum Oh yes, please fix those also! import Prelude.Strict? Honestly, these functions are ones that I've *deffinately* used lazy versions of, in fact, in the cases of minimum/maximum I've even used ones that are super-lazy and parallel using unamb. It would be extremely odd to randomly decide most people would want this to be strict based on no knowledge of what they're actually doing. Instead, why don't we stand by the fact that haskell is a lazy language, and that the functions we get by default are lazy, and then write a strict prelude as I suggest above to complement the lazy version. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- keithsheppard.name ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
What do you mean by literals are strict? Strictness is a semantic property of functions, and while literals can be overloaded to be functions I don't know what you mean. On Wed, Jun 17, 2009 at 9:50 PM, Keith Sheppardkeiths...@gmail.com wrote: Haskell's numeric literals are strict. You wouldn't want that to change right? It seems to me that having sum and product be strict is consistent with this. -Keith On Wed, Jun 17, 2009 at 11:15 AM, Thomas Davietom.da...@gmail.com wrote: On 17 Jun 2009, at 13:32, Yitzchak Gale wrote: Henk-Jan van Tuyl wrote: reverse maximum minimum Oh yes, please fix those also! import Prelude.Strict? Honestly, these functions are ones that I've *deffinately* used lazy versions of, in fact, in the cases of minimum/maximum I've even used ones that are super-lazy and parallel using unamb. It would be extremely odd to randomly decide most people would want this to be strict based on no knowledge of what they're actually doing. Instead, why don't we stand by the fact that haskell is a lazy language, and that the functions we get by default are lazy, and then write a strict prelude as I suggest above to complement the lazy version. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- keithsheppard.name ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
In lambda calculus numbers are just functions and you evaluate them just like any other function. Haskell could have chosen the same representation for numbers and all evaluation on numbers would be lazy (assuming normal order evaluation). I think that would have been the Purist Lazy way to go. That is not the way the creators of Haskell designed language though... am i missing something? On Wed, Jun 17, 2009 at 4:05 PM, Lennart Augustssonlenn...@augustsson.net wrote: What do you mean by literals are strict? Strictness is a semantic property of functions, and while literals can be overloaded to be functions I don't know what you mean. On Wed, Jun 17, 2009 at 9:50 PM, Keith Sheppardkeiths...@gmail.com wrote: Haskell's numeric literals are strict. You wouldn't want that to change right? It seems to me that having sum and product be strict is consistent with this. -Keith On Wed, Jun 17, 2009 at 11:15 AM, Thomas Davietom.da...@gmail.com wrote: On 17 Jun 2009, at 13:32, Yitzchak Gale wrote: Henk-Jan van Tuyl wrote: reverse maximum minimum Oh yes, please fix those also! import Prelude.Strict? Honestly, these functions are ones that I've *deffinately* used lazy versions of, in fact, in the cases of minimum/maximum I've even used ones that are super-lazy and parallel using unamb. It would be extremely odd to randomly decide most people would want this to be strict based on no knowledge of what they're actually doing. Instead, why don't we stand by the fact that haskell is a lazy language, and that the functions we get by default are lazy, and then write a strict prelude as I suggest above to complement the lazy version. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- keithsheppard.name ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- keithsheppard.name ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
The creators of Haskell didn't pick any particular representation for numbers. (Well, literals are kind of Integers.) You can pick what types you make instances of Num. Some of them are lazy, some of them are strict. On Wed, Jun 17, 2009 at 11:05 PM, Keith Sheppardkeiths...@gmail.com wrote: In lambda calculus numbers are just functions and you evaluate them just like any other function. Haskell could have chosen the same representation for numbers and all evaluation on numbers would be lazy (assuming normal order evaluation). I think that would have been the Purist Lazy way to go. That is not the way the creators of Haskell designed language though... am i missing something? On Wed, Jun 17, 2009 at 4:05 PM, Lennart Augustssonlenn...@augustsson.net wrote: What do you mean by literals are strict? Strictness is a semantic property of functions, and while literals can be overloaded to be functions I don't know what you mean. On Wed, Jun 17, 2009 at 9:50 PM, Keith Sheppardkeiths...@gmail.com wrote: Haskell's numeric literals are strict. You wouldn't want that to change right? It seems to me that having sum and product be strict is consistent with this. -Keith On Wed, Jun 17, 2009 at 11:15 AM, Thomas Davietom.da...@gmail.com wrote: On 17 Jun 2009, at 13:32, Yitzchak Gale wrote: Henk-Jan van Tuyl wrote: reverse maximum minimum Oh yes, please fix those also! import Prelude.Strict? Honestly, these functions are ones that I've *deffinately* used lazy versions of, in fact, in the cases of minimum/maximum I've even used ones that are super-lazy and parallel using unamb. It would be extremely odd to randomly decide most people would want this to be strict based on no knowledge of what they're actually doing. Instead, why don't we stand by the fact that haskell is a lazy language, and that the functions we get by default are lazy, and then write a strict prelude as I suggest above to complement the lazy version. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- keithsheppard.name ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- keithsheppard.name ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
Jochem Berndsen schrieb: Deniz Dogan wrote: 2009/6/13 Jochem Berndsen joc...@functor.nl: Keith Sheppard wrote: Is there any reason that sum isn't strict? I can't think of any case where that is a good thing. Prelude sum [0 .. 100] *** Exception: stack overflow It is useful if the (+) is nonstrict; although I cannot think of any useful mathematical structure where (+) would be nonstrict. I remember needing a non-strict sum at least once, but I do not remember the exact application. But imagine having a (very) long list of numbers and you want to do A if the sum exceeds a small number, otherwise B. if sum [0..10] 10 then A else B However, this idea didn't work, because of strictness. You can only do such things if you know that all entries of your list are nonnegative. That requires a custom solution anyway (not to mention the fact that to determine whether x 10 or not, we need to explicitly compute x). http://hackage.haskell.org/packages/archive/non-negative/0.0.5/doc/html/Numeric-NonNegative-Chunky.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
On Mon, 15 Jun 2009, Don Stewart wrote: keithshep: The answer is sometimes (only if you use an optimize flag): You're turning on the strictness analyser. That's enabled with -O or -O2. But sum should be using a tail recursive foldl'. It's a bug in the H98 report, IMO. I can wrap an accumulator lazily: data Accum a = Accum a Then foldl' using (Accum a) instead of 'a' would be non-strict, again. Thus foldl' is not always strict. I think this 'seq' function is broken and there should have been a Seq class. Then you can choose the required depth of strictness. Btw. for lazy Peano numbers, sum would be better a foldr rather than foldl. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
On 16 Jun 2009, at 05:18, Don Stewart wrote: keithshep: The answer is sometimes (only if you use an optimize flag): You're turning on the strictness analyser. That's enabled with -O or -O2. But sum should be using a tail recursive foldl'. It's a bug in the H98 report, IMO. Not at all, as discussed, there are legitimate uses for a lazy sum, and haskell is a lazy language by default. The only change here needs to be either claus' suggestion of generalizing functions over their application operator, or providing a strict sum'. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
tom.davie: On 16 Jun 2009, at 05:18, Don Stewart wrote: keithshep: The answer is sometimes (only if you use an optimize flag): You're turning on the strictness analyser. That's enabled with -O or -O2. But sum should be using a tail recursive foldl'. It's a bug in the H98 report, IMO. Not at all, as discussed, there are legitimate uses for a lazy sum, and haskell is a lazy language by default. The only change here needs to be either claus' suggestion of generalizing functions over their application operator, or providing a strict sum'. Are the legitimate uses more common than the illegitimate uses? -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Fwd: [Haskell-cafe] curious about sum
On Sun, Jun 14, 2009 at 21:23, Jochem Berndsenjoc...@functor.nl wrote: Alberto G. Corona wrote: Once more I forgot to send my messages to the haskell cafe list. All the rest of the list which I惴 suscribed to, send the mail replies to the list automatically, but this doesn��. Please, can this be changed?. This comes up every so often, but I would be against this. Your e-mail client should support mailing lists. This list does not fill out the Reply-To header. Many other lists do. I am all for adding it, if there's no specific reason not to. Thomas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Fwd: [Haskell-cafe] curious about sum
Again: what if somebody wants to answer to the original author privately? It's easier to just use Reply for private answers and Reply all for list answers. Thomas ten Cate wrote on 15.06.2009 11:18: On Sun, Jun 14, 2009 at 21:23, Jochem Berndsenjoc...@functor.nl wrote: Alberto G. Corona wrote: Once more I forgot to send my messages to the haskell cafe list. All the rest of the list which I惴 suscribed to, send the mail replies to the list automatically, but this doesn��. Please, can this be changed?. This comes up every so often, but I would be against this. Your e-mail client should support mailing lists. This list does not fill out the Reply-To header. Many other lists do. I am all for adding it, if there's no specific reason not to. Thomas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
keithshep: Is there any reason that sum isn't strict? I can't think of any case where that is a good thing. Prelude sum [0 .. 100] *** Exception: stack overflow It is strict when subject to strictness analysis (try compiling it). -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
The answer is sometimes (only if you use an optimize flag): ke...@sugarglider:~/temp/ cat sumtest.hs main = putStrLn . show . sum $ [0 .. 100] ke...@sugarglider:~/temp/ ghc --make sumtest.hs [1 of 1] Compiling Main ( sumtest.hs, sumtest.o ) Linking sumtest ... ke...@sugarglider:~/temp/ ./sumtest Stack space overflow: current size 8388608 bytes. Use `+RTS -Ksize' to increase it. ke...@sugarglider:~/temp/ rm sumtest.hi sumtest.o sumtest ke...@sugarglider:~/temp/ ghc --make -O2 sumtest.hs [1 of 1] Compiling Main ( sumtest.hs, sumtest.o ) Linking sumtest ... ke...@sugarglider:~/temp/ ./sumtest 5050 ke...@sugarglider:~/temp/ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.1 But since hackage warns against using these flags when you upload packages I would think that most libraries would not be using a strict version of sum. On Mon, Jun 15, 2009 at 11:14 AM, Don Stewartd...@galois.com wrote: keithshep: Is there any reason that sum isn't strict? I can't think of any case where that is a good thing. Prelude sum [0 .. 100] *** Exception: stack overflow It is strict when subject to strictness analysis (try compiling it). -- Don -- keithsheppard.name ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
I just realized... that was a statement not a question :-) anyway, thanks Keith On Mon, Jun 15, 2009 at 11:14 AM, Don Stewartd...@galois.com wrote: keithshep: Is there any reason that sum isn't strict? I can't think of any case where that is a good thing. Prelude sum [0 .. 100] *** Exception: stack overflow It is strict when subject to strictness analysis (try compiling it). -- Don -- keithsheppard.name ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
keithshep: The answer is sometimes (only if you use an optimize flag): You're turning on the strictness analyser. That's enabled with -O or -O2. But sum should be using a tail recursive foldl'. It's a bug in the H98 report, IMO. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
* Deniz Dogan deniz.a.m.do...@gmail.com [2009-06-13 16:17:57+0200] I remember needing a non-strict sum at least once, but I do not remember the exact application. We may agree that lazy sum is sometimes (rarely) needed, but then it can be always written as fold. However, in most cases user wants strict sum. So it's not really an excuse. -- Roman I. Cheplyaka :: http://ro-che.info/ Don't let school get in the way of your education. - Mark Twain ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Fwd: [Haskell-cafe] curious about sum
Once more I forgot to send my messages to the haskell cafe list. All the rest of the list which I´m suscribed to, send the mail replies to the list automatically, but this doesn´t. Please, can this be changed?. -- Forwarded message -- From: Alberto G. Corona agocor...@gmail.com Date: 2009/6/13 Subject: Re: [Haskell-cafe] curious about sum To: Deniz Dogan deniz.a.m.do...@gmail.com first, I was completely wrong. It is foldl what is neccesary. sum is defined in terms of foldl: sum= foldl (+) 0 but Prelude foldl (+) 0 [1..100] *** Exception: stack overflow that is not because + is non strict, but because foldl is: foldl f z0 xs0 = lgo z0 xs0 where lgo z [] = z lgo z (x:xs) = lgo (f z x) xs this version of foldl IS strict: foldlStrict f z0 xs0 = lgo z0 xs0 where lgo z [] = z lgo z (x:xs) =let t= f z x in t `seq` lgo t xs main= print $ foldlStrict (+) 0 [1..100] 5050 so the garbage collector do the job in freeing the consumed part of the list. 2009/6/13 Alberto G. Corona agocor...@gmail.com Prelude let strictplus x y= let z=x +y in z `seq` z; sum1= foldr strictplus 0 in sum1[0..100] *** Exception: stack overflow I suppose that strictplus is strict, so the garbage collector would free the consumed part of the list. Then, why the stack overflow? 2009/6/13 Deniz Dogan deniz.a.m.do...@gmail.com 2009/6/13 Jochem Berndsen joc...@functor.nl: Keith Sheppard wrote: Is there any reason that sum isn't strict? I can't think of any case where that is a good thing. Prelude sum [0 .. 100] *** Exception: stack overflow It is useful if the (+) is nonstrict; although I cannot think of any useful mathematical structure where (+) would be nonstrict. I remember needing a non-strict sum at least once, but I do not remember the exact application. But imagine having a (very) long list of numbers and you want to do A if the sum exceeds a small number, otherwise B. if sum [0..10] 10 then A else B However, this idea didn't work, because of strictness. -- Deniz Dogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
On 14 Jun 2009, at 12:47, Roman Cheplyaka wrote: * Deniz Dogan deniz.a.m.do...@gmail.com [2009-06-13 16:17:57+0200] I remember needing a non-strict sum at least once, but I do not remember the exact application. We may agree that lazy sum is sometimes (rarely) needed, but then it can be always written as fold. However, in most cases user wants strict sum. So it's not really an excuse. How's this for an excuse - Haskell is a lazy language. It also happens to have support for strictifying things when necessary. The Haskell API is designed to be lazy, like the rest of the language, similarly though, where commonly used, strict versions are provided, like for example foldl'. A much better idea than making sum strict, would simply be to add a sum'. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Fwd: [Haskell-cafe] curious about sum
Alberto G. Corona wrote: Once more I forgot to send my messages to the haskell cafe list. All the rest of the list which I´m suscribed to, send the mail replies to the list automatically, but this doesn´t. Please, can this be changed?. This comes up every so often, but I would be against this. Your e-mail client should support mailing lists. this version of foldl IS strict: foldlStrict f z0 xs0 = lgo z0 xs0 where lgo z [] = z lgo z (x:xs) =let t= f z x in t `seq` lgo t xs main= print $ foldlStrict (+) 0 [1..100] 5050 so the garbage collector do the job in freeing the consumed part of the list This is correct; the function you defined is equivalent to foldl' in Data.List, if I'm not mistaken. Regards, -- Jochem Berndsen | joc...@functor.nl GPG: 0xE6FABFAB ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
A much better idea than making sum strict, would simply be to add a
sum'.
Even better to abstract over strictness, to keep a lid on code duplication?
{-# LANGUAGE TypeOperators #-}
sum = foldlS ($) (+) 0
sum' = foldlS ($!) (+) 0
-- identity on constructors of t (from a), modulo strictness in a
type a :-? t = (a - t) - (a - t)
foldlS :: (b :-? ([a] - b)) - (a - b - b) - (b - [a] - b)
foldlS ($) op n []= n
foldlS ($) op n (h:t) = (foldlS ($) op $ (op h n)) t
Strictness is encoded as a constructor transformer - ($) keeps the
constructor in question unchanged, ($!) makes it strict. Also works
with container types (Maps strict or not strict in their elements can
share the same strictness-abstracted code, for instance). Though
sometimes there is more than one strictness choice to make in the
same piece of code..
Claus
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] curious about sum
Is there any reason that sum isn't strict? I can't think of any case where that is a good thing. Prelude sum [0 .. 100] *** Exception: stack overflow -Keith -- keithsheppard.name ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
Keith Sheppard wrote: Is there any reason that sum isn't strict? I can't think of any case where that is a good thing. Prelude sum [0 .. 100] *** Exception: stack overflow It is useful if the (+) is nonstrict; although I cannot think of any useful mathematical structure where (+) would be nonstrict. Regards, -- Jochem Berndsen | joc...@functor.nl GPG: 0xE6FABFAB ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
2009/6/13 Jochem Berndsen joc...@functor.nl: Keith Sheppard wrote: Is there any reason that sum isn't strict? I can't think of any case where that is a good thing. Prelude sum [0 .. 100] *** Exception: stack overflow It is useful if the (+) is nonstrict; although I cannot think of any useful mathematical structure where (+) would be nonstrict. I remember needing a non-strict sum at least once, but I do not remember the exact application. But imagine having a (very) long list of numbers and you want to do A if the sum exceeds a small number, otherwise B. if sum [0..10] 10 then A else B However, this idea didn't work, because of strictness. -- Deniz Dogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
Jochem Berndsen wrote: Keith Sheppard wrote: Is there any reason that sum isn't strict? I can't think of any case where that is a good thing. Prelude sum [0 .. 100] *** Exception: stack overflow It is useful if the (+) is nonstrict; although I cannot think of any useful mathematical structure where (+) would be nonstrict. What about some numeric representations? type MyNum = [()] instance Num MyNum where (+) = (++) Regards, Stephan -- Früher hieß es ja: Ich denke, also bin ich. Heute weiß man: Es geht auch so. - Dieter Nuhr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
That's an interesting example. I guess a lazy number system like that would work nicely for Deniz's use case. On Sat, Jun 13, 2009 at 10:26 AM, Stephan Friedrichsdeduktionstheo...@web.de wrote: Jochem Berndsen wrote: Keith Sheppard wrote: Is there any reason that sum isn't strict? I can't think of any case where that is a good thing. Prelude sum [0 .. 100] *** Exception: stack overflow It is useful if the (+) is nonstrict; although I cannot think of any useful mathematical structure where (+) would be nonstrict. What about some numeric representations? type MyNum = [()] instance Num MyNum where (+) = (++) Regards, Stephan -- Früher hieß es ja: Ich denke, also bin ich. Heute weiß man: Es geht auch so. - Dieter Nuhr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- keithsheppard.name ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
Deniz Dogan wrote: 2009/6/13 Jochem Berndsen joc...@functor.nl: Keith Sheppard wrote: Is there any reason that sum isn't strict? I can't think of any case where that is a good thing. Prelude sum [0 .. 100] *** Exception: stack overflow It is useful if the (+) is nonstrict; although I cannot think of any useful mathematical structure where (+) would be nonstrict. I remember needing a non-strict sum at least once, but I do not remember the exact application. But imagine having a (very) long list of numbers and you want to do A if the sum exceeds a small number, otherwise B. if sum [0..10] 10 then A else B However, this idea didn't work, because of strictness. You can only do such things if you know that all entries of your list are nonnegative. That requires a custom solution anyway (not to mention the fact that to determine whether x 10 or not, we need to explicitly compute x). Regards, -- Jochem Berndsen | joc...@functor.nl GPG: 0xE6FABFAB ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
Am Samstag 13 Juni 2009 17:00:36 schrieb Jochem Berndsen: Deniz Dogan wrote: 2009/6/13 Jochem Berndsen joc...@functor.nl: Keith Sheppard wrote: Is there any reason that sum isn't strict? I can't think of any case where that is a good thing. Prelude sum [0 .. 100] *** Exception: stack overflow It is useful if the (+) is nonstrict; although I cannot think of any useful mathematical structure where (+) would be nonstrict. I remember needing a non-strict sum at least once, but I do not remember the exact application. But imagine having a (very) long list of numbers and you want to do A if the sum exceeds a small number, otherwise B. if sum [0..10] 10 then A else B However, this idea didn't work, because of strictness. You can only do such things if you know that all entries of your list are nonnegative. That requires a custom solution anyway (not to mention the fact that to determine whether x 10 or not, we need to explicitly compute x). Well, if you have lazy Peano numbers of any kind, you know that all entries are non- negative and you needn't evaluate x fully to determine whether it's 10. Isn't that the point why one would use lazy numbers at all? Regards, ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
Daniel Fischer wrote: Am Samstag 13 Juni 2009 17:00:36 schrieb Jochem Berndsen: Deniz Dogan wrote: 2009/6/13 Jochem Berndsen joc...@functor.nl: Keith Sheppard wrote: Is there any reason that sum isn't strict? I can't think of any case where that is a good thing. Prelude sum [0 .. 100] *** Exception: stack overflow It is useful if the (+) is nonstrict; although I cannot think of any useful mathematical structure where (+) would be nonstrict. I remember needing a non-strict sum at least once, but I do not remember the exact application. But imagine having a (very) long list of numbers and you want to do A if the sum exceeds a small number, otherwise B. if sum [0..10] 10 then A else B However, this idea didn't work, because of strictness. You can only do such things if you know that all entries of your list are nonnegative. That requires a custom solution anyway (not to mention the fact that to determine whether x 10 or not, we need to explicitly compute x). Well, if you have lazy Peano numbers of any kind, you know that all entries are non- negative and you needn't evaluate x fully to determine whether it's 10. Isn't that the point why one would use lazy numbers at all? Yes. (That's what I meant with 'custom solution', using Peano numbers instead of Ints or Integers.) Regards, -- Jochem Berndsen | joc...@functor.nl GPG: 0xE6FABFAB ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
You can make numeric class instances from arbitrary Applicatives [1]. I imagine a lot of them (e.g. Stream) would want at least some non-strictness. We might provide strict alternatives for sum and product. I wonder what else. [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/applicative-numbers - Conal On Sat, Jun 13, 2009 at 7:03 AM, Keith Sheppard keiths...@gmail.com wrote: Is there any reason that sum isn't strict? I can't think of any case where that is a good thing. Prelude sum [0 .. 100] *** Exception: stack overflow -Keith -- keithsheppard.name ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
Keith Sheppard wrote: Is there any reason that sum isn't strict? I can't think of any case where that is a good thing. Prelude sum [0 .. 100] *** Exception: stack overflow As others have said, there are cases where non-strictness is what you want. And if you are using a type that is strict (the common case), GHC's optimizations will catch it. The historical reason for this is that foldl' is not Haskell 98, only foldl. - Jake ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
