GHCは、(いつもと同様、-Oが指定されているときだけ)「十分に小さい」関数・値をインライン化(または「展開(unfold)」)して、呼び出しのオーバーヘッドを回避し、場合によってはより素晴らしい最適化を可能にしようとする。通常、GHCがある関数をインライン化するのが「高くつきすぎる」と判断したときは、インライン化は行わないし、他のモジュールで使うために展開候補をエクスポートすることもない。

ここで使える強力な武器がINLINEプラグマであり、次のように使う。

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

INLINEプラグマの主要な効果は、ある関数の「コスト」がとても低いと宣言することである。これによって、通常の展開機構がインライン化に非常に積極的になる。一方、関数「f」に関するINLINEプラグマには、他の効果がいくつかある。

GHCはインライン化が永遠に続くことがないことを保証する。相互再帰的な一団はすべて、一個以上の決してインライン化されないループ破りによって切り離される。( Secrets of the GHC inliner, JFP 12(4) July 2002を見よ)。GHCはループ破りとしてINLINEプラグマのついた関数を選ばないことを試みるが、選択肢がないときはINLINE関数でも選択され得、この場合INLINEプラグマは無視される。例えば、自己再帰的な関数では、ループ破りはその関数自体でしかありえないので、INLINEプラグマは常に無視される。

構文的には、ある関数についてのINLINEプラグマは、その関数の型シグネチャが置けるところならどこに置いても良い。

INLINEプラグマはモナドのthen/return(またはbind/unit)関数に特に有用である。例えば、GHCのUniqueSupplyモナドのコードには次のものが含まれている。

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

NOINLINEプラグマ(7.13.5.3. NOINLINEプラグマ)とINLINABLEプラグマ(7.13.5.2. INLINABLEプラグマ)も見よ。

注意: HBCコンパイラはINLINEプラグマと相性が悪いので、コードをHBC互換にしたいなら#ifdef __GLASGOW_HASKELL__...#endifというCプリプロセッサ指令でプラグマを囲む必要があるだろう。

関数fに対する{-# INLINABLE f #-}プラグマは、以下のように振る舞う。

NOINLINEプラグマはまさに想像される通りのことを行う。すなわち、指定された関数がコンパイラによってインライン化されるのを防ぐ。コードの大きさについて非常に用心深くある場合をのぞけば、これが必要になることはないはずである。

NOTINLINEはNOINLINEの同義名である。(NOINLINEは、Haskell 98によって、インライン化を無効にするための標準的な方法として定められているので、コードの可搬性を気にするならこちらを使うべきである)

INLINEプラグマとNOINLINEプラグマはCONLIKE修飾子を持つことができる。これは、RULEの照合に(のみ)影響する。7.14.3. 書き換え規則と、INLINE/NOINLINEおよびCONLIKEプラグマとの間の相互作用を見よ。

GHCのパイプライン中のどの段階でINLINEプラグマが有効になるかを制御したいことがあるだろう。インライン化が行われるのは、単純化器の実行過程だけである。単純化器は、毎回異なる段階番号で実行される。段階番号は零に向かって減少する。-dverbose-core2coreを使えば、単純化器が連続して実行されるに際しての段階番号を見ることができる。次のように、INLINEプラグマに段階番号を指定することができる。

以下に、上の情報をまとめる。

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

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

「場合による」というのは、インライン化についての通常のヒューリスティクス(関数本体が小さいなら、とか、興味深い見た目の引数に適用されているなら、など)が適用されるということである。この規則は次のように捉えることもできる。

これと同じ段階番号制御はRULES(7.14. 書き換え規則 )についても使える。

最上位の値の束縛には、ANNプラグマを使って、TypeableとDataの両方のインスタンスであるような任意の式を添付することができる。したがって、特に、通常の値(例えばtake)だけでなくデータ構築子(例えばJust)にもANNを使って注釈を付けられる。例として、fooという関数にJust "Hello"を注釈として付けるには、次のようにする。

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

注釈の利用には、いくつか制限が課せられる。

これらの制限のうちどれかがあまりに重荷だと強く思うなら、GHCチームに連絡を寄越して欲しい。

一方で、これらの制限を別にすれば、多くのことが許されており、完全に評価されていない式でさえも使うことができる。注釈式は、Template Haskellの接合がコンパイラによって評価されるのとちょうど同じように評価される。よって、この注釈は問題ない。

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

ANNプラグマで型に注釈を付けるには、typeキーワードを使う。例を示す。

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

ANNプラグマでモジュールに注釈を付けるには、moduleキーワードを使う。例を示す。

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

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は発散する。

一般に、SPECIALIZEプラグマは同じモジュールで定義された関数にのみ与え得る。しかし関数fがその定義場所でINLINABLEプラグマを与えられているなら、インポート先のモジュールで後から特殊化することができる(7.13.5.2. INLINABLEプラグマを見よ)。例を挙げる。

module Map( lookup, blah blah ) where
  lookup :: Ord key => [(key,a)] -> key -> Maybe a
  lookup = ...
  {-# INLINABLE lookup #-}

module Client where
  import Map( lookup )

  data T = T1 | T2 deriving( Eq, Ord )
  {-# SPECIALISE lookup :: [(T,a)] -> T -> Maybe a

ここで、lookupがINLINABLEと宣言されているが、この定義位置ではTが存在しないので、これをTに関して特殊化することができない。代わりに、利用者のモジュールがTを定義して、lookupをその型に関して特殊化することができる。

さらに、Clientをインポートする(あるいは推移的に、Clientをインポートするモジュールをインポートする)全てのモジュールからは、このlookupの特殊化版が「見え」て、利用されることになる。各モジュールにSPECIALIZEプラグマを置く必要はない。

さらに、そもそもSPECIALIZEプラグマすら必要ないこともある。モジュールMをコンパイルする際、GHCの最適化器(-Oで)は、Mで定義された全ての最上位の多重定義関数について、Mで呼ばれている型に関して特殊化するかどうか検討する。加えて最適化器はMにインポートされたINLINABLEの多重定義関数について、Mで呼ばれている型に関して特殊化するかどうか検討する。よってこの例では、以下のように、lookupをT型で呼ぶだけで十分だろう。

module Client where
  import Map( lookup )

  data T = T1 | T2 deriving( Eq, Ord )

  findT1 :: [(T,a)] -> Maybe a
  findT1 m = lookup m T1   -- T型でのlookupの呼び出し

しかし、このような呼び出しがないこともあるので、そういう場合にこのプラグマは便利になり得る。

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

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

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