I've been starting to take note of discussion about space leaks in Haskell. So far, it's not a topic that's bothered me, other than obvious programming errors, and I've never found the need to force strict evaluation of my Haskell programs. I find myself wondering why this is.

Your comment about arithmetic expressions is telling: the kind of program I have been writing (parsers, symbolic processing, etc.) performs almost no arithmetic. (So far, I've used lists instead of arrays, so a usual source of arithmetic functions is missing.)

I've also worked with datasets that fit in memory, so failure to "stream" data hasn't been a problem. I suspect that's the more pernicious case for space leaks, since the causes aren't always so obvious.

Are there any guidelines or warning signs to look out for that may be indicative of potential space-leak problems? So far, I can think of:
- arithmetic results
- multiple uses of a large data value


#g
--

At 00:44 05/10/04 -0700, [EMAIL PROTECTED] wrote:

I added two lines to your code:

iterate2 f x n | seq f $ seq x $ seq n $ False = undefined
iterate2 f x n = --- as before

rk4Next f h (x, y) | seq f $ seq h $ seq x $ seq y $ False = undefined
rk4Next f h (x, y) = -- as before

I also increased ten times the number of steps for the last iteration,
to make the example more illustrative.
   putStr (show (rk4 stiff 0 1 (exp (-1)) 1000000))

The rest of the code is unchanged. The program now runs on GHCi

*Foo> main
Begin
(1.0000000000000007,-6.503275017254139)
(0.9999999999999062,-6.497717470015538)
(1.000000000007918,-6.497716616653335)


on on hugs

Begin
(1.0,-6.50327501725414)
(0.999999999999906,-6.49771747001554)
(1.00000000000792,-6.49771661665334)

with the default stack size for both interpreters. It seems the code
does run in constant space now.

The added lines are meant to turn the relevant functions from lazy to
strict. When you see something like '(n-1)' and 'y + a1/6', it is a
red flag. These are exactly the kinds of expressions that lead to
memory exhaustion. Perhaps it is because the size of an unevaluated
thunk for (n-1) is so much bigger than the size of the evaluated
thunk. It seems that arithmetic expressions are the best candidates
for some opportunistic evaluation...
_______________________________________________
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe

------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

_______________________________________________
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to