未使用DuplicateRecordFields扩展的代码在启用该扩展后是否兼容？

你问到点子上了——虽然Haskell的扩展大多是opt-in（需要显式启用）的设计，但确实存在一些扩展，会改变核心语法或语义规则，导致原本完全合法、能正常编译的代码，在启用该扩展后编译失败。下面举几个典型的例子：

• OverloadedLists
  这个扩展让列表字面量[x,y,z]不再默认绑定到Haskell原生的[]（列表）类型，而是可以匹配任何实现了IsList类型类的类型。比如，假设你有一段无类型注解的代码：

  main = print [1,2,3]
  

  未启用扩展时，编译器会默认[1,2,3]是[Int]类型，完全能正常编译运行。但如果启用了OverloadedLists，同时你的代码中存在另一个实现了IsList的自定义类型（比如data MyVec a = MyVec [a] deriving (IsList, Show)），编译器会因为无法推断[1,2,3]的具体类型而抛出歧义错误，导致编译失败。

• ApplicativeDo
  这个扩展会优化do表达式的解析，优先尝试用Applicative的规则来推导，而不是默认的Monad绑定。如果你的代码依赖一个仅实现了Monad实例、未实现Applicative实例的自定义类型（虽然现代Haskell推荐Monad必须基于Applicative，但旧代码可能存在这种情况），那么启用ApplicativeDo后，原本能正常编译的do表达式会因为找不到Applicative实例而报错，而未启用时只需要Monad实例就能正常编译。

• NoImplicitPrelude
  这个扩展会禁用Prelude模块的默认导入——Prelude包含了Haskell最常用的基础函数（比如print、map、(++)）。比如这段最简单的代码：

  main = print "Hello"
  

  未启用扩展时完全没问题，但启用NoImplicitPrelude后，编译器会报错说print不在作用域内，因为Prelude没有被自动导入了。

需要注意的是，这类破坏兼容性的扩展大多是改变默认行为或者扩展语法边界的类型，而大部分扩展（比如RecordWildCards、PatternSynonyms）都是在原有语法基础上添加新特性，不会影响原有合法代码的编译。

内容的提问来源于stack exchange，提问作者sandwood