haskell – 如何在不使用-XUndecidableInstances的情况下绕过功能依赖的覆盖条件

Wen使用函数依赖,我经常达到Coverage条件.可以使用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

当我使结果类型更通用时,Coverage条件失败(因此需要UndecidableInstances):

{-# Language MultiParamTypeClasses,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没有什么大的理由.可能发生的最糟糕的情况是类型检查器开始循环(并且我认为它告诉你它).你可以使覆盖条件越来越聪明,但它永远不会做你想要的一切,因为那是不可判定的.

相关文章

迭代器模式(Iterator)迭代器模式(Iterator)[Cursor]意图...
高性能IO模型浅析服务器端编程经常需要构造高性能的IO模型,...
策略模式(Strategy)策略模式(Strategy)[Policy]意图:定...
访问者模式(Visitor)访问者模式(Visitor)意图:表示一个...
命令模式(Command)命令模式(Command)[Action/Transactio...
生成器模式(Builder)生成器模式(Builder)意图:将一个对...