Re: [Haskell-cafe] Why does this result in a runtime loop instead of a type error or typechecker loop?

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. For mutually recursive functions to cause looping, you don't need classes at all: foo :: Bool -> () foo x = bar x bar :: () -> Bool bar x = foo x No typechecking will detect that loop. This `HasBool` example is just an obfuscated way to write that loop(?) There's some odd thigs in the OP: Why use OVERLAPPABLE? Neither of those instances need it. Or are there more instances in the imports? (There must at least be the definition for class `Has`.) If so, what are their constraints? And what are their implementations? Perhaps that's causing the looping? Will `runRIO` or `view` use one of those other instances? What does this mean: "I can compile an equivalent program; it loops on execution."? There doesn't need to be a `Bool` in the "environment": the `HasBool a` instance introduces `Bool` in its constraint. I suggest boiling this down to a stand-alone program not needing imports. Then tell the whole story. AntC On Mon, Jul 23, 2018 at 2:10 PM, Theodore Lief Gannon < tanuki at gmail.com http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe> wrote:
* λ. :set -XFlexibleContexts -XFlexibleInstances -XMultiParamTypeClasses *>* -XUndecidableInstances *>* λ. import RIO *>* λ. import Data.Has *>* λ. class HasBool a where boolL :: Lens' a Bool *>* λ. instance {-#OVERLAPPABLE#-} HasBool a => Has Bool a where hasLens = *>* boolL *>* λ. instance {-#OVERLAPPABLE#-} Has Bool a => HasBool a where boolL = *>* hasLens *>* λ. runRIO () $ view boolL *>* ^CInterrupted. *>>* The RIO environment () doesn't contain a Bool. I can see how the *>* typechecker might get lost in this, but I can compile an equivalent *>* program; it loops on execution. *>>* _______________________________________________ *>* Haskell-Cafe mailing list *>* To (un)subscribe, modify options or view archives go to: *>* http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe *>* Only members subscribed via the mailman list are allowed to post. *>

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. But one wonders if there are other ways to create looping dictionaries? / Emil
participants (2)
-
Anthony Clayden
-
Emil Axelsson