全てのHaskellソースモジュールは専用のファイルに置かれているべきである。

ふつう、ファイル名は、モジュール名をもとにして、ドットをディレクトリ区切りに置き換えたものにされるべきである。例えば、Unixシステムでは、A.B.Cというモジュールは、なんらかの基底ディレクトリからの相対パスでA/B/C.hsというファイルに置かれるべきである。他のモジュールからインポートされる予定がないモジュールには(例えばMain)、どんな名前をつけても構わない。

GHCはソースファイルがASCIIまたはUTF-8のみだと推定し、他のエンコード方式は認識しない。しかし、UTF-8として不正な並びはコメント内部では無視されるので、Latin-1のような他のエンコード方式を、コメント以外の部分がASCIIのみから成ることを条件に使うことができる。

ソースファイルをコンパイルするとき、GHCはふつう二つのファイルを出力する。オブジェクトファイルとインタフェースファイルである。

オブジェクトファイルは通常.oで終わり、そのモジュールのコンパイル済みコードを含む。

インタフェースファイルはふつう.hiで終わり、そのモジュールに依存するモジュールをコンパイルするときに必要な情報を含む。エクスポートされた関数の型や、データ型の定義といったものがこれに含まれる。バイナリ形式なので、読もうとしないように。代わりに—-show-ifaceオプションを使うことができる。(4.7.7. インタフェースファイルに関連するその他のオプションを見よ)

オブジェクトファイルとインタフェースファイルは対になっていると考えるべきである。なぜなら、インタフェースファイルとは、ある意味で、対応するオブジェクトファイルの説明を、コンパイラ可読の形にしたものだからである。なんらかの理由でインタフェースファイルとオブジェクトファイルの間に不整合ができると、コンパイラがオブジェクトファイルについて誤った仮定を置くことになるかもしれない。こうなると、まず間違いなく厄介なことになる。このため、オブジェクトファイルとインタフェースファイルは同じ場所に置くことを推奨する。(GHCはデフォルトでこれを行うが、すぐ下で説明するようにこれを変更することもできる)

全てのモジュールには、ソースコード中で定義(module A.B.C where ...)されたモジュール名がある。

GHCが生成するオブジェクトファイルの名前は次の規則によって決められる。ただしosufはオブジェクトファイルの接尾辞(これは-osufで変えられる)である。

インタフェースファイルの名前も同じ規則で得られるが、osufの代わりにhisuf(デフォルトは.hi)が使われ、オプションは-odirと-osufではなく-hidirと-hisufである。

例えば、GHCがsrc/A/B/C.hsにあるA.B.Cモジュールを、-odirおよび-hidirフラグなしにコンパイルすると、インタフェースファイルはsrc/A/B/C.hiに置かれ、オブジェクトファイルはsrc/A/B/C.oに置かれる。

全てのインポートされたモジュールについて、インポート文におけるモジュールの名前は、4.7.3. 探索パスで説明されている方法で見付かったインタフェースファイル(またはソースファイル)に書かれているモジュールの名前と一致しなければならない。このため、大部分のモジュールでは、ソースファイル名とモジュール名は一致している必要がある。

Mainモジュールをfoo.hsという名前のファイルに置くことは問題ない。ただし、これはGHCがMainモジュールのインタフェースファイルを探すことがない(Mainモジュールはインポートされないので)からうまくゆくに過ぎないということに注意。これのおかげで、単一のディレクトリに複数のMainモジュールを持つことができ、GHCがこれによって混乱するということもない。

一括コンパイルモードでは、出力ファイルの名前を-oで指定することができるし、インタフェースファイルの名前も-ohiオプションで直接指定できる。

プログラム中では、import Fooと言うことによってモジュールFooをインポートする。--makeモードとGHCiでは、GHCはFooのソースファイルを探し、そちらを先にコンパイルするようにする。--makeが与えられなかったときは、Fooのインタフェースファイルを探す。これは、あらかじめFooをコンパイルすることで作られていなければならない。どの場合でも、GHCが適切なファイルを見つけるのに使う戦略は同じである。

戦略とはこうである。GHCは探索パスと呼ばれるディレクトリの一覧を保持している。これらのディレクトリ一つずつに対して、basename.extensionを後置し、そのファイルが存在するか調べる。basenameの値はモジュール名のドットをディレクトリ区切り(システムによって「/」または「\」)で置換したものであり、extensionは、--makeモードとGHCiではソース拡張子(hs、lhs)であり、その他ではhisufである。

例えば、探索パスにd1、d2、d3の各ディレクトリがある状況で、--makeモードでA.B.Cというモジュールのソースファイルを探しているとしよう。GHCが探すのはd1/A/B/C.hs、d1/A/B/C.lhs、d2/A/B/C.hs等々である。

デフォルトでは探索パスにはただ一つのディレクトリ「.」(つまりカレントディレクトリ)が含まれる。以下のオプションを使って、探索パスの内容を追加したり変更したりできる。

以上のことが全てではない。GHCはコンパイル済みライブラリ(パッケージと呼ばれる)からもモジュールを探す。詳細はパッケージについての節(4.9. パッケージ )を見よ。

以下のオプションは、ある種の中間ファイルをそのままにしておくのに有用である。通常、これらのファイルはコンパイル終了後にGHCによって破棄される。

昔、GHCは新しく生成された.hiを前の版と比較し、それらが同一なら、前の版をそのままにして、変更日時を変えることもしなかった。この結果、.hiが変更されていないモジュールをインポートしたモジュールは再コンパイルされなかった。

これはもはやうまく行かない。モジュールCがモジュールBをインポートし、BがモジュールAをインポートしているとしよう。このとき、モジュールAが変更されたなら、モジュールCを再コンパイルしなければならないかもしれない。したがって、A.hiが変更されたときはCが再コンパイルされるべきか確かめねばならない。しかし、Cの依存関係一覧に載るのはB.hiだけであって、A.hiではない。そのため、Aになんらかの変更(例えば、ある関数の定義が変更され、Bがエクスポートする関数のインライン展開結果にその関数が現れる場合)が加えられてもB.hiには一切の変化がないということも考えられる。そういうわけで…

GHCは、インタフェースファイルそれぞれ、およびその中の宣言それぞれについて指紋(実はMD5ハッシュ)を計算する。さらに、全てのインタフェースファイルに、最後にコンパイルされたときに使われたもの全ての指紋一覧を記録しておく。ソースファイルの変更日時が.oよりも古く(つまり最後にコンパイルされたときからソースが変更されていない)、再コンパイル検査が有効なら、GHCは賢い振る舞いをする。今回必要なものの指紋一覧と前回必要とされたものの指紋一覧(これはコンパイルされているモジュールのインタフェースファイルから拾ってくる)を比較し、全て同じなら「Compilation IS NOT required」と言ってコンパイルをかなり早い段階で中断するのである。何と美しい眺めであろうか！

GHC commentaryでこれら全てがどうやって動いているかについて読むことができる。

GHCでは相互再帰的なモジュールをコンパイルすることができる。この節ではその方法を説明する。

モジュールのインポート関係が成すグラフにおけるサイクルは全てhs-bootファイルを使って解消しなければならない。A.hsとB.hsがHaskellのソースファイルだとしよう。つまり、

module A where
    import B( TB(..) )

    newtype TA = MkTA Int

    f :: TB -> TA
    f (MkTB x) = MkTA x

module B where
    import {-# SOURCE #-} A( TA(..) )

    data TB = MkTB !Int

    g :: TA -> TB
    g (MkTA x) = MkTB x

ここでAはBをインポートしているが、BはAを{-# SOURCE #-}プラグマ付きでインポートしているので、環状の依存性が解消されている。モジュールのインポートグラフに存在する全てのループは{-# SOURCE #-}付きインポートで解消されていなければいけない。言い換えると、{-# SOURCE #-}付きインポートを無視した場合にモジュールのインポートグラフに閉路がなくなるようになっていなければならない。

このように{-# SOURCE #-}付でインポートされる全てのモジュールA.hsに対して、A.hs-bootというソースファイルが存在しなければならない。このファイルはA.hsの縮訳版を含む。つまり、

module A where
    newtype TA = MkTA Int

これらの三つのファイルをコンパイルするには、次のコマンドを発行すれば良い。

ghc -c A.hs-boot    -- A.hi-bootとA.o-bootを作る
ghc -c B.hs         -- A.hi-bootを使ってB.hiとB.oを作る
ghc -c A.hs	      -- B.hiを使ってA.hiとA.oを作る
ghc -o foo A.o B.o  -- プログラムをリンクする

ここで、いくつか注意すべきことがある。

hs-bootファイルにはブートストラップのための最小限の情報があれば良い。例えば、Aがエクスポートするもの全ての宣言を含んでいる必要はなく、Aを再帰的にインポートするモジュールが必要とするものだけで良い。

hs-bootファイルはHaskellのサブセットで書かれる。

GHCと併用するためのMakefileを用意するのは単純である。ただし、ソースファイル名とモジュール名が一致していることが前提である。

HC      = ghc
HC_OPTS = -cpp $(EXTRA_HC_OPTS)

SRCS = Main.lhs Foo.lhs Bar.lhs
OBJS = Main.o   Foo.o   Bar.o

.SUFFIXES : .o .hs .hi .lhs .hc .s

cool_pgm : $(OBJS)
        rm -f $@
        $(HC) -o $@ $(HC_OPTS) $(OBJS)

# 標準的なサフィックスルール
.o.hi:
        @:

.lhs.o:
        $(HC) -c $< $(HC_OPTS)

.hs.o:
        $(HC) -c $< $(HC_OPTS)

.o-boot.hi-boot:
        @:

.lhs-boot.o-boot:
        $(HC) -c $< $(HC_OPTS)

.hs-boot.o-boot:
        $(HC) -c $< $(HC_OPTS)

# モジュール間の依存関係
Foo.o Foo.hc Foo.s    : Baz.hi          # FooはBazをインポートしている
Main.o Main.hc Main.s : Foo.hi Baz.hi   # MainはFooとBazをインポートしている

(洗練されたmakeなら上記のことがもっと優雅にできるかもしれない。特に、gmakeのパターンルールを使えば、以下のようにより判り易く書くことができる。

%.o : %.lhs
        $(HC) -c $< $(HC_OPTS)

上記の方法はどのmakeでもうまく行くはずである。

嘘臭い.o.hiルールに注意: これはインタフェース(.hi)ファイルがソースに依存していることを記している。このルールは、.hiファイルが.oファイルから「何もしない」ことで生成されると述べている。これは実際その通りである。

サフィックスルールはHaskellソースファイルに一回、hs-bootファイル(4.7.9. 相互再帰的なモジュールをコンパイルするにはを見よ)に一回で計二回繰り返されている。

Makefileの最後にモジュール間の依存関係が書かれているが、これは次のような形をしている。

Foo.o Foo.hc Foo.s    : Baz.hi          # Foo imports Baz

これが言っているのは、もしFoo.oかFoo.hcかFoo.sのどれかついて、最終更新日時がBaz.hiよりも前ならば、そのファイルは古くなっているので更新されなければならない、ということである。更新するということになると、makeはそのためのルールを探す。そして、あらかじめ定義しておいたサフィックスルールのいずれかがうまく働く。これらの依存関係はghcを使って自動的に生成することもできる。4.7.11. 依存関係を生成するを見よ。

Foo.o : Bar.hiのようなモジュール間の依存関係を手でMakefileに書き込むのはかなり間違いやすい作業である。しかし安心してほしい。GHCは再ビルドの依存関係を自動的に生成することができる。これには、まず、以下のものをMakefileに加える。

depend :
        ghc -M $(HC_OPTS) $(SRCS)

次に、初めてコンパイルする前、およびプログラムのimportを変更したときは、make cool_pgmする前にmake dependする。これで、ghc -Mが必要な依存関係をMakefileの末尾に加える。

一般に、ghc -M Fooは次のことをする。Fooの各要素、およびFooの要素から直接・間接にインポートされている各モジュールに対して(このモジュールをMと呼ぶ)、以下のものをMakefileに加える。

Mが複数のモジュールをインポートしているなら、M.oをターゲットとする行が複数できることになる。

ghc -Mコマンドの引数として全てのモジュールを列挙する必要はない。ghcが依存性を追跡する。これはghc --makeの場合と同様である。(GHC 6.4の新機能)

ghc -Mが依存性グラフのそれぞれのモジュールのソースコードを見つける必要があることに注意せよ。そうでないと、インポート宣言をパースして依存関係を追跡することができない。したがって、ソースファイルのないコンパイル済みモジュールは全てパッケージに属していなければならない^[7]。

デフォルトでは、ghc -Mは全ての依存関係を生成し、それをmakefile(存在しなければMakefile)の末尾に連結する。この時、追加部分は「# DO NOT DELETE: Beginning of Haskell dependencies」と「# DO NOT DELETE: End of Haskell dependencies」の二行で囲われる。これらの行がすでに存在するときは、先に古い依存関係が消去される。

コンパイル時に使うのと同じ-packageオプションをghc -Mにも渡すのを忘れないように。こうすることで、依存関係生成器がパッケージ由来の被インポートモジュールの場所を把握できるようになる。ただし、パッケージモジュールは生成される依存関係には含まれない。(しかし下記の--include-pkg-depsオプションを見よ)

GHCの依存関係生成の段階にいくつかのオプションを渡すことができるので、活用すると便利かもしれない。依存関係生成器に影響を与えるオプションは以下のものである。

Haskellの規定によると、モジュールMをコンパイルするとき、M「以下」の全てのモジュールの全てのインスタンス宣言が可視である。(モジュールAがM「以下」であるとは、Aが直接Mにインポートされているか、または直接MにインポートされているモジュールBが存在して、AがB以下であることである)。したがって、理論上は、GHCはM以下の全てのモジュールのインタフェースファイルを読まなければならない。それらにMに関係するインスタンス宣言が含まれているかもしれないからである。しかし実際的にはこれは最悪なので、GHCはより賢く振る舞おうとする。

特に、あるインスタンス宣言について、その宣言の頭部(“=>”より後の部分のこと。7.6.3.3. インスタンス文脈に関する規則の緩和を見よ)で言及されている型やクラスのいずれかが、そのインスタンス宣言があるのと同じモジュールで定義されているなら、GHCはいずれにせよそのインタフェースファイルを訪れねばならない。例えば、以下のような場合である。

module A where
  instance C a => D (T a) where ...
  data T a = ...

このインスタンス宣言は型Tが使われているときのみ関係する。そして、もしTが使われているなら、GHCはTの定義を見つけるためにAのインタフェースファイルを訪れているはずである。

唯一問題になるのは、あるモジュールにインスタンス宣言があって、しかもGHCがそのモジュールを訪れる理由が他にない場合である。例えば、

module Orphan where
  instance C a => D (T a) where ...
  class C a where ...

ここでは、DもTもOrphanモジュールで宣言されていない。このようなモジュールは「孤立モジュール」と呼ばれる。GHCは孤立モジュールを認識し、モジュールをコンパイルするときにはそのモジュール以下の全ての孤立モジュールのインタフェースファイルを訪れる。この作業は大抵無駄になるが、回避する方法はない。したがって、孤立モジュールの数をなるべく減らすように努力するべきである。

関数従属によって話がややこしくなる。次のものがあったとしよう。

module B where
  instance E T Int where ...
  data T = ...

これは孤立モジュールだろうか。Tが同じモジュールで定義されているので、そうでないように見える。しかし、Eに関数従属性があったとしよう。

module Lib where
  class E x y | y -> x where ...

すると、あるモジュールMがこれをインポートしたとして、(E a Int)という制約はa = Tとすることで「改善」されねばならない。MでTが明示的に言及されていないにも関わらず、である。

このような考察から、孤立モジュールについての以下の定義が生まれた。

-fwarn-orphansフラグを使っているなら、あなたが孤立モジュールを作ったときにGHCがそれを警告する。他の警告と同様、-fno-warn-orphansとすればこの警告を無効にすることができ、-Werrorとすればこの警告が発生したときにコンパイルが失敗するようにできる。

孤立モジュールをそれと知るには、--show-ifaceモードを使ってそのインタフェースファイルM.hiを見れば良い。最初の行に[orphan module]があれば、GHCはそれを孤立モジュールだと判断している。