このプラグマは、言語拡張を、可搬性のある方法で有効にできるようにするものである。意図としては、全てのコンパイラが同じ構文のLANGUAGEに対応する、というものである。もちろん、全ての拡張が全てのコンパイラで使える訳ではないが。可能なら、OPTIONS_GHCプラグマの代わりにLANGUAGEを使うべきである。

例えば、FFIと、CPPを使った前処理を有効にするには、次のようにする。

{-# LANGUAGE ForeignFunctionInterface, CPP #-}

LANGUAGEはファイルヘッダプラグマ(7.13. プラグマを見よ)である。

全ての言語拡張は、前に「-X」を付けることでコマンド行フラグになる。例えば-XForeignFunctionInterfaceのように。(同様に、全ての「-X」フラグはLANGUAGEプラグマとして書ける)

対応している言語拡張の一覧は、ghc --supported-languagesを実行することで得られる。(4.4. 実行モードを見よ)

Language.Haskell.Extensionで定義されている型Extensionの構築子ならどれを使っても良い。指定された拡張がGHCでサポートされていないなら、エラーが報告される。

OPTIONS_GHCプラグマは、そのソースファイルをコンパイルするときにコンパイラに与える追加のオプションを指定するのに使う。詳細は4.1.2. ソースファイル中のコマンド行オプションを見よ。

GHCの古い版ではOPTIONS_GHCではなくOPITONSを受け付けていたが、これはもはや非推奨である。

過去には、FFIを使うとき、Cを介してコンパイルしているなら、INCLUDEプラグマを使ってどのヘッダファイルをincludeする必要があるか指定しなければならなかった。これはもはやGHCにとって必要でないが、他のコンパイラとの互換性のために受け付けられる(そして無視される)。

WARNINGプラグマを使うと、特定の関数やクラスや型に任意の警告を付属させることができる。DEPRECATEDプラグマを使うと、特定の関数やクラスや型が、非推奨・廃止予定であると指定できる。これらのプラグマを使うには二つの方法がある。

警告と非推奨報告は次のものに対しては為されない。(a) 定義されたモジュール中での使用、および (b) エクスポートリスト中での使用。後者のおかげで、一つのモジュールが複数のモジュールがエクスポートしているものを集めて再エクスポートするという構造のライブラリで、余計な文句を言うことがない。

フラグ-fno-warn-warnings-deprecationsを使ってこの警告を抑制することができる。

これらのプラグマは関数定義のインライン化を制御する。

key_function :: Int -> String -> (Bool, Double)
{-# INLINE key_function #-}

#ifdef __GLASGOW_HASKELL__
{-# INLINE thenUs #-}
{-# INLINE returnUs #-}
#endif

                           --  段階2より前         段階2以降
  {-# INLINE   [2]  f #-}  --    しない              する
  {-# INLINE   [~2] f #-}  --     する              しない
  {-# NOINLINE [2]  f #-}  --    しない           場合による
  {-# NOINLINE [~2] f #-}  --  場合による           しない

  {-# INLINE   f #-}       --     する               する
  {-# NOINLINE f #-}       --    しない             しない

GHCは、コードのいろいろな構成要素に、三つのプラグマを使って追加のデータを注釈として付ける機能を提供する。そうしたデータは、後でGHC-as-a-libraryを使って観察することができる。

{-# ANN foo (Just "Hello") #-}
foo = ...

{-# ANN f SillyAnnotation { foo = (id 10) + $([| 20 |]), bar = 'f } #-}
f = ...

{-# ANN type Foo (Just "A `Maybe String' annotation") #-}
data Foo = ...

{-# ANN module (Just "A `Maybe String' annotation") #-}

このプラグマはCの#lineプラグマに似ていて、自動生成されたHaskellコードで使うことを主に意図したものである。これを使うと、元々のコードの行番号とファイル名を指定することができる。例えば、ファイルが、Foo.vhsというファイルから生成され、その行が元のファイルの42行目に当たるなら、以下のように書けば良い。

{-# LINE 42 "Foo.vhs" #-}

エラーメッセージが報告されるとき、LINEプラグマで指定された行・ファイルを参照するようになる。

RULESプラグマを使うと書き換え規則を指定することができる。これは7.14. 書き換え規則 で解説されている。

(英式にSPECIALISEでも良い) 鍵となる多重定義関数について、特定の型に特殊化された版を作ることができる。(注意: コードサイズは増大する)。次のような多重定義関数があったとしよう。

  hammeredLookup :: Ord key => [(key, value)] -> key -> value

この関数が、keyの型をWidgetとして特に良く使われるなら、次のようにして特殊化することができる。

  {-# SPECIALIZE hammeredLookup :: [(Widget, value)] -> Widget -> value #-}

関数についてのSPECIALIZEプラグマは、その関数の型シグネチャが書けるところならどこにでも書ける。

SPECIALIZEの効果は、その関数の特殊化版を生成することと、およびその関数の未特殊化版の呼び出しを特殊化版の呼び出しに書き換える規則(7.14. 書き換え規則 を見よ)を生成することである。

SPECIALIZEプラグマ中の型は元の関数の型より多相性が低いものならなんでも良い。ちゃんとした言い方では次のようになる。元の関数がfだとする。

  {-# SPECIALIZE f :: <type> #-}

このプラグマが正当なのは、以下の定義が正当な時だけである。

  f_spec :: <type>
  f_spec = f

いくつか例を示す。(元の関数については型シグネチャだけを示し、コードは省略した)

  f :: Eq a => a -> b -> b
  {-# SPECIALISE f :: Int -> b -> b #-}

  g :: (Eq a, Ix b) => a -> b -> b
  {-# SPECIALISE g :: (Eq a) => a -> Int -> Int #-}

  h :: Eq a => a -> a -> a
  {-# SPECIALISE h :: (Eq a) => [a] -> [a] -> [a] #-}

最後の例では、生成されたRULSの左辺がかなり複雑なものになる(試してみよ)ので、あまりうまく発動しないかもしれない。この手の特殊化を使うことがあったら、どの程度うまくいったか知らせてほしい。

SPECIALIZEの後にはINLINEかNOINLINEプラグマを続けることができる。さらに、7.13.5. INLINEおよびNOINLINEプラグマにあるように段階を指定することもできる。このようなINLINEプラグマはその関数の特殊化版(のみ)に影響し、その関数が再帰的であっても適用される。動機となる例はこれである。

-- type-indexedな表現を持つ配列のGADT
data Arr e where
  ArrInt :: !Int -> ByteArray# -> Arr Int
  ArrPair :: !Int -> Arr e1 -> Arr e2 -> Arr (e1, e2)

(!:) :: Arr e -> Int -> e
{-# SPECIALISE INLINE (!:) :: Arr Int -> Int -> Int #-}
{-# SPECIALISE INLINE (!:) :: Arr (a, b) -> Int -> (a, b) #-}
(ArrInt _ ba)     !: (I# i) = I# (indexIntArray# ba i)
(ArrPair _ a1 a2) !: i      = (a1 !: i, a2 !: i)

ここでは、(!:)はArr e型の配列の添字演算を行う再帰関数である。(Int,Int)での(!:)の呼び出しを考えてみよう。二番目の特殊化が発動し、その特殊化された関数がインライン化される。それには(!:)の呼び出しが二つあり、どちらもInt型についてのものである。これらの呼び出しは両方とも最初の特殊化を発動させ、その本体も再びインライン化される。結果として、添字演算関数についての型によるアンロールができたことになる。

警告: SPECIALISE INLINEを非多相再帰な関数に対して使うと、GHCは発散する。

参考: 古いGHCでは、特定の型についての特殊化を自分で指定することができた。

{-# SPECIALIZE hammeredLookup :: [(Int, value)] -> Int -> value = intLookup #-}

より一般的なRULESプラグマ(7.14.4. 特殊化 を見よ)ができたので、この機能は削除された。

考え方は同じで、対象がインスタンス宣言になっただけである。例を示す。

instance (Eq a) => Eq (Foo a) where { 
   {-# SPECIALIZE instance Eq (Foo [(Int, Bar)]) #-}
   ... 通常と同じ ...
 }

このプラグマはインスタンス宣言のwhere部に現れなければならない。

ところで、これはHBCと互換性がある。あるいはプラグマの配置場所については非互換かもしれないが。

UNPACKは、コンパイラに対し、構築子フィールドの内容を構築子に直に収めることで、一段階の間接参照を排除することを指示するものである。例を示す。

data T = T {-# UNPACK #-} !Float
           {-# UNPACK #-} !Float

これにより、二つの非ボックス化Floatを保持する構築子Tができる。これは常に最適化になっているとは限らない。例えば、構築子Tの内容を調べて、そのfloatを非正格な関数に渡す場合、それらを再びボックス化しなければならない。(これはコンパイラによって自動的に行われる)

構築子のアンパックは専ら-Oと組み合わせて使われるべきである。再ボックス化をなるべく排除できるように展開候補をコンパイラに露出するためである。次の例を考える。

f :: T -> Float
f (T f1 f2) = f1 + f2

コンパイラは、floatについての+をインライン化することで、f1とf2を再ボックス化することを避けるが、これは-Oが有効なときだけである。

単一構築子のデータはどんなものでもアンパックし得る。

data T = T {-# UNPACK #-} !(Int,Int)

この場合、構築子Tは、対を平坦化して、二つのIntを直接保持することになる。複数水準のアンパックもサポートされている。

data T = T {-# UNPACK #-} !S
data S = S {-# UNPACK #-} !Int {-# UNPACK #-} !Int

この場合、二つの非ボックス化Int#が構築子Tに直接置かれる。アンパックはnewtypeを透過して起こる。

フィールドがアンパックできないとき、警告は出力されないので、生成されたコードを-ddump-simplで検査するのが良いかもしれない。

-funbox-strict-fieldsフラグも見よ。これは、簡単に言うと、あらゆる正格な構築子フィールドに{-# UNPACK #-}を加えるのと同じ効果がある。

{-# SOURCE #-}は専らimport宣言の中で使われ、モジュールのループを断ち切る役割を果たす。詳しい説明は4.6.9. 相互再帰的なモジュールをコンパイルするにはにある。