<div dir="ltr">Hi all,<br><br>Well, I&#39;ve got two problems which both want to be solved with undecidable and overlapping instances. Obviously, I&#39;d like to try and avoid them. For the record, the problems have to do with the control-monad-failure and convertible packages. The code below *should* make clear what I&#39;m trying to accomplish:<br>
<br>-- failure should not be limited to just monads, so...<br>class Failure e f where<br>    failure :: e -&gt; f v<br>class (Functor f, Failure e f) =&gt; FunctorFailure e f<br>instance (Functor f, Failure e f) =&gt; FunctorFailure e f -- undecidable, overlaps<br>
class (Applicative f, Failure e f) =&gt; ApplicativeFailure e f<br>instance (Applicative f, Failure e f) =&gt; ApplicativeFailure e f -- undecidable, overlaps<br>class (Monad f, Failure e f) =&gt; MonadFailure e f<br>instance (Monad f, Failure e f) =&gt; MonadFailure e f -- undecidable, overlaps<br>
<br>And now the convertible issue. I want two type classes: Convert for anything which *might* be convertible, but might not. For example, sometimes a String can be converted to an Int (like the string &quot;5&quot;), but sometimes it will fail (like &quot;five&quot;). TotalConvert is when something *is* convertible, such as Int to String (simply the show function). Thus the following:<br>
<br>class Convert x y where<br>    convert :: x -&gt; Maybe y<br>class Convert x y =&gt; TotalConvert x y where<br>    totalConvert :: x -&gt; y<br>instance TotalConvert x y =&gt; Convert x y where -- Boom!<br>    convert = Just . totalConvert<br>
<br>Any ideas are most welcome. Both of these seem like cases where the compiler could do some DWIMery, but isn&#39;t.<br><br>Michael<br></div>