You can't rely on adding dummy arguments to cause re-evaluation: full-laziness (enabled when optimisation is on in GHC) will do the opposite transformation.
Well in this case, you may find it harder to claim that the full laziness transformation constitutes an `optimisation'. Maybe the GHC manual should have a section on "Flags for worsening the space behaviour of programs". :-)
Seriously, would it be difficult to detect when performing this `optimisation' would introduce a CAF and perhaps back it out appropriately?
The problem isn't restricted to CAFs - full laziness always trades space for time. We found that it can be a large win in some cases: if repeated computation is replaced by sharing in an inner loop, then the gains can be dramatic. We didn't meet any cases where it caused space problems, so you get it by default[1] when optimisation is turned on in GHC. You can always disable it with -fno-full-laziness. Cheers, Simon [1] Actually what you get is almost-full-laziness: GHC won't split adjacent lambda abstractions if it finds it can float an expression past some of the lambdas but not all.