# Laziness is not always good

### From HaskellWiki

Generally, since Haskell is a non-strict language, you 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 theMonoid

()

mempty = () mappend _ _ = ()

These functions are least strict, but have a subtle problem: They do not generally satisfy the monoid laws.

Remind you:mempty

mappend

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

mappend mempty undefined = undefined

mappend mempty undefined = mempty

Is this academic nitpicking or practically relevant?

I think it is the latter one, because aMonoid

mappend mempty a

a

You might even create an optimizer rule doing this.

The above implementation ofmappend

The solution of this issue is to define

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

and write

mappend (force a) (force b)

mappend a b

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

## 1 Exercise

Find out whether it would help to definemempty = undefined

## 2 See also

- Haskell-Cafe on Laws and partial values
- Haskell-Cafe on a space leak caused by the garbage collector that did not recognize a selector-like function call
- Maintaining laziness