言語ゲーム

とあるエンジニアが嘘ばかり書く日記

Twitter: @propella (MF東京 8/3,4)

提案: LanguagePragma http://hackage.haskell.org/trac/haskell-prime/wiki/LanguagePragma

概要

LANGUAGE プラグマが提供する最低限の保証を記述する。

内容

GHC と Cabal (Language.Haskell.Extension を通じて) では次の二つの目的のために LANGUAGE プラグマを上手く利用して来た。

  1. ソースファイルに必要な Haskell98 以降の言語拡張を記述する。
  2. 拡張機能を使うソースファイルをコンパイルする際に、必要となる言語拡張を有効化する。

この提案の目的は、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 以前のいくつかの実装でサポートされ、この報告書に組み込まれた名前付き言語拡張である。