[Haskell-cafe] Why does this result in a runtime loop instead of a type error or typechecker loop?
Anthony Clayden
anthony_clayden at clear.net.nz
Thu Jul 26 22:31:03 UTC 2018
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180727/40dd412e/attachment.html>
More information about the Haskell-Cafe
mailing list