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

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

Haskell 98では、クラス宣言の文脈(スーパークラスを導入するのはこれである)は単純でなければならない。すなわち、すべての述語が、型変数にクラスを適用した形でなければならない。-XFlexibleContextsフラグ(7.13.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のスーパークラスにするのは駄目である)

制約の種を追加する拡張を使うと、さらに風変りなスーパークラス定義を書くことができる。この場合、スーパークラス循環の検査はさらに緩和される。たとえばこれは問題ない。

class A cls c where
  meth :: cls c => c -> c

class A B c => B c where

クラスCのスーパークラス文脈が許されるのは、型シノニムをその右辺へと展開し、使われている(C以外の)クラスをそれらのスーパークラスへと展開したときに、構文的にその文脈内に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 to genumが補充され、(Generic a, GEnum (Rep a)) => [a]という型で型検査される。

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

クラス宣言では、全てのメソッドについて、そのメソッドの型中の自由変数から、クラス型変数が全て(7.13.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

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

instance context1 => C Int a     where ...  -- (A)
instance context2 => C a   Bool  where ...  -- (B)

GHCのデフォルトの振る舞いは、解決しようとする制約に適合するインスタンスが、ただ一つ存在しなければならないというものである。例えば、制約C Int Boolは(A)と(B)の両インスタンスに適合するので、拒絶される。C Int Charは(A)にしか合致しないので、(A)が選ばれる。

以下に注意せよ。

インスタンス解決の規則を緩めるフラグに関して、7.6.3.5. 重複インスタンスも見よ。

Haskell 98では、インスタンス宣言の頭部はC (T a1 ... an)という形でなければならない。ここで、Cはクラス、Tはデータ型構築子、a1 ... anは相異なる型変数である。多引数の型クラスについては、この規則がインスタンス頭部の各パラメタに対して適用される。(この形を持つものがただ一つで、残りが型変数であってもたぶん問題ないはずだが、今のところこれが規則である。)

GHCはこれを二通りの方向に緩和する。

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

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

これらの制約により、文脈の簡約に終わりがあることが保証される。一回簡約するごとに最悪でも構築子一つ分問題が小さくなるからである。-XUndecidableInstancesフラグ(7.6.3.4. 決定不能インスタンス)を与えれば、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.3. インスタンス文脈に関する規則の緩和の規則でさえも厄介なことがある。例えば、次のようにして「クラスシノニム」のような効果を得たいと思うかもしれない。

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.3. インスタンス文脈に関する規則の緩和に記述がある)の両方が撤廃される。停止性は、深さ固定の再帰スタックを使うことで保証される。スタックの深さを超過した場合、バックトレースのようなものが表示される。この時、-fcontext-stack=Nで、スタックをより深くすることもできる。

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

-XOverlappingInstancesが与えられると、GHCは、7.6.3.1. インスタンスの解決に記述されているインスタンス解決規則を緩めて、最も特殊性の高いインスタンスが存在することを条件に、複数のインスタンスの適合を認める。-XIncoherentInstancesフラグは、この解決をさらに緩め、最も特殊性の高いインスタンスが存在するかどうかにかかわらず、複数のインスタンスが適合することを認める。

例として、以下を-XOverlappingInstancesを有効にしてコンパイルする場合を考えよ。

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

C Int [Int]という制約は、(A)、(C)、(D)の各インスタンスに適合するが、最も特殊性が高いのは最後のものなので、これが選ばれる。

仮に(D)が存在しなかった場合、(A)と(C)は変わらず適合するが、どちらも、最も特殊性が高い訳ではない。この場合、-XOverlappingInstancesが有効であってもプログラムは拒絶される。-XIncoherentInstancesが有効の場合、このプログラムは受理され、(A)または(C)が恣意的に選ばれる。

あるインスタンス宣言が別のインスタンス宣言よりも特殊性が高いというのは、前者の頭部が後者の頭部の置換例であることである。例えば、(D)が(C)よりも「特殊性が高い」のは、a:=Intの置換を施すことで(C)から(D)にたどりつけるからである。

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

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

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

ただし、(D)を含むモジュールをコンパイルする際に-XIncoherentInstancesフラグを追加すると、GHCは、後々のインスタンス化についての問題を指摘することなく、(C)を選ぶようになる。

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

f :: C b [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が有効になっていたかどうかで決まる。(C ty1 .. tyn)という目標制約のインスタンスを探しているとしよう。探索は次のように行なわれる。

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

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

Haskellでは、インスタンス宣言に型シグネチャを書くことはできない。しかしこれができると便利なことがあるので、言語拡張-XInstanceSigsがこれを許す。例を示す。

data T a = MkT a a
instance Eq a => Eq (T a) where
  (==) :: T a -> T a -> Bool   -- シグネチャ
  (==) (MkT x1 x2) (MkTy y1 y2) = x1==y1 && x2==y2

インスタンス宣言における型シグネチャは、クラス宣言内のものにインスタンスの型をあてはめたものと全く同じでなければならない。

型シグネチャを書きたいと思うスタイル上の理由の一つは、単純なドキュメントとしてである。もう一つは、スコープを持つ型変数をスコープに導入したいかもしれないからである。例。

class C a where
  foo :: b -> a -> (a, [b])
 
instance C a => C (T a) where
  foo :: forall b. b -> T a -> (T a, [b])
  foo x (T y) = (T y, xs)
     where
       xs :: [b]
       xs = [x,x,x]

-XScopedTypeVariables(7.13.8. 字句的スコープを持つ型変数 )も指定しているなら、forall bのスコープはfooの定義にわたる。特にxsの型シグネチャもこれに含まれる。

上記の脱糖において、toList、fromList、fromListNの各関数はIsListクラスのメソッドであり、このクラスはGHC.Extsモジュールからエクスポートされている。この型クラスは以下のように定義されている。

class IsList l where
  type Item l

  fromList :: [Item l] -> l
  toList   :: l -> [Item l]

  fromListN :: Int -> [Item l] -> l
  fromListN _ = fromList

FromListクラスとそのメソッドは、OverloadedLists拡張と一緒に使うことを意図されている。

IsListの新しいインスタンスを定義することは何も問題ない。これによって、全く新しいデータ型に対してもリスト記法が使えるようになる。ここにインスタンスの例をいくつか示す。

instance FromList [a] where
  type Item [a] = a
  fromList = id
  toList = id

instance (Ord a) => FromList (Set a) where
  type Item (Set a) = a
  fromList = Set.fromList
  toList = Set.toList

instance (Ord k) => FromList (Map k v) where
  type Item (Map k v) = (k,v)
  fromList = Map.fromList
  toList = Map.toList

instance FromList (IntMap v) where
  type Item (IntMap v) = (Int,v)
  fromList = IntMap.fromList
  toList = IntMap.toList

instance FromList Text where
  type Item Text = Char
  fromList = Text.pack
  toList = Text.unpack

instance FromList (Vector a) where
  type Item (Vector a) = a
  fromList  = Vector.fromList
  fromListN = Vector.fromListN
  toList = Vector.toList

-XOverloadedListsが有効な場合、リスト記法を脱糖する際にはGHCはGHC.Extsモジュール由来のfromList(など)を使う。これはGHC.Extsをインポートしなくても行なわれる。

しかし、-XRebindableSyntaxを使うと、GHCは、toList、fromList、fromListNの各名前について、スコープにあるものならなんでも使うようになる。つまり、これらの関数は再束縛可能である。7.3.15. 再束縛可能な構文とPreludeの暗黙インポートと比較せよ。

現在、IsListクラスにはデフォルト化規則が付随していない。以下のようなデフォルト宣言はもっともらしいが、このような宣言の意味を如何に規定するかについては、あまり深く考察されていない。

default ([a])

OverloadedLists拡張は、リテラルを内容とするリストを特別扱いすることで、現在の実装からさらに改良できる。より詳しく言うと、コンパイラはこのようなリストを確保する際にコンパクトな表現を使うことが可能であり、その場合IsListインスタンスがこのコンパクト表現を活用できるようにすることができる。この能力があれば、OverloadedStrings拡張をOverloadedLists拡張に統合することが現実味を帯びるであろう(現在のところ、文字列リテラルは特別扱いされ、静的に確保されたコンパクトな表現を使うことができる)。