Prelude.catch vs. Exception.catch

[Simon Marlow]

> >This is bizarre: the definition of evaluate in Exception is=20
> exactly the
> >one you gave above, yet they behave differently.  You may=20
> have uncovered
> >a compiler bug, I'll look into it.
>=20
> I might ask which is correct: according to the rules for seq,=20
> "evaluate'=20
> undefined" should be bottom, but we want "Expression.evaluate=20
> undefined"=20
> to be a failing IO action.
>=20
> I think the compiler is correct but the definition given in the=20
> documentation is wrong.

Well, given the compiler is compiling the definition from the
documentation and giving the wrong semantics, I'd say the compiler is
definitely wrong :-)

But the question of whether Exception.evaluate should have a different
semantics is interesting.  So to be clear about this, there are three
possible definitions of evaluate:

  evaluate a =3D return a                        -- not strict enough
  evaluate a =3D a `seq` return a                -- too strict (?)
  evaluate a =3D IO $ \s -> a `seq` (# s, a #)   -- just right :)

I had to write out the third one in full, because we don't have any
combinators that provide this functionality elsewhere (at least, I can't
think of any).

I must admit I can't think of any compelling reasons for the change,
other than the fact that this is functionality that we don't have at the
moment, and therefore might be useful.  Opinions?

Cheers,
	Simon