如何解决函数依赖的覆盖条件而不使用-XUndecidableInstances

问题描述：

Wen使用函数依赖关系时，我经常碰到覆盖条件。可以用UndecidableInstances来解除它，但我通常尽量远离那个扩展。如何解决函数依赖的覆盖条件而不使用-XUndecidableInstances

这里是一个有些人为的例子，在不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决定的，所以更通用的代码不应该引起任何问题，所以我的问题：

是否有使用UndecidableInstances这里
我可以在上面的场景模拟任何可能出现的问题，而不依赖于UndecidableInstances（可能与类型的家庭？）

没有什么大的理由远离'UndecidableInstances'。可能发生的最糟糕的事情是类型检查器开始循环（并且告诉你这个问题，我想）。你可以使覆盖条件变得越来越聪明，但它不会做你想做的所有事情，因为这是不可判定的。 – augustss 2012-01-31 08:29:10

c在这里如何确定？ – Saizan 2012-02-19 21:54:40

答

有没有很大的原因来自UndecidableInstances远离。可能发生的最糟糕的事情是类型检查器开始循环（并且告诉你这个问题，我想）。你可以使覆盖条件变得越来越聪明，但它不会做你想做的所有事情，因为这是不可判定的。

如何解决函数依赖的覆盖条件而不使用-XUndecidableInstances

相关推荐