The Proper Definition of (evaluate :: a -> IO a)

Isaac Dupree isaacdupree at
Mon May 7 18:57:51 EDT 2007

Hash: SHA1

Malcolm Wallace wrote:
> Nils Anders Danielsson <nad at> wrote:
>>> Where did you find the erroneous version?
>> Presumably he found it by reading the documentation for evaluate:
> Actually, I checked the source code for Control.Exception before asking
> the question, and those laws definitely do not appear there.  So now I'm
> kind of puzzled as to how Haddock managed to generate documentation for
> them!

In the source code, grep found it at the end of

>   (1) That 'evaluate' should _not_ force its argument when it is called,
>       but that rather that the argument should be forced only when the
>       resultant IO action is executed.  This conflicts with the
>       documentation, which implies that the argument is forced _before_
>       the IO action is created or executed.

I didn't think so... though in most cases the IO action is only
scrutinized/created in order to immediately execute it.

> But I guess this semantics
>       accords with Isaac's suggested definition:
>           evaluate x = (x `seq` return x) >>= return

I think evaluate's non-strictness until the IO is executed

is similar to IO's (>>=)'s non-strictness in its first argument (would
there be be any performance consequences to this artificially being
different, in GHC, I wonder?)

except that evaluate is documented, and that behavior has a purpose re:
exceptions considering that evaluate is found in Control.Exception

and I haven't found anything indicating that IO's (>>=) must not be
strict in the first argument, it's just that all implementations seem to
do it that way, so, is my suggested implementation really a good idea?
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


More information about the Libraries mailing list