Does Haskell optimizer utilize memoization for repeated function calls in a scope?

Question

Consider this function:

f as = if length as > 100 then length as else 100

Since the function is pure it\'s obvious that the length will

Answer 1

The case you are describing has more to do with common subexpression elimination than memoization, however it seems that GHC currently doesn't do that either because unintended sharing might lead to space leaks.

Answer 2

GHC now does some CSE by default, as the -fcse flag is on.

On by default.. Enables the common-sub-expression elimination optimisation. Switching this off can be useful if you have some unsafePerformIO expressions that you don't want commoned-up.

However, it is conservative, due to the problems with introducing sharing (and thus space leaks). The CSE pass is getting a bit better though (and this).

Finally, note there is a plugin for full CSE.

• http://hackage.haskell.org/package/cse-ghc-plugin

If you have code that could benefit from that.

Answer 3

Even in such a local setting, it is still the case that it is not obvious that the introduction of sharing is always an optimization. Consider this example definition

f = if length [1 .. 1000000] > 0 then head [1 .. 1000000] else 0

vs. this one

f = let xs = [1 .. 1000000] in if length xs > 0 then head xs else 0

and you'll find that in this case, the first behaves much better, as each of the computations performed on the list is cheap, whereas the second version will cause the list to be unfolded completely in memory by length, and it can only be discarded after head has been reduced.