RE: Running out of memory in a simple monad
Alastair Reid writes:
The workaround is simple enough: add a dummy argument to the CAF (so that it is not a CAF any more):
main _ = loop 50000
and then specify the extra argument when invoking it:
main ()
(This is a pretty standard optimisation technique: we're trading time to recompute a result for the space taken to store the result. Coming from other languages where actions (i.e., monadic computations) are not first class values, this is a bit surprising but, from a Haskell perspective, it is completely uniform.)
Careful: this isn't guaranteed to turn a CAF into a function. In particular, GHC will "optimise away" this trick when optimisation is turned on (and perhaps even when it isn't). The point is that adding dummy arguments isn't really a technique that should be relied upon. You might well argue that there ought to be a way to control the operational behaviour of the program w.r.t. CAFs (and in fact sharing in general), and I'd be inclined to agree. Also, GHCi retains CAFs in the same way as Hugs, the difference is that GHCi can be configured to throw away the results after evaluation (:set +r). Cheers, Simon
Simon Marlow <simonmar@microsoft.com> writes:
Also, GHCi retains CAFs in the same way as Hugs, the difference is that GHCi can be configured to throw away the results after evaluation (:set +r).
If I set this flag, does GHCi discard CAFs during evaluation or at the end of evaluation? Or, to put it another way, do classic examples like module Main(main,primes) where main = print primes primes = ... leak space? -- Alastair
participants (2)
-
Alastair Reid -
Simon Marlow