instance visibility
Simon Marlow
marlowsd at gmail.com
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:
>>>
>>> http://bugs.darcs.net/issue387
>> 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
http://hackage.haskell.org/trac/ghc/ticket/1171
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.
Cheers,
Simon
More information about the Libraries
mailing list