gpt4 book ai didi

Haskell 编译指示 : OPTIONS_GHC vs LANGUAGE

转载 作者:行者123 更新时间:2023-12-04 10:36:54 25 4
gpt4 key购买 nike

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

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

但是当我看到其他人使用扩展时,他们总是这样声明:
{-# LANGUAGE FlexibleInstances, RankNTypes, ... #-}

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

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

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

最佳答案

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

…allows language extensions to be enabled in a portable way. It is the intention that all Haskell compilers support the LANGUAGE pragma with the same syntax, although not all extensions are supported by all compilers, of course. The LANGUAGE pragma should be used instead of OPTIONS_GHC, if possible. [Emphasis added]



GHC 6.6 (§7.10.4) 开始,文档中都出现了相同的语言。 , 当 LANGUAGE介绍,直到 GHC 7.10.1 (§7.22.1) ,当前(在撰写本文时)版本。

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

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

这里有一些疯狂的猜测,为什么 LANGUAGE编译指示可能无法被识别:
  • 你有一个古老的 GHC 版本 (< 6.6)
  • 您没有将其声明为文件头编译指示。
    文件头编译指示必须在 module 之前。文件中的关键字。换句话说,它应该在文件的最顶部(尽管它之前可能有其他文件头编译指示)
  • 关于Haskell 编译指示 : OPTIONS_GHC vs LANGUAGE,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/29720851/

    25 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com