<div dir="ltr">I know this is basically a rewording of a previous e-mail, but I realized this is the question I *really* wanted to ask.<br><br>We have this language extension UndecidableInstances (not to mention OverlappingInstances), which seem to divide the Haskell camp into two factions:<br>
<br>* Hey, GHC said to turn on this flag. Ok!<br>* Undecidables are the devil!<br><br>I get the feeling the truth lies in the middle. As I understand it (please correct me if I am wrong), the problem with undecidables is that they can create non-terminating instances. However, for certain cases the programmer should be able to prove to him/herself that the instances will terminate. My question is: how can you make such a proof?<br>
<br>I&#39;ve had to cases in particular that made me want undecidables. Both of them, IMO, could be solved by creating new extensions to GHC which would not require undecidables. Nonetheless, for now we only have undecidables at our disposal. The examples are:<br>
<br>* Context synonyms (eg, MonadFailure = Monad + Failure).<br>* Subclass function defaulting<br><br>For an example of the second, a nifty definition of Monad would be:<br><br>class Applicative m =&gt; Monad m where<br>  &gt;&gt;= ...<br>
  return ...<br>  pure = return<br>  (&lt;*&gt;) = ap<br>  fmap = liftM<br><br>Of course, neither of these is possible in Haskell, so we can use undecidables. How can a programmer prove that a set of instances is, in fact, safe? And if they make a mistake and right a bad set of undecidable/overlapping instances, what&#39;s the worst case scenario? Is it a compile-time or run-time error*?<br>
<br>Michael<br><br>* Yes, I mean error.<br></div>