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