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<lenn...@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
Sheppard<keiths...@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
Augustsson<lenn...@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
Sheppard<keiths...@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
Davie<tom.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
