私が最初に深刻なcriticism on -XUndecidableInstancesを読む時までに、私はすでにそれに完全に慣れていました。それは単にという迷惑な制限の削除であると見なされます。Haskell98はコンパイラの実装を容易にする必要があります。。undecidableインスタンスは実際にコンパイラをハングアップさせることができますか？
実際、私は、決定不能なインスタンスが必要だったアプリケーションがたくさん出てきましたが、実際にはそれらがundecidabilityに関係する問題を引き起こしていませんでした。これは実際に国連決定論です：！まあ、これは明らかには、任意の適切なGroupインスタンスによってをオーバーラップされますので、決定不能が私たちの心配の少なくともです - ルカの例では、
class Group g where
(%) :: g -> g -> g
...
instance Num g => Group g where
...
全く異なる理由で問題があります
しかし、私の頭の後ろには、「判読不能なインスタンスがコンパイラーをハングアップする可能性がある」ということがありました。
this challenge on CodeGolf.SEを読むと、コンパイラを無期限にハングするコードを尋ねられました。うーん、うまくいかないインスタンスの仕事のように聞こえるよね？
私は彼らにそれをさせることができません。少なくともGHC-7.10から時間がないの、次のコンパイル、：
{-# LANGUAGE FlexibleInstances, UndecidableInstances #-}
class C y
instance C y => C y
main = return()
私もクラスメソッドを使用することができ、そして、彼らは唯一のランタイムでループを引き起こします：
{-# LANGUAGE FlexibleInstances, UndecidableInstances #-}
class C y where y::y
instance C y => C y where y=z
z :: C y=>y; z=y
main = print (y :: Int)
しかしランタイムループは珍しいことではありません.Haskell98でこれらを簡単にコーディングすることができます。
Iはまた、異なる試み、以下そのような再度
{-# LANGUAGE FlexibleContexts, UndecidableInstances #-}
data A x=A
data B x=B
class C y
instance C (A x) => C (B x)
instance C (B x) => C (A x)
として直接ループ、コンパイル時に問題はありません。
したがって、実際には、コンパイラは、決定不可能な型クラスのインスタンスを解決するためにハングする必要がありますか？
「Int」が 'C'のインスタンスであるかどうかをコンパイラが判断するようにする必要があるかもしれません。 – immibis