"Ch. A. Herrmann" wrote:
>
> Hi Haskellers,
>
> which compiler settings do I have to pass to ghc-5.02
> in order to achieve that the strictness analyzer
> recognizes strictness of (+) in foldl and computes
> sum in constant space?
>
> Prelude> sum [1.
| > Prelude> sum [1..1000]
| >
| > had the following effect:
| >
| > PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
| > 23542 herrmann 20 0 250M 130M 97500 R66.3 52.4 0:21
ghc-5.02
|
| Is this what I think it is? Do you benchmark the
| interpreter? Interpr
not really. I wanted to have a strict foldl (for a different purpose
than sum) and could not figure out how to tell the compiler.
I tried different things, precompile just one module, compile
the entire program, using -fglasgow-exts, but nothing seems to work.
Thus, I reduced the problem to sum to
Hal Daume III <[EMAIL PROTECTED]> wrote,
> > Is this what I think it is? Do you benchmark the
> > interpreter? Interpreted code isn't optimised. When I
> > compile
> >
> > main = print $ sum [1..1000]
> >
> > with -O2, it takes 13s on a 600MHz P3 and runs in 1.5MB of
> > space.
>
> O
Hi,
> Is this what I think it is? Do you benchmark the
> interpreter? Interpreted code isn't optimised. When I
> compile
>
> main = print $ sum [1..1000]
>
> with -O2, it takes 13s on a 600MHz P3 and runs in 1.5MB of
> space.
Out of curiousity, why doesn't this get compiled down to
"Ch. A. Herrmann" <[EMAIL PROTECTED]> wrote,
> which compiler settings do I have to pass to ghc-5.02
> in order to achieve that the strictness analyzer
> recognizes strictness of (+) in foldl and computes
> sum in constant space?
>
> Prelude> sum [1..10
Hi Haskellers,
which compiler settings do I have to pass to ghc-5.02
in order to achieve that the strictness analyzer
recognizes strictness of (+) in foldl and computes
sum in constant space?
Prelude> sum [1..1000]
had the following effect:
PID USER PRI NI SIZE RSS SHARE S
Unless I'm mistaken, foldl' (the strict version of foldl)
doesn't appear in (the export list of) the standard prelude
or the list library.
Is there a good reason for this? New users quite quickly
find that they need it.
Jón
--
Jón Fairbairn [
I know it's complete heresy to say so, but I use laziness very
little in Haskell, while I probably pay quite a lot for it
in CPU time and memory, because of all those thunks which have to be
stored. However I prefer Haskell's type classes, syntax and
purity to, say, Standard ML. So I wonder whet
"C.Reinke" <[EMAIL PROTECTED]> writes:
> So foldl is indeed tail recursive, but this doesn't help if its
> operator isn't strict because the tail recursion only builds up the
> expression to be evaluated. Making strictness explicit by defining a
> variant o
"Julian Assange" <[EMAIL PROTECTED]>:
> ..
> | When used with a 170k input file, makemap suffers from a stack
> | overflow. foldl should be tail recursive. What's the score?
"Simon Peyton-Jones" <[EMAIL PROTECTED]>:
> Consider
>
functions (foldr, foldl, zip,
union, etc) in terms of foldl or foldr in really, as shown in a previous
post, this is horribly inefficient. It seams like my Generator concept,
which I just posted 2 days ago, would be a good way to go because GHC is
able to optimize away any garbage collection when
Kevin Atkinson wrote:
>
> Even though it is possible to define foldl with foldr or vis versa it
> (with the current implantation of Haskell with ghc) not nearly as
> efficient. To demonstrate this consider folding of a range.
>
> import System
>
> foldR f i (a,z) =
Even though it is possible to define foldl with foldr or vis versa it
(with the current implantation of Haskell with ghc) not nearly as
efficient. To demonstrate this consider folding of a range.
import System
foldR f i (a,z) = g a
where g a | a == z= i
| otherwise = f a
S. Alexander Jacobson <[EMAIL PROTECTED]> wrote
(sorry, i do not remember, to which of the Haskell lists)
> Wow! If Ralf is right, then foldl in a lazy language always generates
> a space leak and should be avoided in favor of strictFoldl.
> ...
There were other letters o
Please, could anybody explain me what the rationale behind the current
foldM in Monad? At least of the IO monad, it seems important to have
a left associative fold instead of the right associative foldM.
Adding to my confusion, it seems that earlier in time, there was
indeed two monad fold's inst
16 matches
Mail list logo
