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
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
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
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
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
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
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
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
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,
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'
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
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
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.
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
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 (+)
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
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
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.
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
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 ...
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]
***
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
___
* 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
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
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),
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
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
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
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
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
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:
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]
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]
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
34 matches
Mail list logo
