在本地使用 UndecidableInstances pragma 是否会对编译终止产生全局影响？答案

【问题标题】：Can using UndecidableInstances pragma locally have global consequences on compilation termination?在本地使用 UndecidableInstances pragma 是否会对编译终止产生全局影响？
【发布时间】：2013-01-23 09:25:59
【问题描述】：

假设 Haskell 库设计者出于某种原因决定使用 UndecidableInstances。该库编译良好。现在假设某个程序使用该库（例如定义其类型类的一些实例），但不使用扩展。会不会编译失败（不终止）？

如果这种情况可能发生，我很乐意看到一个例子。例如，由于mtl 经常使用UndecidableInstances，是否可以编写一个依赖于mtl（或任何其他使用扩展的标准库）的程序，而不使用@987654325 @ 本身，但由于不确定性而无法编译？

【问题讨论】：

标签： haskell compilation ghc language-extension

【解决方案1】：

好问题！

一般来说这当然是可能的。考虑这个模块：

{-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, UndecidableInstances #-}

module M where

class C a b | a -> b where
  f :: a -> b

instance C a b => C [a] [b]
  where f = map f

它自己编译就好了。但是，如果您导入此模块并定义

g x = x + f [x]

你会得到

Context reduction stack overflow; size = 201
Use -fcontext-stack=N to increase stack size to N
  C [b] b
In the second argument of `(+)', namely `f [x]'
In the expression: x + f [x]
In an equation for `g': g x = x + f [x]

关于 mtl 实例，我看不出这样的事情怎么可能，但我也没有证据证明它不是。

【讨论】：

我正在使用您的解决方案，我设法将其缩减为 class C a where f :: a -> a 和 instance C [[a]] => C [a] where f = id，除了 UndecidableInstances 之外不需要任何其他扩展。
经过检查mtl，我相信不可能通过使用它来导致编译器循环。它需要扩展的唯一原因是它的一些实例未能通过Coverage Condition。但是条件背后的想法是满足的——所有的rhs类型变量都可以从mtl的实例声明中推断出来。
嗯，我很惊讶C [[a]] 不需要FlexibleContexts。
确实如此，但似乎UndecidableInstances 暗示FlexibleContexts。