# Difference between revisions of "Laziness is not always good"

(exercise) |
m (delete comma splice) |
||

Line 43: | Line 43: | ||

== Exercise == |
== Exercise == |
||

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

== See also == |
== See also == |

## Revision as of 03:08, 9 July 2009

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 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 of this issue is 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.

## Exercise

Find out whether it would help to define `mempty = undefined`

.

## See also

- Haskell-Cafe on Laws and partial values
- Maintaining laziness