Another question about sharing

[Simon Marlow]

> > 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.
>=20
> 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".  :-)
>=20
> 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.