Running out of memory in a simple monad

[Simon Marlow]

> 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).
>=20
> 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=20
> examples like
>=20
>   module Main(main,primes) where
>=20
>   main =3D print primes
>   primes =3D ...
>=20
> leak space?

Actually CAF reverting only applies to CAFs in compiled code at the
moment, and it happens after evaluation, not during it.  The primes
example will leak in GHCi (not in plain GHC, though).

I guess the right thing to do is to revert them as soon as they're found
to be unreferenced, but that's hard - the compiler's symbol table refers
to all the top-level bindings, so it would probably have to use weak
pointers.

The CAF reverting feature was added mainly so that you can recover from
doing hGetContents on stdout.

Cheers,
	Simon