7

我发现自己在我的 cabal 项目中经常使用这种 pragma 来强制 GHC 使用特定选项进行构建：

{-# OPTIONS_GHC -XFlexibleInstances -XRankNTypes ... #-}

但是当我看到其他人使用扩展时，他们总是这样声明：

{-# LANGUAGE FlexibleInstances, RankNTypes, ... #-}

但是，当我在使用后一种方法的 GHCi 中加载文件时，GHC 总是抱怨我正在使用 anunrecognised pragma并立即失败。

为什么GHC不接受LANGUAGEpragma，两者哪个更好？

注意：我的 GHC 版本是最新的：7.8.3，但发生这种情况时是 7.6.*。

4

1 回答 1

12

使用LANGUAGE编译指示更好。它没有给出任意选项的列表，而是仅针对语言扩展。如 GHC 文档中所述，它还被设计为在实现之间可移植；LANGUAGE

…允许以可移植的方式启用语言扩展。目的是所有 Haskell 编译器都支持LANGUAGE具有相同语法的 pragma，当然，并非所有编译器都支持所有扩展。如果可能，应使用 pragma 代替。LANGUAGEOPTIONS_GHC[强调补充]

从引入时的GHC 6.6 (§7.10.4)一直到当前（撰写本文时）版本的GHC 7.10.1 (§7.22.1) ，文档中都出现了相同的语言。LANGUAGE

第三种指定语言扩展的方法是在 cabal 文件中声明它们。

我还发现使用LANGUAGEpragma 为单个文件声明使用的扩展名是很常见的，但使用OPTIONS_GHC（在单个文件的级别上）通常用作解决方法（例如禁用某些警告）。人们更喜欢在项目范围内（使用 cabal）而不是在单个文件上声明 GHC 选项，而由于某种原因，语言扩展通常在每个文件的基础上使用。

LANGUAGE以下是一些可能无法识别编译指示的疯狂猜测：

  • 你有一个古老的 GHC 版本 (< 6.6)
  • 您没有将其声明为文件头编译指示。文件头编译指示必须在module文件中的关键字之前。换句话说，它应该位于文件的最顶部（尽管它之前可能有其他文件头编译指示）
于 2015-04-18T18:12:08.727 回答