instance visibility

Simon Marlow marlowsd at
Tue Sep 30 05:50:59 EDT 2008

David Roundy wrote:
> On Wed, Sep 24, 2008 at 07:48:06PM +0100, Simon Marlow wrote:
>> David Roundy wrote:
>>> In the interest of providing a concrete example, see the darcs bug:
>> Nice motivation for wanting to *not* import an instance.
>> The first thing that occurs to me is to avoid using UserError - is that
>> feasible?
> It's feasible, but extremely ugly, and it seems almost impossible to
> audit the code for this, as we'd have to look at every instance of
> fail to see if it might happen to be used in the IO monad.  And, of
> course, we'd have to write our own version of error.  Either of these
> sounds very tricky.  fail is a great function (albeit much maligned),
> and I'd hate to have to replace it throughout the code.
> Now, if we could avoid importing the Monad instance of IO from the
> Prelude, then we could write our own instance that would have a fail
> such as
> fail = throw . AssertionFailed

I'd strongly urge you *not* to use error (or anything with value _|_) for 
reporting errors to the user.  The reason being that GHC (or indeed 
Haskell) doesn't guarantee that your program will report the error message 
that you think it will - all it guarantees is that you'll get *some* error 
message.  As GHC gets more clever, we're seeing more an more cases of this. 
  If GHC can prove that your program has value _|_, then it is free to 
explore different orders of evaluation that also produce _|_ and pick one 
of them.  See

now GHC doesn't follow the imprecise exception semantics as described in 
the paper, but that is because the semantics in the paper isn't liberal 
enough (in our opinion).

Of course it's fine to use error for things that are bugs in your program, 
and perhaps that's the way it's used in darcs.


More information about the Libraries mailing list