Laziness is not always good

From HaskellWiki
Revision as of 20:18, 30 January 2009 by Lemming (talk | contribs) (first draft)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Generally, since Haskell is a non-strict language, one should try to make a function least strict. This is in many cases the best semantics and the most efficient implementation. However, here is an important exception from the rule: Consider the Monoid instance of the null type ():

mempty = ()
mappend _ _ = ()

These functions are least strict, but have a subtle problem: They do not generally satisfy the monoid laws. Remind you: mempty must be the identity element with respect to mappend:

forall a. mappend mempty a = a
forall a. mappend a mempty = a

You find that it is not mappend mempty undefined = undefined, but mappend mempty undefined = mempty. Is this academic nitpicking or practically relevant? I think it is the latter one, because a Monoid instance implicitly promises that monoid laws can be applied in every case. A programmer expects that every occurence of mappend mempty a can be safely replaced by a. You might even create an optimizer rule doing this. The above implementation of mappend however evaluates its operands lazily, and this gets lost when the optimization is applied.

The solution to this to define

mempty = ()
mappend () () = ()

force :: () -> ()
force _ = ()

and write

mappend (force a) (force b)

instead of mappend a b.

If you find that example too academic, you can choose any other data type with one constructor instead.

See also