【问题标题】:Haskell pragmas: OPTIONS_GHC vs LANGUAGEHaskell 编译指示:OPTIONS_GHC 与 LANGUAGE
【发布时间】:2015-04-18 17:59:17
【问题描述】:

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

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

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

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

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

为什么 GHC 不接受LANGUAGE pragma,两者哪个更好?


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

【问题讨论】:

  • 哪个 GHC 版本?也许你有一个很老的?还请注意在启用 CPP 时使用 # 作为行的第一个字符(在这种情况下,在此之前添加一个空格)。
  • 远射,但是您运行的是哪个版本的 GHC? (在你的 shell 中运行 ghc --version 来找出答案。)
  • 很好奇。您能否显示给出此错误的整个文件?
  • LANGUAGE 编译指示从 6.8.1 开始工作。我真的认为我们需要一个完整的文件来查看问题所在。
  • @AJFarmar 嗯。可能不是这样。如果您将 pragma 放在 module 声明之后,则不会出现错误,但 GHC 只会将其视为注释(7.8.4)。

标签: haskell language-extension


【解决方案1】:

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

...允许以可移植的方式启用语言扩展。目的是所有 Haskell 编译器都支持具有相同语法的 LANGUAGE pragma,当然,并非所有编译器都支持所有扩展。 如果可能,应使用LANGUAGE 杂注而不是OPTIONS_GHC [强调添加]

GHC 6.6 (§7.10.4) 引入LANGUAGEGHC 7.10.1 (§7.22.1)(在撰写本文时)当前版本,文档中都出现了相同的语言。

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

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

下面是一些疯狂的猜测,为什么LANGUAGE pragma 可能无法被识别:

  • 你有一个古老的 GHC 版本 (
  • 您没有将其声明为 file-header pragma。 文件头编译指示必须在文件中的 module 关键字之前。换句话说,它应该位于文件的最顶部(尽管它之前可能有其他文件头编译指示)

【讨论】:

  • 如果有人有更多猜测可能无法识别编译指示的原因,请将它们添加到列表中(供后代使用)
  • LANGUAGE 扩展名通常是每个文件的原因是为了确保阅读文件的任何人都知道正在播放哪些扩展名。很高兴知道GeneralizedNewtypeDerivingOverlappingInstancesIncoherentInstancesMonoLocalBindsScopedTypeVariablesDataKinds 和/或PolyKinds 是否在起作用,而这些(至少)可能并不完全从源代码的其余部分显而易见。
猜你喜欢
  • 1970-01-01
  • 2011-04-27
  • 1970-01-01
  • 1970-01-01
  • 2018-04-03
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多