curious about sum

Keith Sheppard

13 Jun 2009 13 Jun '09

2:03 p.m.

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 .. 1000000] *** Exception: stack overflow -Keith -- keithsheppard.name

Show replies by date

Jochem Berndsen

13 Jun 13 Jun

2:09 p.m.

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 .. 1000000] *** 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 | jochem@functor.nl GPG: 0xE6FABFAB

Deniz Dogan

2:17 p.m.

2009/6/13 Jochem Berndsen :

...

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 .. 1000000] *** 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..100000] > 10 then A else B However, this idea didn't work, because of strictness. -- Deniz Dogan

Jochem Berndsen

3 p.m.

Deniz Dogan wrote:

...

2009/6/13 Jochem Berndsen :

...
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 .. 1000000] *** 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..100000] > 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 | jochem@functor.nl GPG: 0xE6FABFAB

Daniel Fischer

3:41 p.m.

Am Samstag 13 Juni 2009 17:00:36 schrieb Jochem Berndsen:

...

Deniz Dogan wrote:

...
2009/6/13 Jochem Berndsen :

...
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 .. 1000000] *** 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..100000] > 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,

Jochem Berndsen

3:50 p.m.

Daniel Fischer wrote:

...

Am Samstag 13 Juni 2009 17:00:36 schrieb Jochem Berndsen:

...
...
2009/6/13 Jochem Berndsen :

...
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 .. 1000000] *** 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..100000] > 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

Deniz Dogan wrote: 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 | jochem@functor.nl GPG: 0xE6FABFAB

Henning Thielemann

16 Jun 16 Jun

11:10 a.m.

Jochem Berndsen schrieb:

...

Deniz Dogan wrote:

...
2009/6/13 Jochem Berndsen :

...
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 .. 1000000] *** 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..100000] > 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/Nume...

Roman Cheplyaka

14 Jun 14 Jun

10:47 a.m.

* Deniz Dogan [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

Thomas Davie

7:10 p.m.

On 14 Jun 2009, at 12:47, Roman Cheplyaka wrote:

...

* Deniz Dogan [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

Claus Reinke

9:29 p.m.

...

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

Stephan Friedrichs

13 Jun 13 Jun

2:26 p.m.

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 .. 1000000] *** 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

Keith Sheppard

2:47 p.m.

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 Friedrichs 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 .. 1000000] *** 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

Conal Elliott

5:23 p.m.

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-numbe... - Conal On Sat, Jun 13, 2009 at 7:03 AM, 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 .. 1000000] *** Exception: stack overflow

-Keith -- keithsheppard.name _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Jake McArthur

8:18 p.m.

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 .. 1000000] *** 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

Don Stewart

15 Jun 15 Jun

3:14 p.m.

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 .. 1000000] *** Exception: stack overflow

It is strict when subject to strictness analysis (try compiling it). -- Don

Keith Sheppard

16 Jun 16 Jun

12:49 a.m.

The answer is sometimes (only if you use an optimize flag): keith@sugarglider:~/temp/> cat sumtest.hs main = putStrLn . show . sum $ [0 .. 1000000] keith@sugarglider:~/temp/> ghc --make sumtest.hs [1 of 1] Compiling Main ( sumtest.hs, sumtest.o ) Linking sumtest ... keith@sugarglider:~/temp/> ./sumtest Stack space overflow: current size 8388608 bytes. Use `+RTS -Ksize' to increase it. keith@sugarglider:~/temp/> rm sumtest.hi sumtest.o sumtest keith@sugarglider:~/temp/> ghc --make -O2 sumtest.hs [1 of 1] Compiling Main ( sumtest.hs, sumtest.o ) Linking sumtest ... keith@sugarglider:~/temp/> ./sumtest 500000500000 keith@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 Stewart 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 .. 1000000] *** Exception: stack overflow

It is strict when subject to strictness analysis (try compiling it).

-- Don

-- keithsheppard.name

Don Stewart

3:18 a.m.

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

Henning Thielemann

11:18 a.m.

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.

Thomas Davie

11:31 a.m.

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

Don Stewart

3:36 p.m.

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

Yitzchak Gale

17 Jun 17 Jun

8:38 a.m.

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

Henk-Jan van Tuyl

11:07 a.m.

On Wed, 17 Jun 2009 10:38:23 +0200, Yitzchak Gale 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 .. 999999] 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/ --

Bulat Ziganshin

11:15 a.m.

New subject: Re[2]: 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, Bulat mailto:Bulat.Ziganshin@gmail.com

Max Rabkin

11:25 a.m.

On Wed, Jun 17, 2009 at 1:07 PM, Henk-Jan van Tuyl wrote:

...

On Wed, 17 Jun 2009 10:38:23 +0200, Yitzchak Gale 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

Yitzchak Gale

11:32 a.m.

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

Thomas Davie

3:15 p.m.

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

Keith Sheppard

7:50 p.m.

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 Davie 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

Lennart Augustsson

8:05 p.m.

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 Sheppard 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 Davie 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

Keith Sheppard

9:05 p.m.

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 Augustsson 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 Sheppard 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 Davie 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

Lennart Augustsson

10:32 p.m.

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 Sheppard 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 Augustsson 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 Sheppard 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 Davie 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

Keith Sheppard

18 Jun 18 Jun

11:29 a.m.

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 Augustsson 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 Sheppard 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 Augustsson 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 Sheppard 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 Davie 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

Thomas Davie

11:53 a.m.

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 Augustsson 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 Sheppard 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 Augustsson 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 Sheppard 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 Davie 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

Gleb Alexeyev

1:14 p.m.

Thomas Davie 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.

But lazy sum should have beed defined in terms of foldr, not foldl. And foldl is not strict enough for strict sum. Therefore the current choice in the worst of both worlds.

Edward Kmett

2:21 p.m.

On Thu, Jun 18, 2009 at 9:14 AM, Gleb Alexeyev wrote:

...

Thomas Davie 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.

But lazy sum should have beed defined in terms of foldr, not foldl. And foldl is not strict enough for strict sum. Therefore the current choice in the worst of both worlds.

I definitely agree with that sentiment. -Edward Kmett

Keith Sheppard

1:31 p.m.

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 Davie 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 Augustsson 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 Sheppard 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 Augustsson 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 Sheppard 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 Davie 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

Henk-Jan van Tuyl

17 Jun 17 Jun

4:22 p.m.

On Wed, 17 Jun 2009 13:32:40 +0200, Yitzchak Gale wrote:

...

Henk-Jan van Tuyl wrote:

...
reverse maximum minimum

Oh yes, please fix those also!

maximum' = foldl' max 0 [1 .. 999999] minimum' = foldl' min 0 [1 .. 999999]

...

...
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 ..] 1000000 Hugs> head $ drop (10 ^ 6) [1 ..] 1000001 Hugs> head . snd $ splitAt (10 ^ 6) [1 ..] 1000001 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 ..] 1000000 Prelude> head $ drop (10 ^ 6) [1 ..] 1000001 Prelude> head . snd $ splitAt (10 ^ 6) [1 ..] 1000001 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/ --

Henk-Jan van Tuyl

6:07 p.m.

On Wed, 17 Jun 2009 18:22:51 +0200, Henk-Jan van Tuyl wrote:

...

On Wed, 17 Jun 2009 13:32:40 +0200, Yitzchak Gale wrote:

...
Henk-Jan van Tuyl wrote:

...
reverse maximum minimum

Oh yes, please fix those also!

maximum' = foldl' max 0 [1 .. 999999] minimum' = foldl' min 0 [1 .. 999999]

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/ --

Keith Sheppard

16 Jun 16 Jun

1:02 a.m.

I just realized... that was a statement not a question :-) anyway, thanks Keith On Mon, Jun 15, 2009 at 11:14 AM, Don Stewart 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 .. 1000000] *** Exception: stack overflow

It is strict when subject to strictness analysis (try compiling it).

-- Don

-- keithsheppard.name

6043

Age (days ago)

6048

Last active (days ago)

List overview

Download

37 comments

19 participants

participants (19)

Bulat Ziganshin
Claus Reinke
Conal Elliott
Daniel Fischer
Deniz Dogan
Don Stewart
Edward Kmett
Gleb Alexeyev
Henk-Jan van Tuyl
Henning Thielemann
Jake McArthur
Jochem Berndsen
Keith Sheppard
Lennart Augustsson
Max Rabkin
Roman Cheplyaka
Stephan Friedrichs
Thomas Davie
Yitzchak Gale