7

私は自分のカバール プロジェクトでこの種のプラグマを頻繁に使用して、特定のオプションで GHC を強制的にビルドすることに気付きました。

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

しかし、他の人が拡張機能を使用しているのを見ると、常に次のように宣言しています。

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

しかし、後者の方法を使用する GHCi にファイルをロードすると、GHC は常に を使用していると不平を言いunrecognised pragma、すぐに失敗します。

LANGUAGEGHC がプラグマを受け入れないのはなぜですか? 2 つのうちどちらがより適切な方法ですか?

注: GHC のバージョンは最新の 7.8.3 ですが、これが発生したときは 7.6.* でした。

4

1 に答える 1

12

LANGUAGEプラグマを使用する方が優れています。任意のオプションのリストを提供する代わりに、言語拡張のみに固有です。また、GHC ドキュメントに記載されているように、実装間で移植できるように設計されています。LANGUAGE

…移植可能な方法で言語拡張機能を有効にできます。LANGUAGEもちろん、すべての拡張機能がすべてのコンパイラでサポートされているわけではありませんが、すべての Haskell コンパイラが同じ構文でプラグマをサポートすることが意図されています。可能であれば、のLANGUAGE代わりにプラグマを使用する必要があります。OPTIONS_GHC【強調追加】

この同じ言語は、GHC 6.6 (§7.10.4)LANGUAGEが導入されたときから、現在の (執筆時点での) リリースであるGHC 7.10.1 (§7.22.1) までずっとドキュメントに表示されます。

言語拡張機能を指定する 3 つ目の方法は、cabal ファイルで宣言することです。

LANGUAGEまた、プラグマを使用して単一のファイルに使用される拡張子を宣言するのが一般的であることもわかりましたが、 OPTIONS_GHC(単一のファイルのレベルで) を使用することは通常、回避策として使用されます (たとえば、いくつかの警告を無効にするため)。GHC オプションは、個々のファイルではなく、プロジェクト全体 (cabal を使用) で宣言することを好みますが、何らかの理由で、言語拡張はファイルごとに使用されることがよくあります。

LANGUAGEプラグマが認識されない可能性がある理由を以下に示します。

  • 古い GHC バージョン (< 6.6) を使用している
  • ファイル ヘッダープラグマとして宣言しません。ファイル ヘッダー プラグマはmodule、ファイル内のキーワードの前にある必要があります。つまり、ファイルの一番上にある必要があります (ただし、他のファイル ヘッダー プラグマが前にある場合があります)。
于 2015-04-18T18:12:08.727 に答える