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

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

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

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

修飾された演算子を参照するための新しい構文をHaskell'に導入することが計画されており、GHCでは-XNewQualifiedOperatorsオプションによって有効になる。この新しい構文では、修飾された演算子を前置形式で使うときはmodule.(symbol)と書く。(Haskell 98ではこれは(module.symbol)になる)。また、中置形式で使うときは`module.(symbol)`と書く。(Haskell 98では`module.symbol`である)。例を挙げる。

  add x y = Prelude.(+) x y
  subtract y = (`Prelude.(-)` y)

この新しい形式は、Prelude..のような奇妙な例を排除することで、構文を規則的にすることを意図している。例えば、NewQualifiedOperatorsが有効なとき、[Monday..]という列の生成をスペース無しで書くことができる。Haskell 98では、これはMondayというモジュールの「.」という演算子を参照することになる。

-XNewQualifiedOperatorsが有効なとき、古いHaskell 98形式の演算子の修飾構文は受け付けられないので、このオプションは既存のHaskell 98コードを壊す可能性がある。

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 :: Type -> TypeView

-- さらに、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 )というパターンの意味論は以下の通り。

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

Haskell 98のdo記法では、再帰的な束縛が許されない。すなわち、do式中で束縛された変数は、テキスト中でそれより後ろのコードブロックからのみ可視である。これに対して、let式では、束縛変数がその束縛グループ全体から可視である。do記法でも再帰的束縛ができると恩恵を被る応用がいくつかあると分かった。これに必要な構文的なサポートが-XDoRecによって提供される。

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

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

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

再帰的do記法の動機と背景は、A recursive do for Haskell, by Levent Erkok, John Launchbury, Haskell Workshop 2002, pages: 29-37. Pittsburgh, Pennsylvaniaに記されている。モナドの値再帰の背後にある理論については、ErkokのthesisであるValue Recursion in Monadic Computationsがさらなる説明を与えている。ただし、GHCの使う構文はこれらの文書にあるものと異なっていることに注意。

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) }

並行リスト内包表記はリスト内包表記を自然に拡張したものである。リスト内包表記は、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
, then sortWith by (sum salary)
, then take 5 ]

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

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

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

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

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 #)

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

  (# #)

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

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

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.8. 再帰的do記法 )では、let文の局所結合性宣言は、束縛される名前と同様に、そのグループの全ての文に渡るスコープを持つ。

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

let infixr 9 $ in ...

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

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

import "network" Network.Socket

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

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

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

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

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