概要
LANGUAGE プラグマが提供する最低限の保証を記述する。
内容
GHC と Cabal (Language.Haskell.Extension を通じて) では次の二つの目的のために LANGUAGE プラグマを上手く利用して来た。
この提案の目的は、LANGUAGE プラグマが提供する最低限の保証を記述し、Haskell 2010 の実装同士で同じ目的の為に互換性維持に使える事である。
報告の差分
http://www.sampou.org/haskell/report-revised-j/pragmas.html 11 プラグマ にある次の語句を置き換える。
実装は いかなるプラグマも考慮する必要はない。しかし、実装はこれを処理するようになっていないのなら、プラグマを無視しなければならない。
変更後
実装は いかなるプラグマも考慮する必要はなく、実装が対応していないならどのプラグマも無視出来る。しかし、実用上多くの言語拡張が使っているので、実装は下記の LANGUAGE プラグマをサポートするよう強く推奨される。
次のサブセクションを追加
11.3 言語拡張11.3 Language Extensions
LANGUAGE プラグマはファイルヘッダプラグマである。ファイルヘッダプラグマはソースファイルの module キーワードの前に無くてはならない。必要なだけ多くのファイルヘッダプラグマを置く事が出来、前後にコメントがあっても良い。それぞれのプラグマはLANGUAGE キーワードを持ち、コンマで区切られた言語拡張名が続く。
例えば、FFI と CPP によるプリプロセスを有効にするには:
{-# LANGUAGE ForeignFunctionInterface, CPP #-}
もしも Haskell 実装がソースファイルの要求する特定の言語拡張を認識もしくは対応しない(または要求された言語拡張の組み合わせに対応出来ない)なら、どのようなコンパイルの試行または Haskell 実装による利用もエラーと共に失敗しなくてはならない。
互換性に関して言えば、同じ対応する言語拡張を有効にするための(コマンドライン引き数、実装依存の拡張依存、または非標準のプラグマを使う事で)複数の試行は明確に許される。LANGUAGE プラグマに対応する Haskell 2010 実装は {-# LANGUAGE Haskell2010 -#} に対応しなくてはならない。これらの実装はまた、次の名前付き言語拡張の対応を推奨される。DoAndIfThenElse, HierarchicalModules, FixityResolution, PatternGuards, NoNPlusKPatterns, RelaxedDependencyAnalysis, LineCommentSyntax, EmptyDataDeclarations, LanguagePragma and ForeignFunctionInterface. これらは、Haskell 2010 以前のいくつかの実装でサポートされ、この報告書に組み込まれた名前付き言語拡張である。