任意の .hs ファイルについて、依存する言語拡張を次のように指定できます。
{-# LANGUAGE Foo, Bar, Baz #-}
cabal 化されたプロジェクトは、.cabal ファイルでプロジェクトごとに言語拡張を指定することもできます。
extensions: Foo, Bar, Baz
これらのうち、「ベスト プラクティス」と見なされるのはどれですか? パッケージがどのコンパイラと互換性があるかを文書化する形式として、使用されているすべての拡張子を .cabal ファイルにリストする必要がありますか? それとも、どのファイルがどの拡張子に依存しているかを明確にするために、すべての拡張子をファイルごとに記録する必要がありますか? 両方の場所で広範囲に文書化するのはどうですか? それとも、ベストプラクティスはその中間ですか?
それは、それらがどれだけ使用されているかによって異なります。プロジェクトのすべてのモジュールで拡張機能を使用する場合は、cabal ファイルに追加することをお勧めします。たとえば、どこでも C プリプロセッサ ディレクティブを使用している場合、フィールドを何度もリストするのではなく、フィールドに配置するだけで意味があり、モジュールに複雑なインスタンス宣言がたくさんある場合は、そこに配置するのが合理的CPPです。 、 それも。extensionsFlexibleInstances
ただし、「危険な」拡張子 ( などUndecidableInstances) や、いくつかの場所でのみ使用される拡張子は、ファイルの先頭に配置する必要があります。拡張機能は分離されているため、別のモジュールで意図していない拡張機能の効果を誤って使用することはありません。
一般的に、私はそれらをファイルの先頭に置く側で誤りを犯しextensions、拡張子を何度も何度も指定するときにのみフィールドを使用するのは面倒です.