Even in unoptimized, byte-code compiled code?

Take this module:

module A where

t :: IO () t = sequence_ (repeat (return ()))

If I :load it into ghci as interpreted, or if I compile it without optimisation options, and I run t, then the process grows, and grows, and grows, ...

True, GHC does not garbage-collect CAFs when interpreting. This is partly intentional; we provide an option to turn off the behaviour (:set +r) although GHC is currently not capable of garbage collecting CAFs *during* evaluation when interpreting.

Of course, when I first compile it with -O2 option then it runs in constant space.

When I compiled Wojtek's code with -O2, the problem disappeared, so I guess he was loading the module without compiling it with -O2 first.

Shouldn't you rather say: GHC doesn't have CAF leaks in code compiled with [insert the relevand optimisation option here] option?

Just compiling the code (instead of running it in GHCi) is enough to prevent CAFs from leaking. You might get better space behaviour by optimising, however (or you might get worse space behaviour, but that's unlikely). Cheers, Simon