View source for Laziness is not always good

Generally, since Haskell is a [[Non-strict_semantics|non-strict]] language, you should try to make a function [[maintaining laziness|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 <hask>Monoid</hask> instance of the null type <hask>()</hask>:
<haskell>
mempty = ()
mappend _ _ = ()
</haskell>
These functions are least strict, but have a subtle problem:
They do not generally satisfy the monoid laws.
Remind you: <hask>mempty</hask> must be the identity element with respect to <hask>mappend</hask>:
<haskell>
forall a. mappend mempty a = a
forall a. mappend a mempty = a
</haskell>
You find that it is not <hask>mappend mempty undefined = undefined</hask>, but <hask>mappend mempty undefined = mempty</hask>.
Is this academic nitpicking or practically relevant?
I think it is the latter one, because a <hask>Monoid</hask> instance implicitly promises that monoid laws can be applied in every case.
A programmer expects that every occurence of <hask>mappend mempty a</hask> can be safely replaced by <hask>a</hask>.
You might even create an [[Playing by the rules|optimizer rule]] doing this.
The above implementation of <hask>mappend</hask> however evaluates its operands lazily, and this gets lost when the optimization is applied.

The solution of this issue is to define
<haskell>
mempty = ()
mappend () () = ()

force :: () -> ()
force _ = ()
</haskell>
and write
<haskell>
mappend (force a) (force b)
</haskell>
instead of <hask>mappend a b</hask>.

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

== Exercise ==

Find out whether it would help to define <hask>mempty = undefined</hask>.

== See also ==

* Haskell-Cafe on [http://www.haskell.org/pipermail/haskell-cafe/2009-January/054261.html Laws and partial values]
* Haskell-Cafe on a space leak caused by [http://www.haskell.org/pipermail/haskell-cafe/2010-June/079444.html the garbage collector that did not recognize a selector-like function call]
* [[Maintaining laziness]]
* Amanda Clare has written a paper on various methods for twisting the evaluation order: http://users.aber.ac.uk/afc/stricthaskell.html.


[[Category:Idioms]]
[[Category:Style]]