言語拡張-XUnicodeSyntaxは、特定のASCII文字列をUnicode文字を使って表すことを可能にする。以下の代替記法が提供される。

-XMagicHashという言語拡張は、識別子に対する後置修飾子として「#」を認めるものである。つまり、「x#」が変数として有効に、「T#」が型構築子やデータ構築子として有効になる。

この井桁記号はまったく意味論に影響を与えない。非ボックス化された値や型に「#」で終わる名前を付ける(たとえばInt#)傾向があるが、必須ではない。これらはただの通常の変数に過ぎないのである。また、拡張-XMagicHashが何かをスコープに導入することもない。例えば、Int#をスコープに導入するためにはGHC.Prim(7.2. 非ボックス化型とプリミティブ演算を見よ)をインポートしなければならない。その後で、スコープに導入されたInt#に言及することを可能にするのが-XMagicHashオプションである。このオプションが有効だと、x#y = 0の意味が変わることに注意。yという引数を一つ取る関数x#を定義することになる。#という演算子を定義するには、空白を置けば良い。x # y = 0。

また、-XMagicHashは新しい形式のリテラルを何種類か有効にする。(7.2.1. 非ボックス化型 を見よ)

-123というリテラルは、Haskell98およびHaskell 2010によれば、negate (fromInteger 123)のように脱糖される。言語拡張-XNegativeLiteralsは、これがfromInteger (-123)に脱糖されるようにする。

ある数値的データ型が表現できる範囲が正と負で異なる場合、これによって違いが出ることがある。例えば、8ビット算術において-128は表現可能だが、+128はそうでない。よって、negate (fromInteger 128)は予期しない整数リテラルオーバーフローのメッセージを引き起こす。

Haskell 2010およびHaskell 98は1.2e6という構文の浮動小数点リテラルを定義している。このようなリテラルはFractional a => aという型を持つ。

言語拡張-XNumDecimalsは、Integralのインスタンスについても浮動小数点リテラルの構文を許し、(1.2e6 :: Num a => a)のような値を使えるようにする。

GHCは、モジュール名の構文について、ある小さな拡張をサポートしている。すなわち、モジュール名はドット「.」を含むことができる。これは「階層的モジュール名前空間」拡張とも呼ばれる。これは、通常平坦なHaskellモジュールの名前空間を拡張して、より柔軟な、モジュールの階層をつくり出すからである。

この拡張は言語そのものにはほとんど影響を与えない。モジュール名は常に完全修飾されるので、完全修飾されたモジュール名を「真のモジュール名」だと考えることができる。従って、特に、モジュールの先頭のmoduleキーワードの後には、完全なモジュール名を与えなければならない。例えば、A.B.Cというモジュールは次のように始まらなければならない。

module A.B.C

階層的モジュールを使っていて、修飾名を使いたいときは、asキーワードを使ってタイプ数を節約するのが常套手段である。例えば、次のようにである。

import qualified Control.Monad.ST.Strict as ST

階層的モジュールが使われているときにGHCがどのようにソースファイルやインタフェースファイルを探索するかについては、4.7.3. 探索パスを見よ。

GHCには、階層的に配置された大規模なライブラリ群が付属している。これについては、付属のライブラリ説明書(訳注: 未訳。web上の最新版)を見てほしい。また、HackageDBから別のライブラリを入手してインストールすることもできる。

以下の議論はSimon Peyton Jonesの元提案を短くしたものである。(この提案はパターンガードが実装される前に書かれたので、これを未実装の機能として扱っていることに注意)

有限写像を表す抽象データ型と、それについてのlookup操作があったとしよう。

lookup :: FiniteMap -> Int -> Maybe Int

lookupは、与えられたキーが写像の定義域に含まれなければNothingを返し、そうでなければ(Just v)を返す。ここでvはそのキーが対応する値である。ここで次の定義を考えよう。

clunky env var1 var2 | ok1 && ok2 = val1 + val2
| otherwise  = var1 + var2
where
  m1 = lookup env var1
  m2 = lookup env var2
  ok1 = maybeToBool m1
  ok2 = maybeToBool m2
  val1 = expectJust m1
  val2 = expectJust m2

補助関数は次のとおりである。

maybeToBool :: Maybe a -> Bool
maybeToBool (Just x) = True
maybeToBool Nothing  = False

expectJust :: Maybe a -> a
expectJust (Just x) = x
expectJust Nothing  = error "Unexpected Nothing"

clunkyは何をしているのか？ガードであるok1 && ok2は両方のlookupが成功したことを確かめている。このために、maybeToBoolを使ってMaybeを真偽値に変換している。expectJustの呼び出し(遅延評価される)は、lookupの結果から値を抽出し、返った値をval1とval2にそれぞれ束縛している。もしどちらかのlookupが失敗すると、clunkyはotherwiseの選択肢を選び、引数の和を返す。

これは確かに合法なHaskellだが、欲する結果を得るのに非常に冗長で自明でないやりかたをしている。おそらく、case式を使った方がclunkyをもっと直接的に書けるだろう。

clunky env var1 var2 = case lookup env var1 of
  Nothing -> fail
  Just val1 -> case lookup env var2 of
    Nothing -> fail
    Just val2 -> val1 + val2
where
  fail = var1 + var2

これで少し短くなったが、改善とは言えないだろう。もちろん、パターン照合やガードのついた等式をcase式に書き換えることは常にできる。これはまさに、複数の等式を持つ定義をコンパイルするときにコンパイラが行っていることである。Haskellにガードつきの等式があるのは、場合分けを一つ一つ独立に書き下していくことができるようにである。この構造はcaseを使った版では明らかでない。右辺のうちふたつは同じ(fail)だし、式全体がどんどんインデントされていっている。

私ならclunkyを次のように書く。

clunky env var1 var2
  | Just val1 <- lookup env var1
  , Just val2 <- lookup env var2
  = val1 + val2
...clunkyの他の等式...

意味は十分明快だろう。修飾子は順番に照合される。<-修飾子(パターンガードと呼ぼう)については、右辺が評価され、左辺のパターンと照合される。照合が失敗するとガードが全体として失敗し、次の等式が試みられる。成功すると、それに沿った束縛が行われ、次の修飾子が、拡張された環境の下で照合される。ただし、リスト内包表記の場合と違って、<-の右辺の式の型は左辺のパターンの型と同じである。パターンガードによって導入された束縛のスコープは、残りのガード修飾子と、その等式の右辺にわたる。

リスト内包表記の場合と同様に、パターンガード間に自由に真偽式を混ぜることができる。例えば、次のようにである。

f x | [y] <- x
    , y > 3
    , Just z <- h y
    = ...

従って、現在のHaskellのガードは、修飾子がただ一つの要素からなり、その要素が真偽式であるような、特別な場合とみなされる。

ビューパターンを有効にするフラグは-XViewPatternsである。ビューパターンに関するさらなる情報と実例はWikiのページにある。

ビューパターンは、他のパターンの中に入れ子にして使えるパターンガードに少々似ていて、抽象型に対するパターン照合の方法として便利である。例えば、プログラミング言語の実装において、その言語の型の構文を以下のように表現することがあるかもしれない。

type Typ

data TypView = Unit
             | Arrow Typ Typ

view :: Typ -> TypView

-- さらに、Typを構築するための演算が続く...

Typの表現は抽象的なままにされているので、実装では手の込んだ表現(例えば共有を管理するためのhash-consing)を使うこともできる。 ビューパターンがないと、このシグネチャを使うのは少々不便である。

size :: Typ -> Integer
size t = case view t of
  Unit -> 1
  Arrow t1 t2 -> size t1 + size t2

等式を使った関数定義は使えず、このcaseを繰り返すしかない。さらに、tに関する照合が別のパターンの深くに埋まっている場合、状況はもっと悪くなる。

ビューパターンを使うと、関数viewをパターンの中で呼んで、その結果に対して照合を行うことができる。

size (view -> Unit) = 1
size (view -> Arrow t1 t2) = size t1 + size t2

つまり、expression -> patternと書かれる新しい形式のパターンを追加したのである。これは、「照合対象にexpressionを適用し、その適用の結果をpatternに対して照合せよ」という意味である。expressionは関数の型を持つ任意のHaskellの式であり、ビューパターンはパターンが使えるところならどこにでも使える。

(exp -> pat )というパターンの意味論は以下の通り。

パターンシノニムは-XPatternSynonymsフラグによって有効になる。このフラグは、パターンシノニムを使うのと定義するのの両方に必要である。ビューパターンについてのより多くの例はWikiページにある。

パターンシノニムは、特定の形のパターンをパラメタ化して、名前を与えることを可能にする。データの表現と結びつけられていない、抽象的な構築子だと思うこともできる。例えば、プログラミング言語の実装において、その言語の型が以下のように表現されているかもしれない。

data Type = App String [Type]

この表現の例をいくつか挙げる。Type宇宙にある型のうちいくつか、以下のようにエンコードされるものを考えよ。

App "->" [t1, t2]          -- t1 -> t2
App "Int" []               -- Int
App "Maybe" [App "Int" []] -- Maybe Int

この表現は、どの型も特別扱いを受けないという点で非常に包括的である。しかし、関数によってはなんらかの既知の型を特別に扱う必要があるかもしれない。例えば、以下の関数はそれぞれ、(ネストされた)矢印型の引数の型を全て集めるものと、Int型を認識するものである。

collectArgs :: Type -> [Type]
collectArgs (App "->" [t1, t2]) = t1 : collectArgs t2
collectArgs _                   = []

isInt :: Type -> Bool
isInt (App "Int" []) = True
isInt _              = False

直接Appに対する照合を行なうのは読みにくく、書くときは間違えやすい。照合が入れ子になると、状況はさらに悪化する。

isIntEndo :: Type -> Bool
isIntEndo (App "->" [App "Int" [], App "Int" []]) = True
isIntEndo _                                       = False

パターンシノニムを使うと、表現を抽象化した形で、構築子のようにパターン照合できる照合子を公開することができる。好きな既知の型に対して、その型の表現を変えることなく、パターンシノニムを作ることができる。(これらはType型が定義されたのと同じモジュールで定義される必要がないことに注意)

pattern Arrow t1 t2 = App "->"    [t1, t2]
pattern Int         = App "Int"   []
pattern Maybe t     = App "Maybe" [t]

これによって、上の関数をずっときれいに書くことができる。

collectArgs :: Type -> [Type]
collectArgs (Arrow t1 t2) = t1 : collectArgs t2
collectArgs _             = []

isInt :: Type -> Bool
isInt Int = True
isInt _   = False

isIntEndo :: Type -> Bool
isIntEndo (Arrow Int Int) = True
isIntEndo _               = False

この例では、パターンシノニムIntおよびArrowを式としても使える(これらは双方向である)ことに注意。これは常には成り立たない。以下の構文を使うと、一方向のパターンシノニムを宣言できる。

pattern Head x <- x:xs

この場合、Head xを使うことができるのはパターン内だけで、式では使えない。なぜなら、これは右辺のxsの値を決めないからである。

一方向パターンシノニムの宣言と使用の意味論は以下の通りである

n+kパターンへの対応はデフォルトで無効になっている。有効にするには、-XNPlusKPatternsフラグが使える。

C {f = x}のような伝統的なレコード構文はデフォルトで有効になっている。無効にするには、-XNoTraditionalRecordSyntaxフラグが使える。

Haskell 98のdo記法では、再帰的な束縛が許されない。すなわち、do式中で束縛された変数は、テキスト中でそれより後ろのコードブロックからのみ可視である。let式と比較せよ。let式では、束縛変数がその束縛グループ全体から可視である。

全てではないが色々なモナドに関して、do内でのこのような再帰的束縛が実際に意味のあることだということが分かった。特に、この意味での再帰は、使われているモナドについての不動点演算子を要求する。これはControl.Monad.Fixで次のように定義されているMonadFixクラスのmfixメソッドによって表現される。

class Monad m => MonadFix m where
   mfix :: (a -> m a) -> m a

HaskellのMaybe、[] (リスト)、ST (正確版と遅延版の両方)、IOや他の多くのモナドはMonadFixインスタンスを持つ。一方、シグネチャ(a -> r) -> rを持つ継続モナドはこのインスタンスを持たない。

MonadFixに属するモナドについては、再帰的束縛を許すようなdo記法の拡張をGHCが提供する。-XRecursiveDo (言語プラグマ: RecursiveDo)がキーワードmdoとrecを含む必要な構文的サポートを提供する。この二つのキーワードはそれぞれ高水準・低水準の記法に使う。do式内の束縛とは異なり、mdoやrecによって導入される束縛は、ちょうど通常のlet式と同様に再帰的に定義される。mdoキーワードにちなんで、この記法をmdo記法とも呼ぶ。

以下は(人為的だが)単純な例である。

{-# LANGUAGE RecursiveDo #-}
justOnes = mdo { xs <- Just (1:xs)
               ; return (map negate xs) }

あるいは、以下も同等である

{-# LANGUAGE RecursiveDo #-}
justOnes = do { rec { xs <- Just (1:xs) }
              ; return (map negate xs) }

推測できるだろうが、justOnesはJust [-1,-1,-1,...に評価される。

GHCにおけるmdo記法の実装は論文A recursive do for Haskellに記述されている元々の翻訳規則に良く則っている。この論文はValue Recursion in Monadic Computationsという仕事を基礎としている。さらに、GHCは前者の論文に記述されている構文を拡張し、recキーワードで示される低水準の構文を導入する。これを次に述べる。

do { a <- getChar            do { a <- getChar
   ; let { r1 = f a r2          ; rec { r1 <- f a r2
   ;     ; r2 = g r1 }          ;     ; r2 <- g r1 }
   ; return (r1 ++ r2) }        ; return (r1 ++ r2) }

rec { b <- f a c     ===>    (b,c) <- mfix (\ ~(b,c) -> do { b <- f a c
    ; c <- f b a }                                         ; c <- f b a
                                                           ; return (b,c) })

vs <- mfix (\ ~vs -> do { ss; return vs })

mdo { a <- getChar      ===> do { a <- getChar
    ; b <- f a c                ; rec { b <- f a c
    ; c <- f b a                ;     ; c <- f b a }
    ; z <- h a b                ; z <- h a b
    ; d <- g d e                ; rec { d <- g d e
    ; e <- g a z                ;     ; e <- g a z }
    ; putChar c }               ; putChar c }

並行リスト内包表記はリスト内包表記を自然に拡張したものである。リスト内包表記は、mapとfilterを書くための扱いやすい構文と捉えることができる。並行内包表記はこれをzipWith系関数を含むように拡張するものである。

並行リスト内包表記は複数の独立した枝からなり、「|」で区切られる。それぞれの枝には修飾子が並べられる。例えば、以下のものは二つのリストをzipする。

[ (x, y) | x <- xs | y <- ys ]

結果のリストは、最も短い枝と同じ長さになる。この点で、並行リスト内包表記の振る舞いはzipのものを踏襲している。

通常の内包表記への変換を規定することによって並行リスト内包表記を定義することができる。以下に示すのは基本的な考え方である。

次のような並行内包表記があったとする。

[ e | p1 <- e11, p2 <- e12, ...
    | q1 <- e21, q2 <- e22, ...
    ...
]

これは次のように変換される。

[ e | ((p1,p2), (q1,q2), ...) <- zipN [(p1,p2) | p1 <- e11, p2 <- e12, ...]
                                      [(q1,q2) | q1 <- e21, q2 <- e22, ...]
                                      ...
]

ここで、「zipN」は、枝の数に応じた適切なzipである。

一般化リスト内包表記は、SQLでおなじみのソートやグループ化といった操作を可能にするための、リスト内包表記という構文糖に対するさらなる強化である。これは、論文Comprehensive comprehensions: comprehensions with "order by" and "group by"で完全に記述されている。ただし、我々が使う構文は論文のものと僅かに異なる。

この拡張は-XTransformListCompというフラグによって有効になる。

例を示す。

employees = [ ("Simon", "MS", 80)
, ("Erik", "MS", 100)
, ("Phil", "Ed", 40)
, ("Gordon", "Ed", 45)
, ("Paul", "Yale", 60)]

output = [ (the dept, sum salary)
| (name, dept, salary) <- employees
, then group by dept using groupWith
, then sortWith by (sum salary)
, then take 5 ]

この例では、リストoutputの値は次のようになる。

[("Yale", 60), ("Ed", 85), ("MS", 180)]

新しいキーワードが三つある。group、by、usingである。(関数sortWithとgroupWithはキーワードではない。GHC.Extsからエクスポートされている普通の関数である。)

内包表記修飾子の新しい形式が五つあり、すべて(既存の)キーワードthenで導入される。

モナド内包表記はリスト内包表記をあらゆるモナドに一般化したものである。これには並列内包表記(7.3.12. 並行リスト内包表記)と変換内包表記(7.3.13. 一般化(SQL風)リスト内包表記)を含む。

モナド内包表記は以下のものに対応する。

MonadComprehensions拡張が有効なら、これらの機能が全て有効になる。内包表記の種類と、より詳細な使い方については、前の章、7.3.13. 一般化(SQL風)リスト内包表記と7.3.12. 並行リスト内包表記に説明がある。一般に、モナド内包表記用に型[a]を型Monad m => m aに置き換えるだけで良い。

注意: これらの例示ではほとんどリストモナドしか使っていないが、モナド内包表記はあらゆるモナドに対して働く。リストに関して必要なインスタンスは全てbaseパッケージが提供する。これによってMonadComprehensionsが組み込みのリスト内包表記、変換内包表記、並列内包表記と後方互換になる。

より形式的には、脱糖は以下のように行われる。以下ではモナド内包表記[ e | Q]を脱糖したものをD[ e | Q]と書く。

式: e
宣言: d
修飾子リスト: Q,R,S

-- 基本形
D[ e | ]               = return e
D[ e | p <- e, Q ]  = e >>= \p -> D[ e | Q ]
D[ e | e, Q ]          = guard e >> \p -> D[ e | Q ]
D[ e | let d, Q ]      = let d in D[ e | Q ]

-- 並列内包表記 (並列な枝が複数あるならこれを繰り返す)
D[ e | (Q | R), S ]    = mzip D[ Qv | Q ] D[ Rv | R ] >>= \(Qv,Rv) -> D[ e | S ]

-- 変換内包表記
D[ e | Q then f, R ]                  = f D[ Qv | Q ] >>= \Qv -> D[ e | R ]

D[ e | Q then f by b, R ]             = f (\Qv -> b) D[ Qv | Q ] >>= \Qv -> D[ e | R ]

D[ e | Q then group using f, R ]      = f D[ Qv | Q ] >>= \ys ->
                                        case (fmap selQv1 ys, ..., fmap selQvn ys) of
                                 	     Qv -> D[ e | R ]

D[ e | Q then group by b using f, R ] = f (\Qv -> b) D[ Qv | Q ] >>= \ys ->
                                        case (fmap selQv1 ys, ..., fmap selQvn ys) of
                                           Qv -> D[ e | R ]

ただし、QvはQで束縛された変数(のうち後で使われるもの)のタプルであり、
       selQviはQvをその第i成分に写すセレクタである

演算子       標準の束縛             期待される型
--------------------------------------------------------------------
return       GHC.Base               t1 -> m t2
(>>=)        GHC.Base               m1 t1 -> (t2 -> m2 t3) -> m3 t3
(>>)         GHC.Base               m1 t1 -> m2 t2         -> m3 t3
guard        Control.Monad          t1 -> m t2
fmap         GHC.Base               forall a b. (a->b) -> n a -> n b
mzip         Control.Monad.Zip      forall a b. m a -> m b -> m (a,b)

内包表記は、それを脱糖したものが型検査に通るなら型検査に通るべきである。

モナド内包表記は構文の再束縛(7.3.15. 再束縛可能な構文とPreludeの暗黙インポート)に対応している。構文の再束縛なしの場合、「標準の束縛」で定義された演算子が使われる。構文の再束縛が有効な場合、各演算子は現在の字句的スコープから引かれる。例えば、並列内包表記は、スコープにある"mzip"をなんであれ使って型検査・脱糖される。

再束縛される演算子は上の表にある「期待される型」を持っていなければならない。これらの型は驚くほど一般的である。例えば、次のような型を持つバインド演算子を使うことができる。

(>>=) :: T x y a -> (a -> T y z b) -> T x z b

変換内包表記の場合には、内包表記が任意のモナドに関する物であるだけでなく、グループが任意の(fmapを持つ)型nに関してパラメタ化されている。

GHCは通常Prelude.hiを自動的にインポートする。これが嫌なら、-XNoImplicitPreludeを使うと良い。こうすれば、自分自身のPreludeをインポートすることができる。(ただし、それにPreludeという名前をつけてはいけない。Haskellではモジュールの名前空間は平坦なので、Preludeモジュールと衝突を起こしてはならないのだ)

自分で数値クラスの階層を定義するために、自作のプレリュードを実装しているとしよう。しかし、リテラルの「1」が、Haskellレポートの指定通りにPrelude.fromInteger 1を意味するとしたら、これは完全な無駄骨である。このため、-XRebindableSyntaxフラグを使った場合には、以下に挙げる組込み構文は(Preludeのものではなく)スコープにあるものならなんでも使うようになる。

-XRebindableSyntaxは、-XNoImplicitPreludeを自動的に有効にする。

どの場合でも(アロー記法は例外)、コードの静的意味は脱糖された形でのそれと等しくなるはずである。これは少々予想に反するかもしれない。例えば、368というリテラルの静的意味はfromInteger (368::Integer)のそれとまったく同じである。従って、fromIntegerは下に挙げるどんな型をもっていても良い。

fromInteger :: Integer -> Integer
fromInteger :: forall a. Foo a => Integer -> a
fromInteger :: Num a => a -> Integer
fromInteger :: Integer -> Bool -> Bool

警告: これは実験的な機能であり、通常ほど検査がなされない。脱糖されたプログラムを型検査するには-dcore-lintを使う。Core Lintが満足しているなら、問題ないはずである。

-XPostfixOperatorsフラグを使うと、演算子の左セクションの構文に小さな拡張が有効になり、これを使って後置演算子を定義することができるようになる。拡張とはこうである。以下のような左セクションがあったとしよう。

(e !)

これは、(型検査と実行の両面において)以下の式と等しい。

((!) e)

(これは式eが何であっても、また演算子(!)が何であっても成り立つ)。Haskell 98の厳密な解釈では、このセクションは以下と同等だとされる。

(\y -> (!) e y)

つまり、演算子は二引数の関数でなければならない。GHCでは一引数の関数であっても良く、結果として、関数を後置記法で書くことができるようになる。

この拡張は関数定義の左辺には及ばない。従って、このような関数を定義するときには前置形を使わなければならない。

-XTupleSectionsフラグは、タプルの構築子をPython風に部分適用することを有効にする。例として、以下のプログラム

(, True)

は、次の不恰好な表記と同じ意味の書き方とみなされる。

\x -> (x, True)

タプルの引数はどんな組み合わせで省略してもよい。以下のように。

(, "I", , , "Love", , 1337)

これは、次のように翻訳される。

\a b c d -> (a, "I", b, c, "Love", d, 1337)

unboxed tuplesを有効にしているなら、これについてもセクションが使える。例えば、

(# , True #)

非ボックス化タプルにゼロ項のものはないので、次の式

(# #)

は、変わらず非ボックス化単項タプルの構築子を意味する。

-XLambdaCaseフラグは以下の形の式を有効にする。

\case { p1 -> e1; ...; pN -> eN }

これは以下と同等である。

\freshName -> case freshName of { p1 -> e1; ...; pN -> eN }

\caseはレイアウトを開始するので、以下のように書けることに注意。

\case
  p1 -> e1
  ...
  pN -> eN

-XEmptyCaseフラグは、選択肢を持たないcase式やラムダcase式を有効にする。次のように。

    case e of { }   -- 選択肢がない
あるいは
    \case { }       -- -XLambdaCaseも必要

これは、検査対象の式がボトム以外の型を持たないことが分かっている場合に便利なことがある。例を挙げる。

data Void
f :: Void -> Int
f x = case x of { }

依存型の諸機能と一緒に使うと、より便利である(Tracを見よ)。例えば、以下の二つのabsurdの定義の候補を考えよ。

data a :==: b where
  Refl :: a :==: a

absurd :: True :~: False -> a
absurd x = error "absurd"    -- (A)
absurd x = case x of {}      -- (B)

我々は(B)の方がずっと良いと思う。なぜなら、(True :~: False)が空の型であることをGHCが発見できるからである。従って、(B)は部分関数でなく、GHCは-fwarn-incomplete-patterns付きでこれをコンパイルできるはずである(ただし、パターンマッチ検査はまだ、これができるほど賢くない)。一方で(A)は危険な感じを与えるし、この関数が実際には決して呼ばれないことをGHCが検査しない。

-XMultiWayIfフラグを使うと、GHCは以下のように複数の選択肢を持つ条件式を受け付ける。

if | guard1 -> expr1
   | ...
   | guardN -> exprN

これは、だいたい次のものと同等である。

case () of
  _ | guard1 -> expr1
  ...
  _ | guardN -> exprN

多選択肢のif式は新しいレイアウト文脈を導入する。よって、上の例は以下と同等である。

if { | guard1 -> expr1
   ; | ...
   ; | guardN -> exprN
   }

以下の式では、

if | guard1 -> if | guard2 -> expr2
                  | guard3 -> expr3
   | guard4 -> expr4

レイアウトが次のように翻訳されるので、意図通りに動く。

if { | guard1 -> if { | guard2 -> expr2
                    ; | guard3 -> expr3
                    }
   ; | guard4 -> expr4
   }

多選択肢のif式でのレイアウトは、他のレイアウト文脈と同じように働くが、相違点として、多選択肢のifのガード間のセミコロンは省略可能である。よって、全てのガードを同じ桁に揃える必要はない。これは、関数定義やcase式のガードと同じ性質である。

レコードの構築とパターンマッチにおいては、仮に同じフィールド名を持つデータ型が二つスコープにあったとしても、どのフィールドが言及されているのか全く曖昧でない。例えば以下のように。

module M where
  data S = MkS { x :: Int, y :: Bool }

module Foo where
  import M

  data T = MkT { x :: Int }

  ok1 (MkS { x = n }) = n+1   -- 曖昧でない
  ok2 n = MkT { x = n+1 }     -- 曖昧でない

  bad1 k = k { x = 3 }  -- 曖昧
  bad2 k = x k          -- 曖昧

スコープには二つのxがあるが、ok1の定義中のパターンにおけるxは、型Sのフィールドを指す他にないということが明白である。関数ok2についても同様である。しかし、bad1におけるレコード更新と、bad2におけるレコード選択では、どちらの型が意図されているか明確でない。

Haskell 98はこの四つすべてを曖昧であると見做すが、-XDisambiguateRecordFieldsが与えられると、GHCは前者二つを認める。この規則は、Haskell 98でのインスタンス宣言の規則(インスタンス宣言中のメソッド束縛の左辺のメソッド名は曖昧さなくそのクラスのメソッドを(スコープにあれば)参照し、スコープに同名の別の変数があっても構わないとする)と全く同じである。これによって、異なるモジュールから同じフィールド名を使う二つのレコードをインポートしたときに、修飾名がそこらに散らばるのを軽減できる。

詳細をいくつか。

レコード同名利用(訳注: record puns; punは「駄洒落」「語呂合わせ」の意)は、-XNamedFieldPunsフラグによって有効になる。

レコードを使うとき、フィールド名と同じ名前の変数を束縛するようなパターンを書くことがよくある。以下のような場合である。

data C = C {a :: Int}
f (C {a = a}) = a

レコード同名利用は、この変数名を省略することを可能にする。よって、上と同じことを単に次のように書くことができる。

f (C {a}) = a

つまり、レコードパターン中において、aというパターンはa = aというパターン(同じaという名前についての)に展開される。

以下のことに注意。

レコードワイルドカードは-XRecordWildCardsフラグによって有効になる。このフラグによって-XDisambiguateRecordFieldsも有効になる。

沢山のフィールドのあるレコードでは、レコードパターンにおいてフィールドをいちいち書き下すのが面倒なことがある。次のような場合である。

data C = C {a :: Int, b :: Int, c :: Int, d :: Int}
f (C {a = 1, b = b, c = c, d = d}) = b + c + d

レコードワイルドカード構文では、レコードパターン中に「..」を使えるようになる。そうすると、省略したそれぞれのfがf = fというパターンに置換される。例として、上のパターンは次のように書ける。

f (C {a = 1, ..}) = b + c + d

さらなる詳細。

Haskell 98レポートを注意深く読むと、letやwhereで導入される局所束縛の内部に結合性宣言(infix、infixl、infixr)が出現することが許されていることが分かる。しかし、このような束縛の意味論について、Haskellレポートはあまり詳しく規定していない。

GHCでは、次のように、局所束縛に結合性宣言が付属していてもよい。

let f = ...
    infixr 3 `f`
in
    ...

そして、この結合性宣言は、この束縛がスコープにあるようなあらゆる場所で適用される。例えば、let式なら、他のlet束縛の右辺とlet式の本体で適用される。また、再帰的do式(7.3.11. 再帰的do記法 )では、let文の局所結合性宣言は、束縛される名前と同様に、そのグループの全ての文に渡るスコープを持つ。

さらに、局所結合性宣言にはその名前についての局所束縛が付属「していなければならない」。次のように、別の場所で束縛された名前の結合性を設定しなおすことは不可能である。

let infixr 9 $ in ...

局所結合性宣言は技術的にHaskell 98なので、有効にするのにフラグは必要ない。

-XPackageImportsフラグが有効なら、GHCは、インポート宣言を、インポート先のモジュールが属しているべきパッケージ名で修飾することを認める。例をあげる。

import "network" Network.Socket

こうすると、networkパッケージ(のいずれかのバージョン)からNetwork.Socketをインポートすることになる。これは、同じモジュールが複数のパッケージから利用できたり、現在ビルド中のパッケージと他のパッケージの両方にあったりする場合に、インポートの曖昧性を取り除くために使うことができる。

特別なパッケージ名thisを使うと、現在ビルド中のパッケージを示すことができる。

注意: おそらく、あなたがこの機能を使う必要はないだろう。この機能は、主に我々がAPIの変更に際して後方互換なパッケージのバージョンをビルドすることができるように追加されたものである。一般的な事例では、この機能を使うと脆い依存が発生しやすい。モジュールはあるパッケージから別のパッケージに移ることがあり、その場合パッケージ修飾されたインポートは壊れるからである。

-XSafe、-XTrustworthy、-XUnsafeのいずれかのフラグを付けると、GHCはimport宣言の構文を拡張してimportキーワードの後に任意でsafeキーワードを受け取るようにする。この機能はSafe HaskellというGHC拡張の一部である。例えば、

import safe qualified Network.Socket as NS

は、Network.Socketモジュールをインポートするが、Network.Socketが安全にインポートできる場合にしかコンパイルに成功しない。importがどういう場合に安全だとみなされるかの記述は7.27. Safe Haskellを見よ。

次のようなインポートリストやエクスポートリストにおいて、

module M( f, (++) ) where ...
  import N( f, (++) ) 
  ...

fおよび(++)の各実体は値である。しかし、型演算子(7.4.4. 型演算子)が有効だと、(++)を型構築子として宣言できるようになる。この場合、これをインポートしたりエクスポートするにはどうすれば良いだろうか。

-XExplicitNamespaces拡張は、この曖昧性を取り除くため、インポートリストやエクスポートリストの中の型構築子の名前に「type」を前置することを許す。次のように。

module M( f, type (++) ) where ...
  import N( f, type (++) ) 
  ...
module N( f, type (++) ) where
  data family a ++ b = L a | R b

-XExplicitNamespacesは、-XTypeOperatorsによって有効になる。また、(なぜか)-XTypeFamiliesによっても有効になる。

専用の構文を有効にするオプションを使うと、Haskell 98で動作していたコードがコンパイルできなくなる可能性がある。これは大抵、変数名として使われていたものが予約語になることが原因である。この節では、言語拡張によって「盗まれた」構文を列挙する。ここではHaskell 98の字句構文(Haskell 98レポートを見よ)の記法と非終端記号を使っている。構文の変更については、既存の正しいプログラムに影響する可能性のあるもの(「盗まれた」構文)のみを列挙する。多くの拡張は新しい文脈自由構文を導入するが、これらの場合は例外なく、新しい構文を使って書かれたプログラムは適当なオプションなしではコンパイルできない。

専用の構文には次の二種類がある。

盗まれるのは以下の構文である。