-XMultiParamTypeClassesフラグが有効なら、以下のような、多引数の型クラスが許される。

  class Collection c a where
    union :: c a -> c a -> c a
    ...etc.

Haskell 98では、クラス宣言の文脈(スーパークラスを導入するのはこれである)は単純でなければならない。すなわち、すべての述語が、型変数にクラスを適用した形でなければならない。-XFlexibleContextsフラグ(7.8.2. 型シグネチャの文脈)はこの制限を外し、クラス宣言の文脈には、クラス階層に循環があってはならないという制約のみがかかるようにする。従って、以下のようなクラス宣言が認められる。

  class Functor (m k) => FiniteMap m k where
    ...

  class (Monad m, Monad (t m)) => Transform t m where
    lift :: m a -> (t m) a

Haskell 98と同様に、クラス階層に循環があってはならない。しかし、「循環があってはならない」というのは、スーパークラスという関係についてのみである。例えば、以下は問題ない。

  class C a where {
    op :: D b => a -> b -> b
  }

  class C a => D a where { ... }

この場合、CはDのスーパークラスであるが、Cのクラス演算であるopがDに言及するのは問題ない。(DをCのスーパークラスにするのは駄目である)

Haskell 98では、クラスメソッドの型中に、クラス型変数についての制約が現れることを禁止している。次のような場合である。

  class Seq s a where
    fromList :: [a] -> s a
    elem     :: Eq a => a -> s a -> Bool

Haskell 98ではelemの型は不正である。制約Eq aがクラス型変数(この場合a)のみを拘束しているからである。GHCはこの制限を撤廃する(-XConstrainedClassMethodsフラグ)。

Haskell 98は、クラスを宣言する際にデフォルト実装を定義することを許している。以下のように。

  class Enum a where
    enum :: [a]
    enum = []

enumメソッドの型は[a]であり、これがデフォルトメソッドの型でもある。-XDefaultSignaturesというフラグを使うと、この制限を撤廃し、デフォルトメソッドに別の型を与えることができる。例えば、genumというメソッドを持つGEnumというクラスに、GHC.Genericsを使って列挙の総称的な実装を書いたなら、その総称的な実装を使うデフォルトメソッドを次のように指定することができる。

  class Enum a where
    enum :: [a]
    default enum :: (Generic a, GEnum (Rep a)) => [a]
    enum = map to genum

defaultキーワードを再利用することで、シグネチャがデフォルトメソッドにのみ適用されることを示している。Enumクラスのインスタンスを定義する際には、enumの元々の型である[a]が変わらず適用される。しかし、空のインスタンスを与えた場合には、デフォルト実装であるmap to0 genumが補充され、(Generic a, GEnum (Rep a)) => [a]という型で型検査される。

我々は、GHCにおける総称プログラミングを単純にするためにデフォルトシグネチャを使っている(7.17. 総称プログラミング)。

クラス宣言では、全てのメソッドについて、そのメソッドの型中の自由変数から、クラス型変数が全て(7.8.2. 型シグネチャの文脈で言われている意味で)到達可能でなければならない。例を挙げる。

  class Coll s a where
    empty  :: s
    insert :: s -> a -> s

これは正しくない。emptyの型がaに言及していないからである。関数従属を使ってこの型変数に到達できるようにすることができる。

  class Coll s a | s -> a where
    empty  :: s
    insert :: s -> a -> s

あるいは、次のようにCollを書き換えても良い。

  class Coll s a where
    empty  :: s a
    insert :: s a -> a -> s a

aの集積物の型((s a))と要素の型であるaとの間につながりを作った訳である。 これがうまく行かないこともある。そういうときは、次のようにクラスを分割することができる。

  class CollE s where
    empty  :: s

  class CollE s => Coll s a where
    insert :: s -> a -> s

なぜ関数従属が必要か、およびどのようにそれを使うか、についての以下の解説は、Hugsの利用者手引きから採られたものである。Mark Jonesが親切にも許可をくれたので、ここに(多少の改変の上で)転載する。

以下のクラスを考えてみよう。これは、何かの集まりを表す型を扱うライブラリの一部という意図である。

   class Collects e ce where
       empty  :: ce
       insert :: e -> ce -> ce
       member :: e -> ce -> Bool

型変数eは要素型を表しており、ceはコンテナの型を表している。この枠組みの下で、このクラスのインスタンスとして、リストや特性関数(どちらも、等値比較可能なあらゆる要素型の集まりを表現できる)、ビット集合(文字の集まりを表現できる)、ハッシュ表(ハッシュ関数のあるあらゆる要素型の集まりを表現できる)を持ちたいとしよう。標準的な実装の詳細を省くと、これは次のような宣言になる。

   instance Eq e => Collects e [e] where ...
   instance Eq e => Collects e (e -> Bool) where ...
   instance Collects Char BitSet where ...
   instance (Hashable e, Collects a ce)
              => Collects e (Array Int ce) where ...

クラスを定義し、いくつかの有用な実装を定義したわけで、ここまでのところ順調である。残念ながら、このクラス宣言にはいくつかの重大な問題がある。第一に、empty関数の型が曖昧である。

   empty :: Collects e ce => ce

「曖昧」だというのは、型変数eが=>の左辺に現れるにもかかわらず、右辺には現れないということである。これが問題なのは、Haskellの多重定義の理論的基礎によると、曖昧な型のある項には、明確に定義された意味が与えられることを保証できないからである。

この問題を回避するだけなら、クラス宣言からemptyメンバを取り除くだけで良い。しかし、残りのメンバであるinsertとmemberも、型こそ曖昧でないが、使おうとすると問題が発生する。例えば、以下の例を考えてほしい。

   f x y = insert x . insert y
   g     = f True 'a'

これに対して、GHCは以下の型を推論する。

   f :: (Collects a c, Collects b c) => a -> b -> c -> c
   g :: (Collects Bool c, Collects Char c) => c -> c

fではxとyの値を一つの集まりに対して順番にinsertしようとしているが、fの型は、この二つの変数が異なる型を持つことを許している。我々が 表現しようとしているのが、ただ一つの型の値のみを含む集まりだとすれば、これは明らかに不正確な型である。さらに悪いことに、gの定義は、型エラーを起こすことなくコンパイルを通過する。結果として、このコードの誤りはすぐには明らかにされない。これが発覚するのはgを使おうとしたときで、これは別のモジュールであることさえあり得る。

   class Collects e c where
      empty  :: c e
      insert :: e -> c e -> c e
      member :: e -> c e -> Bool

   f :: (Collects e c) => e -> e -> c e -> c e

   class C a b where ...

   class D a b | a -> b where ...
   class E a b | a -> b, b -> a where ...

   instance D Bool Int where ...
   instance D Bool Char where ...

   instance D [a] b where ...

   instance D t s where ...

   class Collects e ce | ce -> e where
      empty  :: ce
      insert :: e -> ce -> ce
      member :: e -> ce -> Bool

   f x y = insert x y = insert x . insert y

   f :: (Collects a c, Collects b c) => a -> b -> c -> c

   f :: (Collects a c) => a -> a -> c -> c

Haskell 98では、インスタンス宣言の頭部はC (T a1 ... an)という形でなければならない。ここで、Cはクラス、Tはデータ型構築子、a1 ... anは相異なる型変数である。GHCはこれを二通りの方向に緩和する。

Haskell 98では、インスタンス宣言中の文脈における表明はC aという形でなければならない。ここでaは頭部に出現する型変数である。

-XFlexibleContextsフラグは、この規則を緩め、さらに型シグネチャについての同様の規則も緩める(7.8.2. 型シグネチャの文脈を見よ)。このフラグが有効なら、インスタンス宣言の文脈は、下記の規則に従う限り、(種の正しい)任意の表明(C t1 ... tn)から成っていてよい。

これらの制約により、文脈の簡約に終わりがあることが保証される。一回簡約するごとに最悪でも構築子一つ分問題が小さくなるからである。-XUndecidableInstancesフラグ(7.6.3.3. 決定不能インスタンス)を与えれば、Paterson条件と対応範囲条件の両方が撤廃される。これらの制限がある理由についての沢山の背景資料が、論文Understanding functional dependencies via Constraint Handling Rulesに見つかる。

例を挙げると、以下のものは問題ない。

  instance C Int [a]          -- 多引数
  instance Eq (S [a])         -- 頭部に構造のある型

      -- 頭部に同じ型変数が複数回出現
  instance C4 a a => C4 [a] [a]
  instance Stateful (ST s) (MutVar s)

      -- 頭部は型変数のみから成っていても良い
  instance C a
  instance (Eq a, Show b) => C2 a b

      -- 文脈中に型変数以外のものがあっても良い
  instance Show (s a) => Show (Sized s a)
  instance C2 Int a => C3 Bool [a]
  instance C2 Int a => C3 [a] b

一方で、下記は禁止される。

      -- 文脈の表明が頭部より小さくない
  instance C a => C a where ...
      -- (C b b)に頭部よりも多くのbの出現がある
  instance C b b => Foo [b] where ...

これと同じ制約が、deriving節で生成されたインスタンスにも適用される。従って、下記のものは許される。

  data MinHeap h a = H a (h a)
    deriving (Show)

これは、自動導出された以下のインスタンスが上記の規則に整合するからである。

  instance (Show a, Show (h a)) => Show (MinHeap h a)

上記の規則によって、ある便利なイディオムが可能になる。重複インスタンス宣言を許すとき、より特化したインスタンスが当てはまらないときに適用される「デフォルトのインスタンス」があると非常に便利である。

  instance C a where
    op = ... -- デフォルト

7.6.3.2. インスタンス文脈に関する規則の緩和の規則でさえも厄介なことがある。例えば、次のようにして「クラスシノニム」のような効果を得たいと思うかもしれない。

  class (C1 a, C2 a, C3 a) => C a where { }

  instance (C1 a, C2 a, C3 a) => C a where { }

次のようなシグネチャがあったとする。

  f :: (C1 a, C2 a, C3 a) => ...

これは上記のものを使えば次のように書ける。

  f :: C a => ...

関数従属(7.6.2. 関数従属 )についての制約は特に面倒である。通常の規則では禁止されているものの、頭部に現れない型変数を文脈中で使いたいと思うことがあるだろう。以下のような場合である。

  class HasConverter a b | a -> b where
     convert :: a -> b

  data Foo a = MkFoo a

  instance (HasConverter a b,Show b) => Show (Foo a) where
     show (MkFoo value) = show (convert value)

しかし、これは危険な領域である。例えば、以下のものは、型検査器をループさせる。

  class D a
  class F a b | a->b
  instance F [a] [[a]]
  instance (D c, F a c) => D [a]   -- 「c」は頭部で言及されていない

同様に、対応範囲条件を撤廃したいと思うかもしれない。

  class Mul a b c | a b -> c where
  	(.*.) :: a -> b -> c

  instance Mul Int Int Int where (.*.) = (*)
  instance Mul Int Float Float where x .*. y = fromIntegral x * y
  instance Mul a b c => Mul a [b] [c] where x .*. v = map (x.*.) v

三番目のインスタンス宣言は対応範囲条件に従っていない。実際、以下の(やや奇妙な)例では、型推論がループに陥る。これは、(Mul a [b] b)という制約を要求するからである。

  f = \ b x y -> if b then x .*. [y] else y

これにもかかわらず、GHCは、より自由な規則の下で実験することを許している。-XUndecidableInstances という実験的なフラグを使えば、Paterson条件と対応範囲条件(7.6.3.2. インスタンス文脈に関する規則の緩和に記述がある)の両方が撤廃される。停止性は、深さ固定の再帰スタックを使うことで保証される。スタックの深さを超過した場合、バックトレースのようなものが表示される。この時、-fcontext-stack=Nで、スタックをより深くすることもできる。

一般に、GHCでは、型クラス制約を解決するのにどのインスタンス宣言を使えば良いかが曖昧さなく決まることが要求される。この挙動を変更するフラグが二つある。-XOverlappingInstances と-XIncoherentInstances である。この節ではこれらを扱う。これらは両方とも動的フラグであり、(望むならOPTIONS_GHCプラグマを使って)モジュール単位で設定することができる。(4.2.2. ソースファイル中のコマンド行オプション)

例えば、C Int Boolという制約を解決しようとするときは、全てのインスタンス宣言について、その頭部を具体化して、この制約と照合しようと試みられる。例として、以下のようなインスタンス宣言があったとしよう。

  instance context1 => C Int a     where ...  -- (A)
  instance context2 => C a   Bool  where ...  -- (B)
  instance context3 => C Int [a]   where ...  -- (C)
  instance context4 => C Int [Int] where ...  -- (D)

インスタンス(A)および(B)は制約C Int Boolに適合するが、(C)や(D)は適合しない。照合の際、インスタンス宣言の文脈(context1など)は無視される。GHCのデフォルトの振る舞いは、解決中の制約に適合するインスタンスがただ一つ存在しなければならないというものである。潜在的な重複(例えば(A)と(B)の両方がスコープにある場合)があっても問題はない。特定の制約に複数のインスタンスが適合して初めてエラーが報告される。

-XOverlappingInstancesフラグは、最も特殊性の高いインスタンスが存在することを条件に、複数のインスタンスの適合を認めるものである。例えば、C Int [Int]には(A)、(C)、(D)の各インスタンスが適合するが、最後のものの特殊性が最も高いので、これが選ばれる。最も特殊性の高いものがない場合は、プログラムが拒絶される。

ただし、GHCは重複インスタンスから特定のものを選ぶことに関しては保守的である。例。

  f :: [b] -> [b]
  f x = ...

fの右辺から、C Int [b]という制約を得たとしよう。しかし、GHCはインスタンス(C)を使うことはない。なぜなら、fの呼び出しによっては、bがIntに実体化するかも知れず、その場合は(D)が最も特殊性の高いインスタンスになるからである。よって、GHCはこのプログラムを拒絶する。(-XIncoherentInstancesフラグを追加すると、GHCは、後々のインスタンス化についての問題を指摘することなく、(C)を選ぶようになる)。

fに型シグネチャを与えたので、fが指定した型を持っていることをGHCが検査せねばならなかったことに注意。そうでなく、型シグネチャを与えず、GHCに推論してもらったとしよう。この場合、GHCはC Int [b]という制約を単純化することは避ける(前と同じ理由)が、プログラムを拒絶することはなく、以下の型を推論する。

  f :: C Int [b] => [b] -> [b]

これは、どのインスタンスを選ぶかの問題をfの呼び出し側まで遅延する。その時には、型bについてより多くが知られているだろう。 -XFlexibleContextsフラグを使えば、この型シグネチャを自分で書くことができる。

インスタンス宣言自体についても、まったく同じ状況が発生し得る。以下のものがあるとしよう。

  class Foo a where
     f :: a -> a
  instance Foo [b] where
     f x = ...

さらに、前と同じように、制約C Int [b]がfの右辺から発生するとする。制約C Int [b]は複数のインスタンス宣言に適合するので、前と同様にGHCはこの制約を解決する方法が分からないとしてこのインスタンスを拒絶する。解決策は、インスタンス宣言の文脈にこの制約を加えて、選択を後回しにすることである。次のように。

  instance C Int [b] => Foo [b] where
     f x = ...

(これをするには-XFlexibleInstancesが必要である)

警告: 重複インスタンスを使うときは気を付けないといけない。一貫性が失われる(つまり、プログラムの部分部分で異なるインスタンスが選ばれる)可能性があるからである。これは-XIncoherentInstancesを使っていない場合ですらそうである。以下を考えよ。

{-# LANGUAGE OverlappingInstances #-}
module Help where

    class MyShow a where
      myshow :: a -> String

    instance MyShow a => MyShow [a] where
      myshow xs = concatMap myshow xs

    showHelp :: MyShow a => [a] -> String
    showHelp xs = myshow xs

{-# LANGUAGE FlexibleInstances, OverlappingInstances #-}
module Main where
    import Help

    data T = MkT

    instance MyShow T where
      myshow x = "Used generic instance"

    instance MyShow [T] where
      myshow xs = "Used more specific instance"

    main = do { print (myshow [MkT]); print (showHelp [MkT]) }

showHelp関数では、GHCから重複のあるインスタンスが見えないので、GHCは文句を言うことなくMyShow [a]インスタンスを使う。main中のmyshowの呼び出しでは、GHCは、制約MyShow [T]を解決するに際してMainモジュールの重複インスタンス宣言を使う。結果として、このプログラムは次のように表示する。

  "Used more specific instance"
  "Used generic instance"

(実装されていないが、他にあり得る振る舞いとして、後のインスタンス宣言が局所的なものと重複するかもしれないという理由でHelpモジュールを拒絶するというものがある。)

重複インスタンスや非整合(incoherent)インスタンスになるかどうかは、インスタンス宣言の性質であり、そのモジュールがコンパイルされるときに-XOverlappingInstancesと-XIncoherentInstancesが有効になっていたかどうかで決まる。より精密には、インスタンス発見の過程では、以下が成り立つ。

これらの規則によって、ライブラリの作者は、重複インスタンスに依存したライブラリを、利用者がそれについて知らなくても良いように設計することができる。

-XIncoherentInstancesフラグを使うと、-XOverlappingInstancesフラグは自動的に有効になる。逆は真でない。