On Thurs, Jul 26, 2018 at 05:39:00, Emil Axelsson wrote:

>> Den 2018-07-26 kl. 01:02, skrev Anthony Clayden:

>>
 >>>
* On Tue, Jul 24, 2018 at 5:52 AM,Ryan Reich wrote:
*>*>> This seems like the canonical illustration of the dangers of
*
>>>* UndecidableInstances.*
>>
>>* No I don't buy that explanation. The worst UndecidableInstances can do *
>>* is send the type checker into a loop.*

> I used to have a counter-example to that claim:

https://mail.haskell.org/pipermail/haskell-cafe/2010-January/072357.html

> That example was causing looping dictionaries at run time on GHC 6.10.
> But now, on GHC 8.2, the program terminates.

6.10 was rather a long time ago. The whole type inference/improvement
engine has had several overhauls since 2010.

To be clear: you can write looping programs without type classes at
all -- such as mutually recursive functions. You can write looping
programs with type classes -- by turning those functions into methods
in classes. You can write looping programs with type classes that need
`UndecidableInstances` -- by making those classes mutual superclasses
or mutual constraints on instances.

That doesn't mean the `UndecidableInstances` are to 'blame' for the
looping. I would blame the functions/method calls for not reducing the
problem.


> But one wonders if there are other ways to create looping dictionaries?

With `UndecidableInstances`, yes there's plenty. And I expect that'll
make the typechecker loop at compile time.

The O.P. here is not getting typechecker looping, so I think the
explanation is to do with method calls -- for which we need to see
what's going on in the imports.

AntC