5

関数の依存関係を使用すると、頻繁にCoverage Conditionにヒットします。で持ち上げることは可能ですUndecidableInstancesが、私は通常、その延長から離れるようにしています.

これは、なしで動作するやや不自然な例ですUndecidableInstances。

{-# Language MultiParamTypeClasses, FunctionalDependencies, FlexibleInstances #-}

data Result = Result String
  deriving (Eq, Show)

data Arguments a b = Arguments a b

class Applyable a b | a -> b where
  apply :: a -> b -> Result

instance Applyable (Arguments a b) (a -> b -> Result) where
  (Arguments a b) `apply` f = f a b

結果の型をより一般的なものにすると、カバレッジ条件が失敗します (したがって が必要UndecidableInstancesです)。

{-# Language MultiParamTypeClasses, FunctionalDependencies, FlexibleInstances, UndecidableInstances #-}

data Result a = Result a
  deriving (Eq, Show)

data Arguments a b = Arguments a b

class Applyable a b c | a -> b c where
  apply :: a -> b -> Result c

instance Applyable (Arguments a b) (a -> b -> Result c) c where
  (Arguments a b) `apply` f = f a b

bとcはどちらも によって決定されるaため、より一般的なコードは問題を引き起こさないはずだと考えたので、私の質問:

  1. UndecidableInstancesここでの使用に問題はありますか
  2. 依存せずに上記のシナリオをモデル化できますかUndecidableInstances(おそらく型ファミリを使用しますか?)
4

1 に答える 1

7

を遠ざける大きな理由はありませんUndecidableInstances。起こりうる最悪の事態は、型チェッカーがループを開始することです (そして、それについて教えてくれると思います)。カバレッジ条件をより巧妙にすることはできますが、決定できないため、必要なすべてを実行することはできません。

于 2012-03-21T08:37:39.813 に答える