using.xml

<?xml version="1.0" encoding="UTF-8"?>
<chapter id="using-ghc">
  <title>GHCを使う</title>

  <indexterm><primary>GHC, using</primary></indexterm>
  <indexterm><primary>using GHC</primary></indexterm>

  <sect1>
    <title>始めてみよう: プログラムをコンパイルする</title>

    <para>この章には、GHCのコマンド行構文の完全なリファレンスが、400以上のフラグも含めて書かれている。これは大きくて複雑なシステムであり、大量の詳細があるので、どこから始めれば良いのかかなり分かりにくいかもしれない。これを踏まえて、ここに入門的な節がある。以降の節で完全な構文に飛び込む前に、この節はHaskellプログラムをコンパイルするためのGHCの基本的な使い方について簡単な導入を提供する。</para>

    <para>Hallo Worldプログラムを作ってコンパイルし、実行してみよう。まず、以下のHaskellコードを含む<filename>hello.hs</filename>というファイルを作る。
    </para>

<programlisting>
main = putStrLn "Hello, World!"
</programlisting>

    <para>このプログラムをコンパイルするには、次のようにGHCを使う。</para>

<screen>
$ ghc hello.hs
</screen>

     <para>(ここで<literal>$</literal>はプロンプトを表す。これを入力しないように)。GHCは<filename>hello.hs</filename>というソースファイルをコンパイルし、<filename>hello.o</filename>という<firstterm>オブジェクトファイル</firstterm>と<firstterm>hello.hi</firstterm>という<firstterm>インタフェースファイル</firstterm>を生成する。次にこのオブジェクトファイルをGHC付属のライブラリとリンクし、Unix/Linux/Macなら<filename>hello</filename>、Windowsなら<filename>hello.exe</filename>という実行ファイルを作成する。</para>

    <para>デフォルトでは、GHCは自身の動作に関して寡黙であり、表示するのはエラーメッセージだけである。裏で何が行われているかを見たいなら、コマンド行に<option>-v</option>を追加すれば良い。
    </para>

    <para>その後、次のようにしてプログラムを実行できる。
    </para>

<screen>
$ ./hello
Hello World!
</screen>

    <para>プログラムが複数のモジュールに分かれている場合、GHCには<filename>Main</filename>モジュールが置かれているソースファイル名を教えてやれば十分である。そうすると、GHCは<literal>import</literal>宣言を分析して、プログラムを構成する他のモジュールを見付け、そのソースファイルを見付ける。これは、<literal>Main</literal>を除いて、全てのソースファイルは、その中身のモジュール名に従って名付けられなけばいけない(ドットはディレクトリ区切りに変換して)ということである。例えば、<literal>Data.Person</literal>というモジュールは、Unix/Linux/Macでは<filename>Data/Person.hs</filename>というファイルに、Windowsでは<filename>Data\Person.hs</filename>に、それぞれ置かれることになる。
    </para>
  </sect1>

  <sect1>
    <title>オプション概観</title>

    <para>GHCの振る舞いは<firstterm>オプション</firstterm>で制御される。歴史的な理由から、これはコマンド行フラグとか引数とも呼ばれる。オプションを指定する方法は次の三つである。</para>

    <sect2>
      <title>コマンド行引数</title>

      <indexterm><primary>structure, command-line</primary></indexterm>
      <indexterm><primary>command-line</primary><secondary>arguments</secondary></indexterm>
      <indexterm><primary>arguments</primary><secondary>command-line</secondary></indexterm>

      <para>GHCを起動するときは次のような形をとる。</para>

<screen>
ghc [argument...]
</screen>

      <para>コマンド行引数はオプションかファイル名のどちらかである。</para>

      <para>コマンド行オプションは<literal>-</literal>ではじまる。これをひとまとめにすることはできない。つまり、<option>-vO</option>は<option>-v -O</option>とは異なる。オプションがファイル名より先に置かれる必要はない。例えば、<literal>ghc *.o -o foo</literal>のようにである。まず全てのオプションが処理され、全てのファイルに適用される。そのため、例えば<literal>ghc -c -O1 Foo.hs -O2 Bar.hs</literal>として<filename>Foo.hs</filename>と<filename>Bar.hs</filename>に異なる最適化水準を適用するということはできない。</para>
    </sect2>

    <sect2 id="source-file-options">
      <title>ソースファイル中のコマンド行オプション</title>

      <indexterm><primary>source-file options</primary></indexterm>

      <para>ソースファイルと、それが必要とするコマンド行オプションの結合をとても強くした方が便利なことがある。例えば、あるHaskellソースファイルが意図的に名前の覆い隠しを使っているなら、それは<option>-fno-warn-name-shadowing</option>オプション付きでコンパイルされるべきである。<filename>Makefile</filename>でファイルごとのオプションの一覧を管理する代わりに、<literal>OPTIONS_GHC</literal>プラグマを使ってソースファイルに直接これを書き込むこともできる。<indexterm><primary>OPTIONS_GHC pragma</primary></indexterm></para>

<programlisting>
{-# OPTIONS_GHC -fno-warn-name-shadowing #-}
module X where
...
</programlisting>

      <para><literal>OPTIONS_GHC</literal>は<emphasis>ファイルヘッダプラグマ</emphasis>である(<xref linkend="pragmas"/>を見よ)。</para>

      <para><literal>OPTIONS_GHC</literal>の中で使えるのは<emphasis>動的な</emphasis>フラグだけである(<xref linkend="static-dynamic-flags"/>を見よ)</para>

      <para>ソースファイル中のオプションはコマンドシェルには渡されず、コンパイラが内部的に管理するコマンド行引数の配列に加えられるだけだということに注意せよ。そのため、<literal>OPTIONS_GHC</literal>の中でワイルドカードなどを使おうとすると猛烈にがっかりすることになるだろう。</para>

      <para>注意: OPTIONS_GHCの内容はコマンド行オプションの後に連結されるので、ソースファイルで与えられたオプションはコマンド行から与えられたものよりも優先される。</para>

      <para>Makefileの内容を全てソースファイルに移すのは推奨されないが、場合によっては<literal>OPTIONS_GHC</literal>プラグマを使うのが「正しい方法」である。(<option>-keep-hc-file</option>を使っていて、モジュールにOPTIONフラグがあるなら、生成された.hcファイルにOPTIONS_GHCが置かれる)</para>
    </sect2>

    <sect2>
      <title>GHCiからオプションを設定する</title>

      <para>GHCiの中から<literal>:set</literal>コマンドを使ってオプションを変更することもできる。詳しくは<xref linkend="ghci-set"/>を見よ。</para>
    </sect2>
  </sect1>

  <sect1 id="static-dynamic-flags">
    <title>静的オプション、動的オプション、モード指定オプション</title>
    <indexterm><primary>static</primary><secondary>options</secondary>
    </indexterm>
    <indexterm><primary>dynamic</primary><secondary>options</secondary>
    </indexterm>
    <indexterm><primary>mode</primary><secondary>options</secondary>
    </indexterm>

    <para>GHCのコマンド行引数は<firstterm>静的オプション</firstterm>か、<firstterm>動的オプション</firstterm>か、<firstterm>モード指定オプション</firstterm>に分類される。</para>

    <variablelist>
      <varlistentry>
        <term>モード指定フラグ</term>
	<listitem>
          <para>例えば<option>--make</option>や<option>-E</option>がこれである。モード指定フラグはコマンド行から一つだけ指定しても良い。利用可能なモードの一覧は<xref linkend="modes"/>にある。</para>
	</listitem>
      </varlistentry>
      <varlistentry>
        <term>動的フラグ</term>
	<listitem>
          <para>モード指定フラグ以外の大部分のフラグはこれに分類される。動的なフラグはコマンド行で使っても良いし、ソースファイルの<literal>OPTIONS_GHC</literal>プラグマで使っても良いし、GHCiで<literal>:set</literal>を使って設定しても良い。</para>
	</listitem>
      </varlistentry>
      <varlistentry>
	<term>静的フラグ</term>
	<listitem>
	  <para>「静的な」フラグも少しある。これは、コマンド行からのみ使うことができ、一回のGHC/GHCiの実行を通して有効である。</para>
	</listitem>
      </varlistentry>
    </variablelist>

    <para>フラグの早見表(<xref linkend="flag-reference"/>)にはそれぞれのフラグがどれに分類されるか記されている。</para>
    <para>静的でありながら、GHCiの<literal>:set</literal>コマンドで設定できるフラグも少しながらある。これは表中では&ldquo;静/<literal>:set</literal>&rdquo;と表記される。</para>
  </sect1>

  <sect1 id="file-suffixes">
    <title>意味を持つファイル接尾辞</title>

    <indexterm><primary>suffixes, file</primary></indexterm>
    <indexterm><primary>file suffixes for GHC</primary></indexterm>

    <para>「意味を持つ」接尾辞(例えば、<filename>.lhs</filename>や<filename>.o</filename>)を持つファイルは、それにしたがって「適切な」方法で処理される。</para>

    <variablelist>

      <varlistentry>
	<term><filename>.hs</filename></term>
	<listitem>
          <para>Haskellモジュール。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term>
          <filename>.lhs</filename>
          <indexterm><primary><literal>lhs</literal> suffix</primary></indexterm>
	</term>
	<listitem>
          <para>「文芸的Haskell」モジュール。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><filename>.hi</filename></term>
	<listitem>
          <para>おそらくはコンパイラによって生成された、Haskellインタフェースファイル。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><filename>.hc</filename></term>
	<listitem>
          <para>Haskellコンパイラによって生成された中間のCファイル。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><filename>.c</filename></term>
	<listitem>
          <para>Haskellコンパイラによって生成されたもの以外のCファイル。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><filename>.ll</filename></term>
	<listitem>
          <para>llvm中間言語のソースファイル。ふつうはコンパイラによって生成される。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><filename>.bc</filename></term>
	<listitem>
          <para>llvm中間言語のビットコードファイル。ふつうはコンパイラによって生成される。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><filename>.s</filename></term>
	<listitem>
          <para>アセンブリ言語のソースファイル。ふつうはコンパイラによって生成される。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><filename>.o</filename></term>
	<listitem>
          <para>アセンブラによって生成されたオブジェクトファイル。</para>
	</listitem>
      </varlistentry>
    </variablelist>

    <para>これ以外の接尾辞を持つファイル(または接尾辞を持たないファイル)はリンカに直接渡される。</para>

  </sect1>

  <sect1 id="modes">
    <title>実行モード</title>
    <indexterm><primary>help options</primary></indexterm>

    <para>GHCの振る舞いはまずモード指定フラグによって制御される。これらのフラグのうちただ一つだけを使うことができるが、コマンド行において最初のオプションである必要はない。</para>

    <para>モードフラグがない場合、コマンド行にソースファイルがあるならGHCはmakeモード(<xref linkend="make-mode"/>)に入り、そうでないならコマンド行中で指定されたオブジェクトをリンクして実行ファイルを作る。</para>

    <para>以下のモードフラグが利用できる。</para>

    <variablelist>
      <varlistentry>
	<term>
	  <cmdsynopsis><command>ghc</command>
	    <arg choice='plain'>--interactive</arg>
	  </cmdsynopsis>
          <indexterm><primary>interactive mode</primary></indexterm>
          <indexterm><primary>ghci</primary></indexterm>
	</term>
	<listitem>
          <para>対話的モード。<command>ghci</command>としても使える。対話的モードは<xref linkend="ghci"/>で詳しく説明されている。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term>
	  <cmdsynopsis><command>ghc</command>
	    <arg choice='plain'>--make</arg>
	  </cmdsynopsis>
          <indexterm><primary>make mode</primary></indexterm>
          <indexterm><primary><option>--make</option></primary></indexterm>
	</term>
	<listitem>
          <para>このモードでは、GHCは複数のモジュールから成るHaskellのプログラムを、依存性を解析しながら自動的にビルドする。単純なHaskellプログラムなら、これは<command>make</command>を使うのに比べてずっと簡単で、しかも速い。makeモードは<xref linkend="make-mode"/>で説明されている。</para>

          <para>コマンド行中に一つでもHaskellソースファイルがあるなら、このモードがデフォルトであり、この場合<option>--make</option>オプションは省略できる。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term>
	  <cmdsynopsis><command>ghc</command>
	    <arg choice='plain'>-e</arg> <arg choice='plain'><replaceable>expr</replaceable></arg>
          </cmdsynopsis>
          <indexterm><primary>eval mode</primary></indexterm>
	</term>
	<listitem>
          <para>式を評価するモード。これは対話的モードによく似ているが、評価する式は一つだけで、コマンド行から与えられる。さらなる詳細は<xref linkend="eval-mode"/>を見よ。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term>
          <cmdsynopsis>
	    <command>ghc -E</command>
	    <command>ghc -C</command>
	    <command>ghc -S</command>
	    <command>ghc -c</command>
	  </cmdsynopsis>
	  <indexterm><primary><option>-E</option></primary></indexterm>
	  <indexterm><primary><option>-C</option></primary></indexterm>
	  <indexterm><primary><option>-S</option></primary></indexterm>
	  <indexterm><primary><option>-c</option></primary></indexterm>
        </term>
	<listitem>
          <para>これは伝統的な一括処理コンパイラモードである。このモードでは、GHCは一度に一つのソースファイルをコンパイルするか、オブジェクトファイルをリンクして実行可能ファイルを作る。コマンド行でモードが指定されなかった場合も、このモードが使われる。このときは、指定されたファイルをコンパイルして、さらにリンクしてプログラムを作る、という動作になる。<xref linkend="options-order"/>を見よ。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term>
          <cmdsynopsis>
            <command>ghc -M</command>
          </cmdsynopsis>
          <indexterm><primary>dependency-generation mode</primary></indexterm>
        </term>
	<listitem>
          <para>依存性生成モード。このモードでは、GHCは<literal>Makefile</literal>で使うのに適した依存性情報を生成する。<xref linkend="makefile-dependencies"/>を見よ。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term>
          <cmdsynopsis>
            <command>ghc --mk-dll</command>
          </cmdsynopsis>
	  <indexterm><primary>DLL-creation mode</primary></indexterm>
        </term>
	<listitem>
          <para>DLL作成モード。(Windowsのみ)<xref linkend="win32-dlls-create"/>を見よ。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term>
          <cmdsynopsis>
            <command>ghc --help</command> <command>ghc -?</command>
          </cmdsynopsis>
          <indexterm><primary><option>--help</option></primary></indexterm>
        </term>
	<listitem>
          <para>使いかたに関する長いメッセージを標準出力に吐いて、終了する。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term>
          <cmdsynopsis>
            <command>ghc --show-iface <replaceable>file</replaceable></command>
          </cmdsynopsis>
          <indexterm><primary><option>----show-iface</option></primary></indexterm>
        </term>
	<listitem>
              <para><replaceable>file</replaceable>中のインタフェースを読んで、それをテキストとして<literal>stdout</literal>にダンプする。例えば、<literal>ghc --show-iface M.hi</literal>のようにする。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term>
          <cmdsynopsis>
            <command>ghc --supported-extensions</command>
            <command>ghc --supported-languages</command>
          </cmdsynopsis>
          <indexterm><primary><option>--supported-extensions</option></primary><primary><option>--supported-languages</option></primary></indexterm>
        </term>
	<listitem>
	  <para>対応している言語拡張を表示する。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term>
          <cmdsynopsis>
            <command>ghc --show-options</command>
          </cmdsynopsis>
          <indexterm><primary><option>--show-options</option></primary></indexterm>
        </term>
        <listitem>
          <para>対応しているコマンド行オプションを印字する。シェルでの自動補完のために使うことができる。</para>
        </listitem>
      </varlistentry>

      <varlistentry>
        <term>
          <cmdsynopsis>
            <command>ghc --info</command>
          </cmdsynopsis>
          <indexterm><primary><option>--info</option></primary></indexterm>
        </term>
	<listitem>
          <para>コンパイラに関する情報を表示する。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term>
          <cmdsynopsis>
            <command>ghc --version</command>
            <command>ghc -V</command>
          </cmdsynopsis>
          <indexterm><primary><option>-V</option></primary></indexterm>
          <indexterm><primary><option>--version</option></primary></indexterm>
        </term>
	<listitem>
          <para>GHCのバージョン番号を含む一行の文字列を印字する。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term>
          <cmdsynopsis>
            <command>ghc --numeric-version</command>
          </cmdsynopsis>
          <indexterm><primary><option>--numeric-version</option></primary></indexterm>
        </term>
	<listitem>
          <para>GHCの数値的なバージョン番号のみを印字する。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term>
	  <cmdsynopsis>
            <command>ghc --print-libdir</command>
          </cmdsynopsis>
          <indexterm><primary><option>--print-libdir</option></primary></indexterm>
        </term>
	<listitem>
          <para>GHCのライブラリディレクトリのパスを表示する。これはGHCのライブラリファイル、インタフェースファイル、およびインクルードファイルが置かれているディレクトリツリーの最上位である。(Unixではふつう<literal>/usr/local/lib/ghc-5.04</literal>のようなところである)これはパッケージ設定ファイルにおける<literal>libdir</literal><indexterm><primary><literal>libdir</literal></primary></indexterm>の値である。(<xref linkend="packages"/>を見よ)</para>
	</listitem>
      </varlistentry>

    </variablelist>

    <sect2 id="make-mode">
      <title><command>ghc</command> <option>--make</option>を使う</title>
      <indexterm><primary><option>--make</option></primary></indexterm>
      <indexterm><primary>separate compilation</primary></indexterm>

      <para>このモードではGHCは複数のモジュールから成るプログラムをビルドする。このとき、GHCは根となる一つ以上のモジュール(ふつうは<literal>Main</literal>だけ)から出発して依存性を追跡する。例えば、<literal>Main</literal>モジュールが<filename>Main.hs</filename>というファイルに置かれているとすると、次のようにしてこのプログラムをコンパイル・リンクすることができる。</para>

<screen>
ghc --make Main.hs
</screen>

      <para>実際には、コマンド行中にHaskellソースファイルが一つでもあり、他のモードが指定されてもいないなら、GHCは自動的にmakeモードに入るので、この例では次のように入力するだけでも良い。</para>

<screen>
ghc Main.hs
</screen>

      <para>ソースファイル名やモジュール名はいくつ指定しても良い。それらを初期モジュールとしてインポートを追いかけることで、GHCはプログラムの全てのモジュールを見つけ出す。次に、古くなったモジュールの再コンパイルが試みられ、最後に、もし<literal>Main</literal>モジュールがあるなら、プログラムはリンクされて実行可能形式になる。</para>

      <para>伝統的な<literal>Makefile</literal>に比べて、<literal>ghc --make</literal>を使うことの利点は、以下のようなことである。</para>

      <itemizedlist>
	<listitem>
          <para>コンパイルのためにGHCを再起動する必要がないので、コンパイル間で情報をキャッシュすることができる。複数のモジュールから成るプログラムを<literal>ghc --make</literal>でコンパイルすると、個々のソースファイルに対して<literal>ghc</literal>を走らせたときに比べて二倍も速いことがある。</para>
	</listitem>
	<listitem>
          <para><literal>Makefile</literal>を書く必要がない。</para>
          <indexterm><primary><literal>Makefile</literal>s</primary><secondary>avoiding</secondary></indexterm>
	</listitem>
	<listitem>
          <para>起動されるたびにGHCが依存関係を再計算するので、ソースとの整合性が失われることがない。</para>
	</listitem>
        <listitem>
          <para><literal>-j</literal>フラグを使うと、モジュールを並列にコンパイルできる。<replaceable>N</replaceable>個のジョブを並列コンパイルするには<literal>-jN</literal>と指定すれば良い。</para>
        </listitem>
      </itemizedlist>

      <para>この章でこれ以降に解説されるコマンド行オプションは全て<option>--make</option>とともに用いることができる。ただし、コマンド行から与えられたオプションは全てのソースファイルに適用されるので、単一のソースファイルにのみ適用したいオプションについては<literal>OPTIONS_GHC</literal>プラグマ(<xref linkend="source-file-options"/>を見よ)を使う必要があることに注意せよ。</para>

      <para>プログラムを追加のオブジェクト(例えばCの補助コード)にリンクする必要があるなら、そのオブジェクトファイルをコマンド行で与えれば、GHCは実行ファイルをリンクするときにそれを含める。</para>

      <para>GHCはソースファイルがあるときしか依存関係を追跡できないので、ソースコードのないモジュールがプログラムに含まれていると、たとえオブジェクトファイルとインタフェースファイルがあったとしても、GHCは文句を言うことに注意せよ。パッケージのモジュールはこの規則の例外で、ソースファイルがあってもなくても良い。</para>

      <para>プログラムのソースファイルが全て同じディレクトリにある必要はない。<option>-i</option>オプションを使ってディレクトリを探索パスに加えることができる。(<xref linkend="search-path"/>を見よ)</para>
    </sect2>

    <sect2 id="eval-mode">
      <title>式評価モード</title>

      <para>式を評価するモード。これは対話的モードによく似ているが、評価する式は一つだけで、コマンド行から<option>-e</option>オプションの引数として与えられる。</para>

<screen>
ghc -e <replaceable>expr</replaceable>
</screen>

      <para>コマンド行からHaskellソースファイルを指定することもでき、それらは対話的モードと全く同じようにロードされる。指定された式はロードされたモジュールの文脈で評価される。</para>

      <para>例えば、<literal>Main</literal>というモジュールを含むHaskellプログラムをロードして走らせるには、次のようにすれば良い。</para>

<screen>
ghc -e Main.main Main.hs
</screen>

      <para>また、このモードを、単に式を<literal>Prelude</literal>の文脈で評価するのに使うこともできる。</para>

<screen>
$ ghc -e "interact (unlines.map reverse.lines)"
hello
olleh
</screen>
    </sect2>

    <sect2 id="options-order">
      <title>一括処理コンパイラモード</title>

      <para><emphasis>一括処理</emphasis>モードでは、GHCはコマンド行で与えられた一つ以上のソースファイルをコンパイルする。</para>

      <para>コンパイルが、複数ある段階のどこから始まるかは、それぞれの入力ファイルの接尾辞によって決定される。また、どこで終わるかは、フラグによって決定される。もしこれに関連するフラグが与えられなかったときは、リンクまでの全ての段階を実行する。次の表はこれをまとめたものである。</para>

      <informaltable>
	<tgroup cols="4">
	  <colspec align="left"/>
	  <colspec align="left"/>
	  <colspec align="left"/>
	  <colspec align="left"/>

	  <thead>
	    <row>
	      <entry>コンパイルシステムの段階</entry>
	      <entry>ここから開始する接尾辞</entry>
	      <entry>ここまでで終了することを指示するフラグ</entry>
	      <entry>出力ファイル(の接尾辞)</entry>
	    </row>
	  </thead>
	  <tbody>
	    <row>
	      <entry>文芸形式プリプロセッサ</entry>
	      <entry><literal>.lhs</literal></entry>
	      <entry>-</entry>
	      <entry><literal>.hs</literal></entry>
	    </row>

	    <row>
	      <entry>Cプリプロセッサ(省略可能)</entry>
	      <entry><literal>.hs</literal> (<option>-cpp</option>が与えられたとき)</entry>
	      <entry><option>-E</option></entry>
	      <entry><literal>.hspp</literal></entry>
	    </row>

	    <row>
	      <entry>Haskellコンパイラ</entry>
	      <entry><literal>.hs</literal></entry>
	      <entry><option>-C</option>, <option>-S</option></entry>
	      <entry><literal>.hc</literal>, <literal>.s</literal></entry>
	    </row>

	    <row>
	      <entry>Cコンパイラ(省略可能)</entry>
	      <entry><literal>.hc</literal> or <literal>.c</literal></entry>
	      <entry><option>-S</option></entry>
	      <entry><literal>.s</literal></entry>
	    </row>

	    <row>
	      <entry>アセンブラ</entry>
	      <entry><literal>.s</literal></entry>
	      <entry><option>-c</option></entry>
	      <entry><literal>.o</literal></entry>
	    </row>

	    <row>
	      <entry>リンカ</entry>
	      <entry><replaceable>other</replaceable></entry>
	      <entry>-</entry>
	      <entry><filename>a.out</filename></entry>
	    </row>
	  </tbody>
	</tgroup>
      </informaltable>

      <indexterm><primary><option>-C</option></primary></indexterm>
      <indexterm><primary><option>-E</option></primary></indexterm>
      <indexterm><primary><option>-S</option></primary></indexterm>
      <indexterm><primary><option>-c</option></primary></indexterm>

      <para>そういうわけで、次のようなものがよくある起動のされかたである。</para>

<screen>
ghc -c Foo.hs
</screen>

      <para>これはHaskellソースファイル<filename>Foo.hs</filename>をコンパイルしてオブジェクトファイル<filename>Foo.o</filename>を生成する。</para>

      <para>注意: Haskellコンパイラが実際に出力するのが何かはバックエンドのコード生成器が何かによる。詳しくは、<xref linkend="code-generators"/>を見よ。</para>

      <para>注意: Cプリプロセスは省略可能であり、<option>-cpp</option><indexterm><primary><option>-cpp</option></primary></indexterm>フラグによって有効になる。詳しくは<xref linkend="c-pre-processor"/>を見よ。</para>

      <para>注意: <option>-E</option><indexterm><primary>-E option</primary></indexterm>オプションはコンパイラをプリプロセス段階まで走らせ、結果をファイルに出力する。</para>

      <sect3 id="overriding-suffixes">
        <title>ファイルに対するデフォルトの振る舞いを上書きする</title>

        <para>上記のように、GHCがファイルを処理する方法はその接尾辞による。これは<option>-x</option>オプションを使って変更できる。</para>

	<variablelist>
	  <varlistentry>
	    <term><option>-x</option> <replaceable>suffix</replaceable>
	    	      <indexterm><primary><option>-x</option></primary>
	      </indexterm></term>
	      <listitem>
                <para>コマンド行においてこれに続く全てのファイルを<replaceable>suffix</replaceable>という接尾辞を持つかのように扱う。例えば、<literal>M.my-hs</literal>というファイルにあるHaskellモジュールをコンパイルするには、<literal>ghc -c -x hs M.my-hs</literal>とすれば良い。</para>
	      </listitem>
	  </varlistentry>
	</variablelist>
      </sect3>

    </sect2>
  </sect1>

  <sect1 id="options-help">
    <title>多弁さに関するオプション</title>

    <indexterm><primary>verbosity options</primary></indexterm>

    <para><xref linkend="modes"/>にある、<option>--help</option>、<option>--version</option>、<option>--numeric-version</option>、<option>--print-libdir</option>の各モードも参照。</para>
    <variablelist>
      <varlistentry>
	<term>
          <option>-v</option>
          <indexterm><primary><option>-v</option></primary></indexterm>
        </term>
	<listitem>
          <para><option>-v</option>はGHCを<emphasis>多弁に</emphasis>する。GHCはバージョン番号を報告し、コンパイルシステムの段階ごとに、どのようにそれを起動したか(標準エラー出力に)表示する。さらに、大部分のコンパイル段階に対しても<option>-v</option>を渡し、渡されたものはバージョン番号(ほかの情報もあるかもしれない)を報告する。</para>

          <para>心よりのお願いとして、バグを報告するときは<option>-v</option>オプションを使って頂きたい！我々は常に、あなたが正しいものを正しい順序で走らせているということを最初に確かめたいのである。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term>
          <option>-v</option><replaceable>n</replaceable>
          <indexterm><primary><option>-v</option></primary></indexterm>
        </term>
	<listitem>
          <para>より正確にコンパイラの多弁さを制御するために、<option>-v</option>は省略可能な数値引数をとる。<option>-v</option>を単独で指定するのは<option>-v3</option>と同じで、そのほかの水準は以下のような意味を持っている。</para>

	  <variablelist>
	    <varlistentry>
	      <term><option>-v0</option></term>
	      <listitem>
                <para>本質的でないメッセージを表示しない。(これがデフォルトである)</para>
	      </listitem>
	    </varlistentry>

	    <varlistentry>
	      <term><option>-v1</option></term>
	      <listitem>
                <para>最小限の多弁さ。コンパイル一回毎に一行を表示する。(<option>--make</option>または<option>--interactive</option>が有効のときはこれがデフォルト)</para>
	      </listitem>
	    </varlistentry>

	    <varlistentry>
	      <term><option>-v2</option></term>
	      <listitem>
                <para>コンパイル段階が実行されるときに、その名前を印字する。(<option>-dshow-passes</option>と同等)</para>
	      </listitem>
	    </varlistentry>

	    <varlistentry>
	      <term><option>-v3</option></term>
	      <listitem>
                <para><option>-v2</option>と同じであるが、各コンパイル段階について完全なコマンド行(あれば)を印字する。</para>
	      </listitem>
	    </varlistentry>

	    <varlistentry>
	      <term><option>-v4</option></term>
	      <listitem>
                <para><option>-v3</option>と同じだが、各コンパイル段階が終わった後にその段階での中間形式でプログラムを表示する。(プリプロセスの結果とC/アセンブリファイルを除く)</para>
	      </listitem>
	    </varlistentry>
	  </variablelist>
	</listitem>
      </varlistentry>

      <varlistentry>
        <term><option>--fprint-explicit-foralls, -fprint-explicit-kinds</option>
          <indexterm><primary><option>-fprint-explicit-foralls</option></primary></indexterm>
          <indexterm><primary><option>-fprint-explicit-kinds</option></primary></indexterm>
        </term>
        <listitem>
          <para>これら二つのフラグは、エラーメッセージやGHCiにおいてGHCが型を表示する際、そのやりかたに影響する。<option>-fprint-explicit-foralls</option>は、型の最上位において明示的に(通常表示されない)<literal>forall</literal>を表示する。以下はGHCi内での例である。
<screen>
ghci> let f x = x
ghci> :t f
f :: a -> a
ghci> :set -fprint-explicit-foralls
ghci> :t f
f :: forall a. a -> a
</screen>
         <option>-fprint-explicit-kinds</option>を使うと、通常抑制される型内の種forallと種適用を表示するようになる。種多相を使っている場合、これが重要になることがある。例を挙げる。
<screen>
ghci> :set -XPolyKinds
ghci> data T a = MkT
ghci> :t MkT
MkT :: T b
ghci> :set -fprint-explicit-foralls
ghci> :t MkT
MkT :: forall (b::k). T b
ghci> :set -fprint-explicit-kinds
ghci> :t MkT
MkT :: forall (k::BOX) (b:k). T b
</screen>
         </para>
        </listitem>
      </varlistentry>

      <varlistentry>

	<term><option>-ferror-spans</option>
          <indexterm><primary><option>-ferror-spans</option></primary>
	  </indexterm>
        </term>
	<listitem>
          <para>エラーメッセージに関連する構文要素がソースで占める位置を完全に出力するようにする。通常、GHCは構文要素の先頭の位置しか報告しない。</para>

	  <para>例えば、次のものは、</para>

<screen>
test.hs:3:6: parse error on input `where'
</screen>

	  <para>以下のようになる。</para>

<screen>
test296.hs:3:6-10: parse error on input `where'
</screen>

	  <para>また、複数行に渡る区間もあり得る。</para>

<screen>
test.hs:(5,4)-(6,7):
    Conflicting definitions for `a'
    Bound at: test.hs:5:4
              test.hs:6:7
    In the binding group for: a, b, a
</screen>

          <para>行番号は一からはじまるが、カラム番号は零からはじまることに注意。これは既存の慣習に合わせたものである。(つまり、Emacsがこの方法を使っているということ)</para>
	</listitem>
      </varlistentry>

      <varlistentry>
        <term><option>-H</option><replaceable>size</replaceable>
        <indexterm><primary><option>-H</option></primary></indexterm>
        </term>
        <listitem>
          <para>ヒープの最小サイズを<replaceable>size</replaceable>にする。これは<literal>-RTS&nbsp;-H<replaceable>size</replaceable></literal>と同等である。<xref linkend="rts-options-gc"/>を見よ。</para>
        </listitem>
      </varlistentry>

      <varlistentry>
        <term><option>-Rghc-timing</option>
        <indexterm><primary><option>-Rghc-timing</option></primary></indexterm>
        </term>
        <listitem>
          <para>GHCの実行に要した時間についての統計情報の一行要約を表示する。このオプションは<literal>+RTS&nbsp;-tstderr</literal>と同等である。<xref linkend="rts-options-gc"/>を見よ。</para>
        </listitem>
      </varlistentry>
    </variablelist>
  </sect1>

  &separate;

  <sect1 id="options-sanity">
    <title>警告と正気度チェックのためのオプション</title>

    <indexterm><primary>sanity-checking options</primary></indexterm>
    <indexterm><primary>warnings</primary></indexterm>


    <para>GHCでは、いくつかのオプションを使って、致命的でないエラーメッセージ(警告ともいう)のうちどの種類のものを生成するか選ぶことができる。デフォルトでは、一般にプログラムのバグを示していることが多い警告が有効になっている。これは<option>-fwarn-overlapping-patterns</option>、<option>-fwarn-warnings-deprecations</option>、<option>-fwarn-amp</option>、<option>-fdeprecated-flags</option>、<option>-fwarn-unrecognised-pragmas</option>、<option>-fwarn-pointless-pragmas</option>、<option>-fwarn-duplicate-constraints</option>、<option>-fwarn-duplicate-exports</option>、<option>-fwarn-missing-fields</option>、<option>-fwarn-missing-methods</option>、<option>-fwarn-wrong-do-bind</option>、<option>-fwarn-unsupported-calling-conventions</option>、<option>-fwarn-dodgy-foreign-imports</option>、<option>-fwarn-inline-rule-shadowing</option>、<option>-fwarn-unsupported-llvm-version</option>である。以下のフラグは標準的な警告の「詰め合わせ」を簡単に選択するためのものである。</para>
    <variablelist>

      <varlistentry>
	<term><option>-W</option>:</term>
	<listitem>
	  <indexterm><primary>-W option</primary></indexterm>
          <para>標準的な警告に加えて、 <option>-fwarn-incomplete-patterns</option>、<option>-fwarn-dodgy-exports</option>、<option>-fwarn-dodgy-imports</option>、<option>-fwarn-unused-matches</option>、<option>-fwarn-unused-imports</option>、<option>-fwarn-unused-binds</option>を提供する。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><option>-Wall</option>:</term>
	<listitem>
	  <indexterm><primary><option>-Wall</option></primary></indexterm>
          <para>疑わしいコードであることを示し得る全ての警告オプションを有効にする。<option>-Wall</option>で有効に<emphasis>されない</emphasis>警告は、<option>-fwarn-tabs</option>、<option>-fwarn-incomplete-uni-patterns</option>、<option>-fwarn-incomplete-record-updates</option>、<option>-fwarn-monomorphism-restriction</option>、<option>-fwarn-auto-orphans</option>、<option>-fwarn-implicit-prelude</option>、<option>-fwarn-missing-local-sigs</option>、<option>-fwarn-missing-import-lists</option>である。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><option>-w</option>:</term>
	<listitem>
	  <indexterm><primary><option>-w</option></primary></indexterm>
          <para>全ての警告を、標準的なものおよび<literal>-Wall</literal>が有効にしないものも含めて、無効にする。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><option>-Werror</option>:</term>
	<listitem>
	  <indexterm><primary><option>-Werror</option></primary></indexterm>
          <para>全ての警告を致命的なエラーにする。一括コンパイルのときに警告を見逃さないようにするのに便利である。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><option>-Wwarn</option>:</term>
	<listitem>
	  <indexterm><primary><option>-Wwarn</option></primary></indexterm>
	  <para>警告を警告として扱い、エラーにしない。これはデフォルトだが、<option>-Werror</option>フラグを否定するのに便利である。</para>
	</listitem>
      </varlistentry>

    </variablelist>

    <para>以下は全ての警告オプションの説明である。なんらかの警告を無効にしたいときは、単に対応する<option>-fno-warn-...</option>をコマンド行から与えれば良い。</para>

    <variablelist>

      <varlistentry>
        <term><option>-fwarn-typed-holes</option>:</term>
        <listitem>
          <indexterm><primary><option>-fwarn-typed-holes</option></primary>
          </indexterm>
          <indexterm><primary>warnings</primary></indexterm>
            <para><literal>_</literal>から始まる未束縛の局所変数か、単独の<literal>_</literal>を式の右辺で見つけた場合、型検査に通るためにこの項がどの型を持たねばならぬかを、エラーメッセージに含める。これは、特に <link linkend="defer-type-errors">型エラーの遅延</link>と相性が良い。<xref linkend="typed-holes"/>を見よ。</para>

            <para>この警告はデフォルトで有効である。</para>
        </listitem>
      </varlistentry>


      <varlistentry>
        <term><option>-fdefer-type-errors</option>:</term>
        <listitem>
          <indexterm><primary><option>-fdefer-type-errors</option></primary>
          </indexterm>
          <indexterm><primary>warnings</primary></indexterm>
            <para>可能なかぎり多くの型エラーを実行時まで遅らせる。コンパイル時には(エラーの代わりに)警告が出る。実行時、型エラーに依存した値を使うと、実行時エラーが発生する。しかし、コードのうち型の合っている部分はすべて問題なく走らせることができる。<xref linkend="defer-type-errors"/>を見よ</para>
        </listitem>
      </varlistentry>

      <varlistentry>
        <term><option>-fhelpful-errors</option>:</term>
        <listitem>
          <indexterm><primary><option>-fhelpful-errors</option></primary>
          </indexterm>
          <indexterm><primary>warnings</primary></indexterm>
            <para>名前やパッケージがスコープにないとき、意図されていたかもしれない名前・パッケージを提案する。</para>
          <para>このオプションはデフォルトで有効である。</para>
        </listitem>
      </varlistentry>

      <varlistentry>
	<term><option>-fwarn-unrecognised-pragmas</option>:</term>
	<listitem>
	  <indexterm><primary><option>-fwarn-unrecognised-pragmas</option></primary>
	  </indexterm>
	  <indexterm><primary>warnings</primary></indexterm>
	  <indexterm><primary>pragmas</primary></indexterm>
	  <para>GHCが認識できないプラグマが使われているときに警告を発する。GHCは、自身が使うプラグマの他に、他のツールが使うことが知られているプラグマも認識する。例えば<literal>OPTIONS_HUGS</literal>や<literal>DERIVE</literal>といったものである。</para>

          <para>このオプションはデフォルトで有効である。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
        <term><option>-fwarn-pointless-pragmas</option>:</term>
        <listitem>
          <indexterm><primary><option>-fwarn-pointless-pragmas</option></primary>
          </indexterm>
          <indexterm><primary>warnings</primary></indexterm>
          <indexterm><primary>pragmas</primary></indexterm>
          <para>モジュールが効果のないプラグマを含んでいることをGHCが発見した場合に警告を発する。</para>

          <para>このオプションはデフォルトで有効である。</para>
        </listitem>
      </varlistentry>

      <varlistentry>
	<term><option>-fwarn-warnings-deprecations</option>:</term>
	<listitem>
	  <indexterm><primary><option>-fwarn-warnings-deprecations</option></primary>
	  </indexterm>
	  <indexterm><primary>warnings</primary></indexterm>
	  <indexterm><primary>deprecations</primary></indexterm>
          <para>WARNINGまたはDEPRECATEDプラグマの付いたモジュール・関数・型が使われたときに警告を発する。このプラグマについて詳しくは<xref linkend="warning-deprecated-pragma"/>を見よ。</para>

          <para>このオプションはデフォルトで有効である。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
        <term><option>-fwarn-amp</option>:</term>
        <listitem>
          <indexterm><primary><option>-fwarn-amp</option></primary>
          </indexterm>
          <indexterm><primary>amp</primary></indexterm>
          <indexterm><primary>applicative-monad proposal</primary></indexterm>
          <para>AMP(Applicative-Monad proosal)と衝突する宣言がある場合に警告する。具体的には、1. ApplicativeでないMonadインスタンス、2. AlternativeでないMonadPlusインスタンス、3. join/pure/&lt;*&gt;の独自定義。</para>

          <para>このオプションはデフォルトで有効である。</para>
        </listitem>
      </varlistentry>

      <varlistentry>
	<term><option>-fwarn-deprecated-flags</option>:</term>
	<listitem>
	  <indexterm><primary><option>-fwarn-deprecated-flags</option></primary>
	  </indexterm>
	  <indexterm><primary>deprecated-flags</primary></indexterm>
	  <para>非推奨のコマンド行フラグが使われたときに警告を発する。</para>

          <para>このオプションはデフォルトで有効である。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
        <term><option>-fwarn-unsupported-calling-conventions</option>:</term>
        <listitem>
          <indexterm><primary><option>-fwarn-unsupported-calling-conventions</option></primary>
          </indexterm>
          <para>対応していない呼び出し規約を使ったforeign宣言があると警告を発する。特に、<literal>stdcall</literal>呼び出し規約がi386以外のアーキテクチャで使われると、<literal>ccall</literal>として扱われる。</para>
        </listitem>
      </varlistentry>

      <varlistentry>
	<term><option>-fwarn-dodgy-foreign-imports</option>:</term>
	<listitem>
	  <indexterm><primary><option>-fwarn-dodgy-foreign-imports</option></primary>
	  </indexterm>
	  <para>次の形式のforeign importに対して警告を発する。</para>

<programlisting>
foreign import "f" f :: FunPtr t
</programlisting>

          <para>なぜなら、これはおそらく次のようになっているべきだからである。</para>

<programlisting>
foreign import "&amp;f" f :: FunPtr t
</programlisting>

          <para>最初の形式は、引数を取らず、「t」型のC関数へのポインタを返す(純粋な)C関数として「f」を宣言する。一方、二番目の形式は「f」自体が「t」型のC関数であると宣言する。前者は通常ミスであり、クラッシュを引き起すためデバッグが難しい。そのためこの警告がある。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><option>-fwarn-dodgy-exports</option>:</term>
	<listitem>
	  <indexterm><primary><option>-fwarn-dodgy-exports</option></primary>
	  </indexterm>
	  <para>データ型<literal>T</literal>が全ての構築子を伴って、つまり<literal>T(..)</literal>としてエクスポートされているが、それが型シノニムにすぎない場合に警告を発する。</para>
          <para>また、あるモジュールが再エクスポートされているが、そのモジュールが何もエクスポートしていない場合にも警告する。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><option>-fwarn-dodgy-imports</option>:</term>
	<listitem>
	  <indexterm><primary><option>-fwarn-dodgy-imports</option></primary>
	  </indexterm>
          <para>以下の場合に警告を発する。</para>
          <itemizedlist>
            <listitem>
              <para>データ型<literal>T</literal>が全ての構築子を伴ってインポート(つまり<literal>T(..)</literal>)されているものの、抽象的にエクスポート(つまり<literal>T</literal>)されている。</para>
            </listitem>
            <listitem>
              <para><literal>import</literal>文が、エクスポートされてない実体を(訳注: <literal>hiding</literal>で)隠した場合。</para>
            </listitem>
          </itemizedlist>
        </listitem>
      </varlistentry>

      <varlistentry>
        <term><option>-fwarn-overflowed-literals</option>:</term>
        <listitem>
          <indexterm><primary><option>-fwarn-overflowed-literals</option></primary>
          </indexterm>
          <para>リテラルがオーバーフローするであろう場合に警告する。例: <literal>300 :: Word8</literal>。
          </para>
        </listitem>
      </varlistentry>

      <varlistentry>
        <term><option>-fwarn-empty-enumerations</option>:</term>
        <listitem>
          <indexterm><primary><option>-fwarn-empty-enumerations</option></primary>
          </indexterm>
          <para>列挙が空の場合に警告する。例: <literal>[5 .. 3]</literal>.
          </para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><option>-fwarn-lazy-unlifted-bindings</option>:</term>
	<listitem>
	  <indexterm><primary><option>-fwarn-lazy-unlifted-bindings</option></primary>
	  </indexterm>
          <para>このフラグはno-opであり、GHC 7.10で削除される。</para>
        </listitem>
      </varlistentry>

      <varlistentry>
        <term><option>-fwarn-duplicate-constraints</option>:</term>
        <listitem>
          <indexterm><primary><option>-fwarn-duplicate-constraints</option></primary></indexterm>
          <indexterm><primary>duplicate constraints, warning</primary></indexterm>

          <para>型シグネチャに二重になった制約がある場合に警告する。例えば、
          <programlisting>
             f :: (Eq a, Show a, Eq a) => a -> a
          </programlisting>
          この警告は<literal>Eq a</literal>制約が二重になっていることを指摘する。
          </para>

          <para>このオプションはデフォルトで有効である。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><option>-fwarn-duplicate-exports</option>:</term>
	<listitem>
	  <indexterm><primary><option>-fwarn-duplicate-exports</option></primary></indexterm>
	  <indexterm><primary>duplicate exports, warning</primary></indexterm>
	  <indexterm><primary>export lists, duplicates</primary></indexterm>

          <para>エクスポートリスト中で重複している要素について警告する。大きなエクスポートリストを管理しているとき、そこから何かを削除したのに相変わらずそれがエクスポートされ続ける、という事態を回避するのに有用である。</para>

          <para>このオプションはデフォルトで有効である。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><option>-fwarn-hi-shadowing</option>:</term>
	<listitem>
	  <indexterm><primary><option>-fwarn-hi-shadowing</option></primary></indexterm>
	  <indexterm><primary>shadowing</primary>
	    <secondary>interface files</secondary></indexterm>

          <para>現在のディレクトリにあるモジュールやインタフェースファイルが、ライブラリディレクトリなどにある同名のものを隠しているときに警告する。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
        <term><option>-fwarn-identities</option>:</term>
	<listitem>
          <indexterm><primary><option>-fwarn-identities</option></primary></indexterm>
          <para>Preludeの数値変換が、型Tを同じ型Tに変換しているときに警告を出力するようにする。このような呼び出しはno-opであり省くことができる。以下の関数が検査される。<literal>toInteger</literal>、<literal>toRational</literal>、<literal>fromIntegral</literal>、<literal>realToFrac</literal>。
          </para>
	</listitem>
      </varlistentry>

      <varlistentry>
        <term><option>-fwarn-implicit-prelude</option>:</term>
        <listitem>
          <indexterm><primary><option>-fwarn-implicit-prelude</option></primary></indexterm>
          <indexterm><primary>implicit prelude, warning</primary></indexterm>
          <para>Preludeが暗黙にインポートされたときにコンパイラが警告するようにする。これは、Preludeモジュールを<literal>import ... Prelude ...</literal>で明示的にイポートしたり、暗黙のインポートが無効にされたりしていない限り発生する。(暗黙のインポートを無効にするには、<option>-XNoImplicitPrelude</option>か<literal>LANGUAGE NoImplicitPrelude</literal>プラグマを使う)</para>

          <para>暗黙にPreludeを参照する構文については警告が生成されない。<option>-XNoImplicitPrelude</option>によって、その構文がPreludeを参照するかどうかが変わったとしても同じである。例えば、<literal>368</literal>が<literal>Prelude.fromInteger (368::Prelude.Integer)</literal>(ここで<literal>Prelude</literal>は、コンパイル中のモジュールが何をインポートしているかに関わらず、実際のPreludeモジュールを指す)を意味したとしても警告はされない。</para>

          <para>この警告はデフォルトで無効である。</para>
        </listitem>
      </varlistentry>

      <varlistentry>
	<term><option>-fwarn-incomplete-patterns</option>,
              <option>-fwarn-incomplete-uni-patterns</option>:
        </term>
	<listitem>
	  <indexterm><primary><option>-fwarn-incomplete-patterns</option></primary></indexterm>
	  <indexterm><primary><option>-fwarn-incomplete-uni-patterns</option></primary></indexterm>
	  <indexterm><primary>incomplete patterns, warning</primary></indexterm>
	  <indexterm><primary>patterns, incomplete</primary></indexterm>

          <para><option>-fwarn-incomplete-patterns</option>は、パターン照合が実行時に失敗する可能性がある場合に警告する。下記の関数<function>g</function>は非空のリストに適用されたときに失敗するので、<option>-fwarn-incomplete-patterns</option>が有効ならコンパイラはこれについて警告を発する。

<programlisting>
g [] = 2
</programlisting>

          このオプションは少々うるさいことがあり、また常にプログラムのバグを示しているわけでもないので、デフォルトでは有効になっていない。しかし、関数を書くときは全ての場合に対応するのが一般には良い習慣とされており、これは<option>-W</option>によって有効になる。</para>

          <para>フラグ<option>-fwarn-incomplete-uni-patterns</option>はこれと似ているが、単一のパターンしか許さない構文要素、つまりラムダ式およびパターン束縛についてのみ適用される。

<programlisting>
h = \[] -> 2
Just k = f y
</programlisting>

          </para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><option>-fwarn-incomplete-record-updates</option>:</term>
	<listitem>
	  <indexterm><primary><option>-fwarn-incomplete-record-updates</option></primary></indexterm>
	  <indexterm><primary>incomplete record updates, warning</primary></indexterm>
	  <indexterm><primary>record updates, incomplete</primary></indexterm>

          <para>下記の関数<function>f</function>は<literal>Bar</literal>に適用されたときに失敗する。<option>-fwarn-incomplete-record-updates</option>が有効だと、このような場合に警告が発せられる。</para>

<programlisting>
data Foo = Foo { x :: Int }
         | Bar

f :: Foo -> Foo
f foo = foo { x = 6 }
</programlisting>

          <para>このオプションはとてもうるさいことがあり、プログラムのバグを示していないことがしばしばあるので、デフォルトでは有効にされていない。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term>
          <option>-fwarn-missing-fields</option>:
	  <indexterm><primary><option>-fwarn-missing-fields</option></primary></indexterm>
	  <indexterm><primary>missing fields, warning</primary></indexterm>
	  <indexterm><primary>fields, missing</primary></indexterm>
        </term>
	<listitem>

          <para>このオプションはデフォルトで有効であり、ラベル付きフィールドを使った構築が完全でない、つまり一つ以上のフィールドについて初期化子を欠いているときに警告する。これはエラーではないが(省略されたフィールドはボトムで初期化される)、しばしばプログラムの誤りを示している。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term>
          <option>-fwarn-missing-import-lists</option>:
	  <indexterm><primary><option>-fwarn-import-lists</option></primary></indexterm>
	  <indexterm><primary>missing import lists, warning</primary></indexterm>
	  <indexterm><primary>import lists, missing</primary></indexterm>
        </term>
	<listitem>

	  <para>qualifiedでない<literal>import</literal>宣言で、スコープに導入する実体を明示的に列挙していないものを使った場合に警告する。例を示す。</para>

<programlisting>
module M where
  import X( f )
  import Y
  import qualified Z
  p x = f x x
</programlisting>

        <para><option>-fwarn-import-lists</option>フラグは、<literal>Y</literal>のインポートについては警告するが、<literal>X</literal>については警告しない。もしモジュール<literal>Y</literal>が(たとえば)<literal>f</literal>をエクスポートするように後で変更されたら、<literal>M</literal>における<literal>f</literal>への参照が曖昧になる。<literal>Z</literal>のエクスポートを拡張しても<literal>M</literal>での曖昧性に繋がる可能性は低いので、<literal>Z</literal>のインポートについては警告は生成されない。
        </para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><option>-fwarn-missing-methods</option>:</term>
	<listitem>
	  <indexterm><primary><option>-fwarn-missing-methods</option></primary></indexterm>
	  <indexterm><primary>missing methods, warning</primary></indexterm>
	  <indexterm><primary>methods, missing</primary></indexterm>

          <para>このオプションはデフォルトで有効であり、インスタンス宣言が一つ以上のメソッドを欠いていて、しかもそのメソッドのデフォルト定義が対応するクラス宣言にないときに警告する。</para>
          <para>この警告はメソッド名がアンダースコアで始まっているときには抑止される。これが便利なのは例えば次のような場合である。
	    <programlisting>
	      class C a where
	        _simpleFn :: a -> String
	        complexFn :: a -> a -> String
	        complexFn x y = ... _simpleFn ...
	      </programlisting>
            意図は、(a) クラスの利用者は専ら<literal>complexFn</literal>を呼び、<literal>_simpleFn</literal>を呼ぶことはない。(b) インスタンス宣言では<literal>complexFn</literal>か<literal>_simpleFn</literal>のどちらかを定義すれば良い。というものである。
	    </para>
          <para>MINIMALプラグマを使うと、特定のクラスに関して、どのメソッドの組み合わせが要求されるかを変更することができる。<xref linkend="minimal-pragma"/>を見よ。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><option>-fwarn-missing-signatures</option>:</term>
	<listitem>
	  <indexterm><primary><option>-fwarn-missing-signatures</option></primary></indexterm>
	  <indexterm><primary>type signatures, missing</primary></indexterm>

          <para>全てのトップレベルの関数・値に型シグネチャがあることをGHCに確認させたいなら、<option>-fwarn-missing-signatures</option>オプションを使うと良い。警告の一部としてGHCは推論された型も報告する。これはデフォルトで無効である。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><option>-fwarn-missing-local-sigs</option>:</term>
	<listitem>
	  <indexterm><primary><option>-fwarn-missing-local-sigs</option></primary></indexterm>
	  <indexterm><primary>type signatures, missing</primary></indexterm>

	  <para><option>-fwarn-missing-local-sigs</option>フラグを使うと、GHCはあらゆる多相的な局所束縛について警告する。警告の一部としてGHCは推論された型も報告する。このオプションはデフォルトで無効である。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><option>-fwarn-name-shadowing</option>:</term>
	<listitem>
	  <indexterm><primary><option>-fwarn-name-shadowing</option></primary></indexterm>
	  <indexterm><primary>shadowing, warning</primary></indexterm>

          <para>このオプションが有効だと、内側のスコープの値と同名の外側のスコープの値があるとき、つまり内側の値が外側のものを隠すときに警告する。これはミスタイプが原因の発見しがたいバグを捕らえることがある。例えば、<literal>f = ... let f = id in ... f ...</literal>において、再帰呼び出しであるはずのものが意図せず捕捉されるというものがある。</para>
          <para>この警告は、アンダースコアで始まる名前については抑制される。例。
          <programlisting>
             f x = do { _ignore &lt;- this; _ignore &lt;- that; return (the other) }
          </programlisting>
         </para>
	</listitem>
      </varlistentry>

      <varlistentry>
        <term><option>-fwarn-orphans, -fwarn-auto-orphans</option>:</term>
	<listitem>
	  <indexterm><primary><option>-fwarn-orphans</option></primary></indexterm>
	  <indexterm><primary>orphan instances, warning</primary></indexterm>
	  <indexterm><primary>orphan rules, warning</primary></indexterm>

          <para>これらのオプションが有効なら、モジュールに「孤立した」インスタンス宣言や書き換え規則があるときに警告する。インスタンス宣言が孤立インスタンス宣言なのは、クラスおよびインスタンス化される型の両方と別のモジュールに置かれているときである。規則が孤立規則なのは、それが別のモジュールで宣言された関数についての規則であるときである。「孤立した」ものを含むモジュールは孤立モジュールと呼ばれる。</para>
          <para>問題は、孤立モジュールについては、そのインスタンスや規則が意味を持つ場合に備えて、他に理由がなくても、GHCが積極的にインタフェースファイルを読まなければいけないということである。詳しくは<xref linkend="orphan-modules"/>を参照せよ。</para>
           <para><option>-fwarn-orphans</option>フラグは、ユーザによって書かれた孤立規則や孤立インスタンスについて警告する。 <option>-fwarn-auto-orphans</option>フラグは、自動生成された孤立規則、特に型クラス(<literal>Specialise</literal>)や引数の値(<literal>-fspec-constr</literal>)についての特殊化の結果として生成されたものについて警告する。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term>
          <option>-fwarn-overlapping-patterns</option>:
          <indexterm><primary><option>-fwarn-overlapping-patterns</option></primary></indexterm>
          <indexterm><primary>overlapping patterns, warning</primary></indexterm>
          <indexterm><primary>patterns, overlapping</primary></indexterm>
        </term>
	<listitem>
          <para>デフォルトで、コンパイラはパターンが重複しているときに警告する。例えば以下のような場合である。</para>

<programlisting>
f :: String -&#62; Int
f []     = 0
f (_:xs) = 1
f "2"    = 2
</programlisting>

          <para>この場合、<function>f</function>の最後のパターン照合には決して到達しない。二番目のパターンがこれに重複しているからである。冗長なパターンはプログラマの誤りであることが、そうでない場合よりも多い。そのため、このオプションはデフォルトで有効である。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><option>-fwarn-tabs</option>:</term>
	<listitem>
	  <indexterm><primary><option>-fwarn-tabs</option></primary></indexterm>
	  <indexterm><primary>tabs, warning</primary></indexterm>
	  <para>ソースファイルにタブがあるときにコンパイラが警告するようにする。</para>

	  <para>この警告はデフォルトで無効である。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><option>-fwarn-type-defaults</option>:</term>
	<listitem>
	  <indexterm><primary><option>-fwarn-type-defaults</option></primary></indexterm>
	  <indexterm><primary>defaulting mechanism, warning</primary></indexterm>
          <para>数値型に対するデフォルト化機構が発動したときに警告・通知する。これは、あるデフォルトを前提としたコードを別のデフォルトの下のコードに変換するときに便利である。例えば、<constant>1</constant>という値に特に制約がないとき、Haskell 1.4の「デフォルトのデフォルト」は型<literal>Int</literal>を与えるが、Haskell 98以降ではこれは<literal>Integer</literal>である。これは実行時性能と挙動に影響を与える可能性があるので、通知されると便利である。</para>

	  <para>この警告はデフォルトで無効である。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><option>-fwarn-monomorphism-restriction</option>:</term>
	<listitem>
	  <indexterm><primary><option>-fwarn-monomorphism-restriction</option></primary></indexterm>
	  <indexterm><primary>monomorphism restriction, warning</primary></indexterm>
	  <para>Haskellの単相性制限が適用されるソースを書いたときにコンパイラがそれを警告/通知するようにする。単相性制限が黙って適用されると予期せぬ振る舞いの原因になることがあるので、これが適用されたという明示的な警告があると便利なことがある。</para>

	  <para>この警告はデフォルトで無効である。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><option>-fwarn-unused-binds</option>:</term>
	<listitem>
	  <indexterm><primary><option>-fwarn-unused-binds</option></primary></indexterm>
	  <indexterm><primary>unused binds, warning</primary></indexterm>
	  <indexterm><primary>binds, unused</primary></indexterm>
          <para>未使用の関数定義(および局所的な束縛)を報告する。トップレベルの関数については、その束縛がエクスポートされていない場合のみ警告される。</para>
          <para>ある定義が「使われている」のは、(a)エクスポートされている、または(b)他の使われている関数定義の右辺で言及されている、または(c)定義される関数がアンダースコアで始まっている、ときである。最後の条件のおかげで、未使用の束縛に対する警告を選択的に抑制することができる。</para>
          <para>ある変数が他の未使用の束縛の右辺に現れても、その変数は未使用だと報告される点に注意。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><option>-fwarn-unused-imports</option>:</term>
	<listitem>
	  <indexterm><primary><option>-fwarn-unused-imports</option></primary></indexterm>
	  <indexterm><primary>unused imports, warning</primary></indexterm>
	  <indexterm><primary>imports, unused</primary></indexterm>

          <para>明示的にインポートされながら使われていないモジュールを全て報告する。ただし、<literal>import M()</literal>の形のインポートは報告されない。これはインスタンス宣言(Haskellでは無名である)をインポートするための有用な決まり文句だからである。</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><option>-fwarn-unused-matches</option>:</term>
	<listitem>
	  <indexterm><primary><option>-fwarn-unused-matches</option></primary></indexterm>
	  <indexterm><primary>unused matches, warning</primary></indexterm>
	  <indexterm><primary>matches, unused</primary></indexterm>

          <para>パターン照合で発生する未使用の変数を全て報告する。これには、単一の変数から成るパターンも含む。例えば、<literal>f x y = []</literal>に対しては<varname>x</varname>と<varname>y</varname>が未使用だと報告する。この警告は変数名がアンダースコアからはじまる場合は抑制される。つまり、
	    <programlisting>
	       f _x = True
	    </programlisting>
            のような場合である。
          </para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><option>-fwarn-unused-do-bind</option>:</term>
	<listitem>
	  <indexterm><primary><option>-fwarn-unused-do-bind</option></primary></indexterm>
	  <indexterm><primary>unused do binding, warning</primary></indexterm>
	  <indexterm><primary>do binding, unused</primary></indexterm>

	  <para><literal>do</literal>および<literal>mdo</literal>ブロックの中の式が、情報を黙って捨てているように見える場合に報告する。例えば、<literal>do { mapM popInt xs ; return 10 }</literal>の場合、<literal>do</literal>ブロックの最初の文が怪しいと報告される。これの型は<literal>StackM [Int]</literal>であって<literal>StackM ()</literal>でなく、この<literal>[Int]</literal>の値が何にも束縛されていないからである。この警告は、何かを捨てていることをソースコード中で明示的に述べることによって抑制できる。
	    <programlisting>
	       do { _ &lt;- mapM popInt xs ; return 10 }
	    </programlisting>
            もちろん、この特定の場合にはもっと良い方法がある。
	    <programlisting>
	       do { mapM_ popInt xs ; return 10 }
	    </programlisting>
          </para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><option>-fwarn-wrong-do-bind</option>:</term>
	<listitem>
	  <indexterm><primary><option>-fwarn-wrong-do-bind</option></primary></indexterm>
	  <indexterm><primary>apparently erroneous do binding, warning</primary></indexterm>
	  <indexterm><primary>do binding, apparently erroneous</primary></indexterm>

	  <para><literal>do</literal>および<literal>mdo</literal>ブロックの中の式が、束縛を欠いているように見える場合に報告する。例えば、<literal>do { return (popInt 10) ; return 10 }</literal>の場合、<literal>do</literal>ブロックの最初の文が怪しいと報告される。これの型は<literal>StackM (StackM Int)</literal>(同じモナド構築子が二回適用された形)であるが、その結果を束縛することで「荷解き」がされていない。この警告は、何かを捨てていることをソースコード中で明示的に述べることによって抑制できる。
	    <programlisting>
	       do { _ &lt;- return (popInt 10) ; return 10 }
	    </programlisting>
          ほとんど全ての意味のあるプログラムについてこれはバグを示しているはずである。おそらく、意図としては次のように書きたかったのだろう。
	    <programlisting>
	       do { popInt 10 ; return 10 }
	    </programlisting>
          </para>
	</listitem>
      </varlistentry>

    </variablelist>

    <para>本当に偏執的な気分なら、<option>-dcore-lint</option>オプション<indexterm><primary><option>-dcore-lint</option></primary></indexterm>を使うと良い。これは、GHC内部でのパス内正気度チェックを有効にする。(これがチェックするのはGHCの正気であり、あなたの正気ではない)</para>

  </sect1>

  &packages;

  <sect1 id="options-optimise">
    <title>最適化(コードの改善)</title>

    <indexterm><primary>optimisation</primary></indexterm>
    <indexterm><primary>improvement, code</primary></indexterm>

    <para><option>-O*</option>オプションは便利な最適化フラグの「詰め合わせ」を指定するのに使う。後で説明される<option>-f*</option>オプションは<emphasis>個々の</emphasis>最適化を有効/無効にするのに使う。<option>-m*</option>は<emphasis>機械固有の</emphasis>最適化を有効/無効にするのに使う。</para>

    <sect2 id="optimise-pkgs">
      <title><option>-O*</option>: 便利な最適化フラグの「詰め合わせ」。</title>

      <para>GHCが生成するコードの質に影響を与えるオプションは<emphasis>大量に</emphasis>ある。大抵の人には一般的な目標しかない。つまり、「素早くコンパイルすること」であるとか「電光石火のように走るプログラムを生成すること」などである。以下に示す最適化の「詰め合わせ」を指定すれば(あるいは指定しないことを選べば)十分なはずである。</para>

      <para>注意点として、高い最適化水準では多くのモジュール間最適化が行われ、何かを変更したときにどの程度再コンパイルが必要かに影響を与える。これは開発中に非最適化を貫くことの理由の一つである。</para>

      <variablelist>

	<varlistentry>
	  <term>
            <option>-O*</option>が指定されないとき:
            <indexterm><primary>-O* not specified</primary></indexterm>
          </term>
	  <listitem>
            <para>「なるべく速くコンパイルしてほしい。できたコードの品質についてはうるさくいわない」という意味にとられる。例えば、<command>ghc -c Foo.hs</command>のような場合である。</para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term>
            <option>-O0</option>:
            <indexterm><primary><option>-O0</option></primary></indexterm>
          </term>
	  <listitem>
            <para>「全ての最適化を無効にせよ」という意味であり、<option>-O</option>が指定されていないかのような状態に戻す。<option>-O0</option>は、例えば<command>make</command>が既に<option>-O</option>をコマンド行に挿入しているときに便利である。</para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term>
            <option>-O</option>または<option>-O1</option>:
            <indexterm><primary>-O option</primary></indexterm>
            <indexterm><primary>-O1 option</primary></indexterm>
            <indexterm><primary>optimise</primary><secondary>normally</secondary></indexterm>
          </term>
	  <listitem>
            <para>「高品質のコードをそれほど時間を掛けずに生成せよ」という意味である。例えば、<command>ghc -c -O Main.lhs</command>のように使われる。</para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term>
            <option>-O2</option>:
            <indexterm><primary>-O2 option</primary></indexterm>
            <indexterm><primary>optimise</primary><secondary>aggressively</secondary></indexterm>
          </term>
	  <listitem>
            <para>「危険でない全ての最適化を適用せよ。コンパイルに非常に時間が掛かっても構わない」という意味である。</para>

            <para>避けられる「危険」な最適化とは、運が悪いときに実行時間・空間を<emphasis>悪化</emphasis>させるおそれのあるものである。通常これらは個々に設定される。</para>

            <para>現時点では、<option>-O2</option>が<option>-O</option>よりも良いコードを生成することは考えにくい。</para>
	  </listitem>
	</varlistentry>
      </variablelist>

      <para>我々は日々の作業では<option>-O*</option>を使わない。それなりの速度が必要なときは<option>-O</option>を使う。例えば、何かを計測するときなどである。「とにかくハイクオリティがいいお( ＾ω＾) 時間とか気にしないお！CPU稼働率100％でも構わないお！」というあなたには、<option>-O2</option>オプションをどうぞ。ガリガリ音を立てるPCを後にして、コーヒーを100万回飲みに行こう。(コーヒーブレイクするってレベルじゃねぇぞ！)</para>

      <para><option>-O</option>(など)が何を「実際に意味している」かを知るもっとも簡単な方法は、<option>-v</option>を付けて走らせ、驚きのあまり後ずさることである。</para>
    </sect2>

    <sect2 id="options-f">
      <title><option>-f*</option>: プラットフォーム非依存のフラグ</title>

      <indexterm><primary>-f* options (GHC)</primary></indexterm>
      <indexterm><primary>-fno-* options (GHC)</primary></indexterm>

      <para>これらのフラグは個々の最適化を有効・無効にする。これらは通常、上記の<option>-O</option>系のオプションを介して設定され、したがって、どれも明示的に指定する必要はないはずである。(実際、そうすると予期せぬ結果が訪れるかもしれない)。<option>-fhoge</option>というフラグは<option>-fno-hoge</option>とすることで打ち消せる。以下のフラグは、示されていない限りデフォルトで無効である。<xref linkend="options-f-compact"/><!-- 訳注: リンク切れ -->には小さくまとまった一覧がある。</para>

      <variablelist>
	<varlistentry>
          <term>
            <option>-favoid-vect</option>
            <indexterm><primary><option></option></primary></indexterm>
          </term>
          <listitem>
            <para><link linkend="dph">Data Parallel Haskell (DPH)</link>の一部。</para>

            <para><emphasis>デフォルトで無効。</emphasis><emphasis>ベクトル化</emphasis>回避の最適化を有効にする。この最適化は、<option>-fvectorise</option>変換と組み合わせた場合にのみ動作する。</para>

            <para>DPHを使ったコードのベクトル化は大きな改善をもたらすことが多いが、ある種のコードについては結果を悪化させることがある。この最適化は、ベクトル化変換に変更を加えて、関数をベクトル化しない方が良いかどうか判断しようとし、もしそうならそうする。</para>
          </listitem>
        </varlistentry>

        <varlistentry>
          <term>
            <option>-fcase-merge</option>
            <indexterm><primary><option></option></primary></indexterm>
          </term>
          <listitem>
            <para><emphasis>デフォルトで有効。</emphasis> 直接入れ子になったcase式の検査対象が同じ変数である場合、一つにまとめる。例
<programlisting>
  case x of
     Red -> e1
     _   -> case x of 
              Blue -> e2
              Green -> e3
==>
  case x of
     Red -> e1
     Blue -> e2
     Green -> e2
</programlisting>
            </para>
          </listitem>
        </varlistentry>

        <varlistentry>
          <term>
            <option>-fcse</option>
            <indexterm><primary><option>-fcse</option></primary></indexterm>
          </term>
	  <listitem>
            <para><emphasis>デフォルトで有効</emphasis>。共通部分式削除の最適化を有効にする。<literal>unsafePerformIO</literal>式が複数あって、共通化されたくない場合には、これを切るのが便利なことがある。</para>
	  </listitem>
	</varlistentry>

        <varlistentry>
          <term>
            <option>-fdicts-cheap</option>
            <indexterm><primary><option></option></primary></indexterm>
          </term>
          <listitem>
            <para>極めて実験的なフラグ。辞書を値に持つような式のコストを、最適化器が低く見積もるようにする。
            </para>
          </listitem>
        </varlistentry>

	<varlistentry>
	  <term>
            <option>-fdo-lambda-eta-expansion</option>
            <indexterm><primary><option></option></primary></indexterm>
          </term>
	  <listitem>
            <para><emphasis>デフォルトで有効</emphasis>。アリティを増やすためにlet束縛をη展開する。
            </para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term>
            <option>-fdo-eta-reduction</option>
            <indexterm><primary><option></option></primary></indexterm>
          </term>
	  <listitem>
            <para><emphasis>デフォルトで有効</emphasis>。ラムダ式をη簡約することで複数のラムダをまとめて除去できるなら、そうする。
            </para>
          </listitem>
        </varlistentry>

        <varlistentry>
          <term>
            <option>-feager-blackholing</option>
            <indexterm><primary><option></option></primary></indexterm>
          </term>
          <listitem>
            <para>GHCは通常スレッドを切り替える場合にのみブラックホール化を行なう。このフラグは、サンクに進入してすぐにこれを行なうようにする。<ulink url="http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel/">Haskell on a shared-memory multiprocessor</ulink>を見よ。
            </para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term><option>-fexcess-precision</option>:</term>
	  <listitem>
	    <indexterm><primary><option>-fexcess-precision</option></primary></indexterm>
            <para>このオプションが与えられると、中間の浮動小数点数が最終的な型よりも<emphasis>大きな</emphasis>精度/範囲をもつことが許される。一般にはこれは良いことだが、<literal>Float</literal>/<literal>Double</literal>の正確な精度/範囲に依存したプログラムがあるかもしれず、そのようなプログラムはこのオプションなしでコンパイルせねばならない。</para>
            <para>32ビットのx86コード生成器は、excess-precisionモードにのみ対応しているので、<option>-fexcess-precision</option>も<option>-fno-excess-precision</option>も効果を持たない。これは既知のバグである。<xref linkend="bugs-ghc" />を見よ。
            </para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term>
            <option>-fexpose-all-unfoldings</option>
            <indexterm><primary><option></option></primary></indexterm>
          </term>
	  <listitem>
            <para>実験的なフラグ。非常に大きな関数や再帰関数も含めて、すべての展開を露出する。通常GHCは大きい関数をインライン化することを避けるが、これによって、全ての関数がインライン化可能になる。</para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term>
            <option>-ffloat-in</option>
            <indexterm><primary><option></option></primary></indexterm>
          </term>
	  <listitem>
            <para><emphasis>デフォルトで有効</emphasis>。let束縛を内側、利用位置に近づく方向に移動させる。<ulink url="http://research.microsoft.com/en-us/um/people/simonpj/papers/float.ps.gz">Let-floating: moving bindings to give faster programs (ICFP'96)</ulink>を見よ。
            </para>

            <para>この最適化はlet束縛を使用位置に近づける。こうすることの利点は、letの移動先の選択肢が実行されない場合に、不要なメモリ確保を防ぐことができる点である。また、他の最適化過程が局所的により多くの情報を手にすることになるので、より効果的に働くことが可能になる。
            </para>

            <para>しかし、この最適化は常に助けになるわけではない(そのため、GHCはヒューリスティクスを使ってこれを適用すべきか決めている)。詳細は複雑だが、単純な例は、let束縛を外側に動かすことで、複数のlet束縛を単一の大きなlet束縛にまとめることができ、メモリ確保を一度に行なうことでガベッジコレクタとアロケータを助けることができる、という場合である。
            </para>
          </listitem>
        </varlistentry>

        <varlistentry>
          <term>
            <option>-ffull-laziness</option>
            <indexterm><primary><option>-ffull-laziness</option></primary></indexterm>
          </term>
          <listitem>
            <para><emphasis>デフォルトで有効</emphasis>。完全遅延最適化(let-floatingとも呼ばれる)を走らせる。これは、let束縛を、外側のラムダの外にまで浮動させることで、それが計算される回数が少なくなるように願うものである。<ulink url="http://research.microsoft.com/en-us/um/people/simonpj/papers/float.ps.gz">Let-floating: moving bindings to give faster programs (ICFP'96)</ulink>を見よ。完全遅延は共有を促進するが、これはメモリ使用量を増やすことにつながる。</para>

            <para>注意: GHCは完全遅延を完全には実装していない。最適化が有効で、<option>-fno-full-laziness</option>が与えられなかったとき、共有を促進するある種の最適化が実行される。例えば繰り返し実行される計算をループから抽出する、といったことである。これらは完全遅延の実装で行われるのと同じ変換だが、GHCは常に完全遅延を適用するとは限らないという違いがあるので、これに頼らないこと。</para>
	  </listitem>
	</varlistentry>

        <varlistentry>
          <term>
            <option>-ffun-to-thunk</option>
            <indexterm><primary><option>-ffun-to-thunk</option></primary></indexterm>
          </term>
          <listitem>
            <para>worker-wrapperは使われていない引数を削除するが、通常全ての引数を削除することはない。そうすると、関数クロージャをサンクへと変化させることになり、スペースリークを発生させたり、インライン化を阻害することになるかもしれないからである。このフラグは、worker/wrapperによって値ラムダを<emphasis>全て</emphasis>削除することを許す。デフォルトで無効。
            </para>
          </listitem>
        </varlistentry>

	<varlistentry>
	  <term><option>-fignore-asserts</option>:</term>
	  <listitem>
	    <indexterm><primary><option>-fignore-asserts</option></primary></indexterm>
            <para>ソースコード中で<literal>Exception.assert</literal>関数が使われていても無視する。(言い替えると、<literal>Exception.assert p e</literal>を<literal>e</literal>に書き換える。<xref linkend="assertions"/>を見よ)。このフラグは<option>-O</option>が指定されていると有効になる。</para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term>
            <option>-fignore-interface-pragmas</option>
	    <indexterm><primary><option>-fignore-interface-pragmas</option></primary></indexterm>
          </term>
	  <listitem>
            <para>インタフェースファイルを読むときに必須でない情報を全て無視するようにGHCに指示する。つまり、仮に<filename>M.hi</filename>に関数の展開候補や正格性情報があったとしても、GHCはその情報を無視する。</para>
	  </listitem>
	</varlistentry>

        <varlistentry>
          <term>
            <option>-flate-dmd-anal</option>
            <indexterm><primary><option>-flate-dmd-anal</option></primary></indexterm>
          </term>
          <listitem>
            <para><emphasis>デフォルトで無効。</emphasis>単純化パイプラインの最後に、要求解析(demand analysis)をもう一度走らせる。以前には見えなかった正確性を発見する機会を我々はいくつか見つけた。また、<literal>-spec-constr</literal>などの最適化が作った関数の未使用の引数を、この後段の要求解析が排除できることがある。改善はささやかであるが、コストもささやかである。<ulink href="http://ghc.haskell.org/trac/ghc/wiki/LateDmd">Tracのwikiページ</ulink>にあるメモを参照。
            </para>
            </listitem>
        </varlistentry>

        <varlistentry>
          <term>
            <option>-fliberate-case</option>
            <indexterm><primary><option>-fliberate-case</option></primary></indexterm>
          </term>
          <listitem>
            <para><emphasis>デフォルトで無効だが、-O2によって有効になる。</emphasis>liberate-case変換を有効にする。これは、再帰関数をその右辺に一回展開することで、自由変数が繰り返しcaseで検査されるのを防ぐ。これは呼び出しパターンの特殊化(<option>-fspec-constr</option>)に少し似ているが、引数でなく自由変数を対象にする。
            </para>
          </listitem>
        </varlistentry>

        <varlistentry>
          <term>
            <option>-fliberate-case-threshold=N</option>
            <indexterm><primary><option>-fliberate-case-threshold</option></primary></indexterm>
          </term>
          <listitem>
            <para>liberate-case変換における大きさの閾値を設定する。
            </para>
          </listitem>
        </varlistentry>

        <varlistentry>
          <term>
            <option>-fmax-relevant-bindings=N</option>
            <indexterm><primary><option>-fmax-relevant-bindings</option></primary></indexterm>
          </term>
          <listitem>
            <para>型検査器がエラーメッセージの中で型環境の断片を表示することがあるが、このフラグがその最大数を定める。デフォルトは6である。<option>-fno-max-relevant-bindings</option>によってこれを無効にすると無制限になる。構文的に最上位である束縛は通常除外される(通常たくさんあるので)が、<option>-fno-max-relevant-bindings</option>はそれらも含める。
            </para>
          </listitem>
        </varlistentry>

	<varlistentry>
	  <term>
            <option>-fno-state-hack</option>
            <indexterm><primary><option>-fno-state-hack</option></primary></indexterm>
          </term>
	  <listitem>
	    <para><literal>State#</literal>トークンを持つラムダを、単一進入であり、したがってその中に物をインライン化しても良いとみなす「stateハック」を無効にする。これはIOおよびSTモナドのコードの性能を向上させ得るが、共有を減らす危険を冒している。</para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term>
            <option>-fomit-interface-pragmas</option>
	    <indexterm><primary><option>-fomit-interface-pragmas</option></primary></indexterm>
          </term>
	  <listitem>
	    <para>コンパイル中のモジュール(Mとしよう)のインタフェースファイルにおいて、必須でない情報を全て省略するようにGHCに指示する。これによって、Mをインポートするモジュールからは、Mがエクスポートする関数の<emphasis>型</emphasis>しか見えず、展開候補や正格性情報などが見えなくなる。よって、例えば、Mからエクスポートされた関数が、それをインポートするモジュールでインライン化されるということがなくなる。これによる利点は、Mをインポートするモジュールを再コンパイルしなければならない頻度が減るということである。(Mのエクスポート物の型が変わった場合だけ再コンパイルすればよく、実装が変わっただけならしなくてよい)
	      </para>
	  </listitem>
	</varlistentry>

        <varlistentry>
          <term>
            <option>-fomit-yields</option>
            <indexterm><primary><option>-fomit-yields</option></primary></indexterm>
          </term>
          <listitem>
              <para><emphasis>デフォルトで有効。</emphasis>メモリ確保がされない場合、GHCがヒープ検査を省略するようにする。これはバイナリの大きさを5%ほど改善するが、スレッドがメモリ確保のないループを実行している場合、すぐには割り込まれないということも意味する。このようなスレッドに常に割り込めることが重要な場合、この最適化を無効にするべきである。また、割り込み可能性を保証したい場合、この最適化を無効にした上で全てのライブラリを再コンパイルすることを検討するべきである。
            </para>
          </listitem>
        </varlistentry>

	<varlistentry>
	  <term>
            <option>-fpedantic-bottoms</option>
            <indexterm><primary><option>-fpedantic-bottoms</option></primary></indexterm>
          </term>
	  <listitem>
	    <para>GHCがボトムをより精密に扱うようにする(ただし<option>-fno-state-hack</option>も見よ)。特に、case式を透過してイータ展開をすることがなくなる。このようなイータ展開は性能には良いが、部分適用の結果に対して<literal>seq</literal>を使っているなら悪いものになる。</para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term>
            <option>-fregs-graph</option>
            <indexterm><primary><option></option></primary></indexterm>
          </term>
	  <listitem>
            <para><emphasis>デフォルトで無効だが、-O2によって有効になる。ネイティブコード生成器との組み合わせでのみ適用される。</emphasis>ネイティブコード生成器においてグラフ彩色レジスタ割り付け器を使う。デフォルトでは、GHCはもっと単純で速い線形レジスタ割り付け器を使う。欠点は、線形割り付け器は通常、より悪いコードを生成することである。
            </para>
          </listitem>
        </varlistentry>

        <varlistentry>
          <term>
            <option>-fregs-iterative</option>
            <indexterm><primary><option></option></primary></indexterm>
          </term>
          <listitem>
            <para><emphasis>デフォルトで無効。ネイティブコード生成器との組み合わせでのみ適用される。</emphasis>ネイティブコード生成器において、反復合併グラフ彩色レジスタ割り付け器を使う。これは<option>-freg-graph</option>のものと同じレジスタ割り付け器だが、レジスタ割り付けの間に反復合併(iterative coalescing)を有効にする。
            </para>
          </listitem>
        </varlistentry>
 
	<varlistentry>
	  <term>
            <option>-fsimpl-tick-factor=<replaceable>n</replaceable></option>
            <indexterm><primary><option>-fsimpl-tick-factor</option></primary></indexterm>
          </term>
	  <listitem>
	    <para>GHCの最適化器は、停止しない書き換え規則(<xref linkend="rewrite-rules"/>)を書いたとき、または(もうすこし嫌なことに)データ型を通して再帰を組み上げた場合(<xref linkend="bugs-ghc"/>)に発散する。コンパイラが無限ループに陥るのを避けるため、最適化器は「tickの回数」を保持し、この回数が超過したときにはインライン化と書き換え規則の適用をやめる。大きいプログラムが多くのtickを使えるように、この限界はプログラムの大きさの定数倍になる。<option>-fsimpl-tick-factor</option>はこの定数を変えられるようにする。デフォルトは100である。100より大きな数はより沢山のtickを与え、100より小さい数はより少ないtickを与える。</para>
            <para>tickの数が尽きると、GHCはそれまでに実行した単純化器の歩みを要約する。<option>-fddump-simpl-stats</option>を使うとずっと詳細な一覧を生成することができる。通常これでループをかなり精密に同定することができる。いくつかの数がとても大きくなるからである。
	      </para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term>
            <option>-funfolding-creation-threshold=<replaceable>n</replaceable></option>:
	    <indexterm><primary><option>-funfolding-creation-threshold</option></primary></indexterm>
	    <indexterm><primary>inlining, controlling</primary></indexterm>
	    <indexterm><primary>unfolding, controlling</primary></indexterm>
          </term>
	  <listitem>
            <para>(デフォルト: 45)関数の展開候補(unfolding)に許される最大の大きさを定める。(展開候補には、それが呼び出し点で展開されたときの「コード膨張」のコストを反映した「大きさ」が与えられる。大きい関数ほど大きなコストを持つ)</para>
            <para>これによる影響は、(a)これより大きい物は(INLINEプラグマがない限り)決してインライン展開されない (b)これより大きい物は決してインタフェースファイルに吐かれることはない、という点である。</para>
            <para>この数値を増やしても、結果としてコードが速くなるというよりは単にコンパイル時間が長くなる公算が高い。<option>-funfolding-use-threshold</option>の方が便利である。</para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term><option>-funfolding-use-threshold=<replaceable>n</replaceable></option>:</term>
	  <listitem>
	    <indexterm><primary><option>-funfolding-use-threshold</option></primary></indexterm>
	    <indexterm><primary>inlining, controlling</primary></indexterm>
	    <indexterm><primary>unfolding, controlling</primary></indexterm>
            <para>(デフォルト: 8)これは展開(インライン化)にあたっての魔法のカットオフ値である。これより小さい関数定義は呼び出し元に展開され、これより大きい物は展開されない。関数の大きさは二つのものに依存する。式の実際の大きさと、それに適用される割引である。(<option>-funfolding-con-discount</option>を見よ<!-- 訳注: このオプションはもはや存在しない -->)</para>
            <para>これと<option>-funfolding-creation-threshold</option>の違いは、これが関数がインライン化されるかどうかを<emphasis>呼び出し地点で</emphasis>決定するのに対し、他方は将来のインライン化のために関数定義を持っておくかどうかを決定することである。
            </para>
	  </listitem>
	</varlistentry>

        <varlistentry>
          <term>
            <option>-fvectorise</option>
            <indexterm><primary><option></option></primary></indexterm>
          </term>
          <listitem>
            <para><link linkend="dph">Data Parallel Haskell (DPH)</link>の一部。</para>

            <para><emphasis>デフォルトで無効。</emphasis><emphasis>ベクトル化</emphasis>という最適化変換を有効にする。この最適化は、lDPHを使ったプログラムのネストされたデータ並列性を平坦なデータ並列性へと変換する。平坦なデータ並列プログラムはより良い負荷分散を持ち、SIMD並列性を可能にし、キャッシュに関してより友好的な振る舞いが可能になる。</para>
          </listitem>
        </varlistentry>

	<varlistentry>
	  <term>
            <option>-fspec-constr</option>
            <indexterm><primary><option>-fspec-constr</option></primary></indexterm>
          </term>
	  <listitem>
            <para><emphasis>デフォルトで無効だが、-O2によって有効になる。</emphasis>呼び出しパターンへの特殊化を有効にする。<ulink url="http://research.microsoft.com/en-us/um/people/simonpj/papers/spec-constr/index.htm">Call-pattern specialisation for Haskell programs</ulink>を見よ。</para>
            <para>この最適化は、再帰関数を、その引数の「形」に対して特殊化する。これは例を出すのが分かり易い。以下を考えよ。
<programlisting>
last :: [a] -> a
last [] = error "last"
last (x : []) = x
last (x : xs) = last xs
</programlisting>
            このコードでは、最初に空リストかどうかの検査をした後では、再帰的に呼ばれた場合にこのパターン照合が冗長であることが分かる。そういうわけで、<option>-fspec-constr</option>は上のコードを次のように変形する。
<programlisting>
last :: [a] -> a
last []       = error "last"
last (x : xs) = last' x xs
    where
      last' x []       = x
      last' x (y : ys) = last' y ys
</programlisting>
            </para>
            <para>不要なパターン照合を避けるだけでなく、これによって不要なメモリ確保が必要なくなることもある。これは、ある引数が、自己再帰呼び出しの場合には正格だが最初に呼ばれたときにはそうでないという場合にあてはまる。上の例と同様に正格で再帰的な選択肢が作られるからである。</para>
            <para>ライブラリ作者は、呼び出しパータンへの特殊化を極めて攻撃的に行なうようにGHCに指示することもできる。これはある種の高度に最適化されたライブラリに必要である。そこでは、特殊板の数やコードサイズがどうなろうとも特殊化したいと思うことがあるかもしれない。例として、<literal>vector</literal>ライブラリでの利用例を単純化したものを挙げる。</para>
<programlisting>
import GHC.Types (SPEC(..))

foldl :: (a -> b -> a) -> a -> Stream b -> a
{-# INLINE foldl #-}
foldl f z (Stream step s _) = foldl_loop SPEC z s
  where
    foldl_loop !sPEC z s = case step s of
                            Yield x s' -> foldl_loop sPEC (f z x) s'
                            Skip       -> foldl_loop sPEC z s'
                            Done       -> z
</programlisting>

            <para>ここで、ループ本体の引数として<literal>SPEC</literal>があるので、<literal>foldl</literal>の本体が呼び出し地点にインライン化された後、<literal>foldl_loop</literal>に対してGHCは非常に攻撃的な呼び出しパターン特殊化を行なう。<literal>GHC.Types</literal>で定義された<literal>SPEC</literal>はコンパイラによって特別に認識される。</para>

            <para>(注意: <literal>SPEC</literal>引数に対して<literal>seq</literal>またはびっくりパターンを使うことが非常に重要である！)</para>

            <para>特筆すべき点として、インライン化によって、ループ本体から<literal>f</literal>が直接見えるようになるので、再帰する選択肢にに関して激しい特殊化が可能になる。</para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term>
            <option>-fspecialise</option>
            <indexterm><primary><option>-fspecialise</option></primary></indexterm>
          </term>
	  <listitem>
            <para><emphasis>デフォルトで有効</emphasis>。このモジュールで定義された、型クラスによる多重定義関数それぞれを、このモジュールで使われている型について特殊化する。また、インポートされた関数でINLINABLEプラグマ(<xref linkend="inlinable-pragma"/>)を持つものを、このモジュールで呼ばれている型で特殊化する。
            </para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term>
            <option>-fstatic-argument-transformation</option>
            <indexterm><primary><option>-fstatic-argument-transformation</option></primary></indexterm>
          </term>
	  <listitem>
            <para>静的引数変換(static argument transformation)を有効にする。これは、再帰的な関数を、再帰的な局所ループを持つ非再帰関数へと変化させるものである。<ulink url="http://research.microsoft.com/en-us/um/people/simonpj/papers/santos-thesis.ps.gz">Andre Santosの博士論文</ulink>の7章を見よ。
            </para>
	  </listitem>
	</varlistentry>

	<varlistentry>
          <term>
            <option>-fstrictness</option>
            <indexterm><primary><option></option></primary></indexterm>
          </term>
	  <listitem>
            <para><emphasis>デフォルトで有効</emphasis>。正格性解析器を有効にする。GHCの正格性解析器については非常に古い論文<ulink url="http://research.microsoft.com/en-us/um/people/simonpj/papers/simple-strictnes-analyser.ps.gz">Measuring the effectiveness of a simple strictness analyser</ulink>があるが、現在のものとはかなり違いがある。</para>

            <para>正格性解析器は、どの引数と変数が関数内で「正格に」(つまり、その関数内でいずれ評価される)使われ得るかを調べる。これによって、lazyな引数に適用された場合にはプログラムの意味を変えるようなある種の最適化(非ボックス化など)をGHCが適用できるようになる。
	    </para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term>
            <option>-funbox-strict-fields</option>:
	    <indexterm><primary><option>-funbox-strict-fields</option></primary></indexterm>
	    <indexterm><primary>strict constructor fields</primary></indexterm>
	    <indexterm><primary>constructor fields, strict</primary></indexterm>
          </term>
	  <listitem>
            <para>このオプションは正格と標示された(つまり「!」)構築子フィールドを可能なら全てアンパックする。これは全ての正格な構築子フィールドに<literal>UNPACK</literal>プラグマを付けるのと同等である。(<xref linkend="unpack-pragma"/>を見よ)</para>

            <para>このオプションは少々大槌を振り回す感じがある。場合によっては状況を悪化させかねない。<literal>UNPACK</literal>を使ってフィールドを選択的に非ボックス化する方が良いかもしれない。もう一つの選択肢は、<option>-funbox-strict-fields</option>を使ってデフォルトで非ボックス化を有効にしつつ、特定の構築子フィールドについては<literal>NOUNPACK</literal>プラグマを使って無効にすることである(<xref linkend="nounpack-pragma"/>を見よ)。
            </para>
	  </listitem>
	</varlistentry>

        <varlistentry>
          <term>
            <option>-funbox-small-strict-fields</option>:
            <indexterm><primary><option>-funbox-small-strict-fields</option></primary></indexterm>
            <indexterm><primary>strict constructor fields</primary></indexterm>
            <indexterm><primary>constructor fields, strict</primary></indexterm>
          </term>
          <listitem>
            <para><emphasis>デフォルトで有効</emphasis>。このオプションは、正格であると標示(つまり「!」)された構築子フィールドで、表現がポインタ一個以下の大きさであるものを、可能なら全てアンパックする。これは、大きさの制約を満たす全ての正格なフィールドに<literal>UNPACK</literal>を付けるのと同等である。</para>

            <para>例として、以下の構築子を考えよ。
<programlisting>
data A = A !Int
data B = B !A
newtype C = C B
data D = D !C
</programlisting>
            <option>-funbox-small-strict-fields</option>が有効だと、これらのフィールドは全て、一つの<literal>Int#</literal>(<xref linkend="primitives"/>を見よ)で表現される。</para>

            <para>このオプションは、<option>-funbox-strict-fields</option>に比べて大槌を振り回す感が少ない。これが状況を悪化させることは少ないはずである。<option>-funbox-small-strict-fields</option>を使ってデフォルトでの非ボックス化を有効にしている場合、<literal>NOUNPACK</literal>を使って個々の構築子フィールドについてこれを無効にすることができる(<xref linkend="nounpack-pragma"/>を見よ)。</para>

            <para>整合性のため、32ビットのプラットフォームにおいて、<literal>Double</literal>、<literal>Word64</literal>、<literal>Int64</literal>の構築子フィールドは、技術的にはポインタよりも大きいにも関わらずアンパックされることに注意せよ。</para>
          </listitem>
        </varlistentry>

      </variablelist>

    </sect2>

  </sect1>

  &code-gens;

  &phases;

  &shared_libs;

  <sect1 id="using-concurrent">
    <title>Concurrent Haskellを使う</title>
    <indexterm><primary>Concurrent Haskell</primary><secondary>using</secondary></indexterm>

    <para>GHCはデフォルトでConcurrent Haskellをサポートしていて、特別なオプションが必要だったリ、特別な方法でコンパイルされたライブラリが必要だったりはしない。Concurrent Haskellのサポートライブラリにアクセスするには、単に<ulink url="&libraryBaseLocation;/Control-Concurrent.html"><literal>Control.Concurrent</literal></ulink>をインポートすれば良い。Concurrent Haskellについてのさらなる情報はこのモジュールの付属文書にある。</para>

    <para>任意選択で、プログラムを<option>-threaded</option>オプション(<xref linkend="options-linker" />)付きでリンクすることができる。これには以下の二つの利点がある。

          <!-- 訳注: phases.xmlに複製あり -->
          <itemizedlist>
            <listitem>
              <para>RTSオプション<option>-N</option><indexterm><primary><option>-N<replaceable>x</replaceable></option></primary><secondary>RTS option</secondary></indexterm>を使うことを可能にする。これはプログラムをマルチプロセッサ<indexterm><primary>multiprocessor</primary></indexterm><indexterm><primary>SMP</primary></indexterm>あるいはマルチコア<indexterm><primary>multicore</primary></indexterm>の機械上でスレッドを並列<indexterm><primary>parallelism</primary></indexterm>に動作させられるようにする。<xref linkend="using-smp" />を見よ。</para>
            </listitem>
            <listitem>
              <para>あるスレッドが外部呼び出しを行なったとき、(その呼び出しが<literal>unsafe</literal>と標示されていなければ)その呼び出しの実行中にプログラム中の他のHaskellスレッドが走り続ける。さらに、<literal>foreign export</literal>されたHaskell関数が複数のOSスレッドから同時に呼ばれても良い。<xref linkend="ffi-threads" />を見よ。</para>
            </listitem>
          </itemizedlist>
    </para>


    <para>以下のRTSオプションがConcurrent Haskellプログラムの振る舞いに影響する。<indexterm><primary>RTS options, concurrent</primary></indexterm></para>

    <variablelist>
      <varlistentry>
	<term><option>-C<replaceable>s</replaceable></option></term>
	<listitem>
	  <para><indexterm><primary><option>-C<replaceable>s</replaceable></option></primary><secondary>RTS option</secondary></indexterm>コンテキストスイッチの間隔を<replaceable>s</replaceable>秒に設定する。コンテキストスイッチは、時間切れの後の最初のヒープブロック確保の時点で発生する。(ヒープブロックの確保は確保4k毎に起こる)。<option>-C0</option>または<option>-C</option>を使うと、コンテキストスイッチは可能な限り頻繁に(ヒープブロックの確保の度に)発生するようになる。デフォルトでは、コンテキストスイッチは20ms毎に発生する。</para>
	</listitem>
      </varlistentry>
    </variablelist>
  </sect1>

  <sect1 id="using-smp">
    <title>SMP並列計算を使う</title>
    <indexterm><primary>parallelism</primary>
    </indexterm>
    <indexterm><primary>SMP</primary>
    </indexterm>

    <para>GHCはSMP(対称型マルチプロセッサ)上でのHaskellプログラムの並列実行をサポートしている。</para>

    <para><emphasis>並行性(concurrency)</emphasis>と<emphasis>並列性(parallelism)</emphasis>の間には明確な区別がある。並列性は、専ら、複数のプロセッサを同時に使うことでプログラムを<emphasis>速く</emphasis>することについてである。一方、並行性は抽象化の一手段である。具体的には、複数の非同期のイベントに対応せねばならないプログラムを構築するための便利な方法である。</para>

    <para>とはいうものの、この二つの用語は確かに関連している。複数のCPUを使うことで、複数の並行スレッドを並列に実行することができるようになる。GHCのSMP並列計算サポートはまさにこれを行う。しかし、並行性を利用しないプログラムにおいて、並列計算によってパフォーマンスを改善することも、また可能である。この節では、GHCを使って並列プログラムをコンパイル・実行する方法を解説し、<xref linkend="lang-parallel"/>では並列性に影響する言語機能を説明する。</para>

    <sect2 id="parallel-compile-options">
      <title>SMP並列計算に関するコンパイル時オプション</title>

      <para>複数のCPUを利用するには、プログラムが<option>-threaded</option>オプション付きでリンクされていなればならない。(<xref linkend="options-linker"/>を見よ)。加えて、以下のコンパイラオプションが並列性に影響する。</para>

      <variablelist>
        <varlistentry>
          <term><option>-feager-blackholing</option></term>
          <indexterm><primary><option>-feager-blackholing</option></primary></indexterm>
          <listitem>
          <para>ブラックホール化(blackholing)とは、サンク(遅延された計算)に、評価中という印を付ける行為である。これは三つの理由で有用である。第一に、これによって、ある種の無限ループが検出(<literal>NonTermination</literal>例外)できる。第二に、ある種のスペースリークを避けることができる。第三に、並列プログラムにおいて一つの計算を繰り返し行うことを避けることができる。これは、計算が既に実行中である場合にそうと分かるからである。</para>

          <para><option>-feager-blackholing</option>オプションは、それぞれのサンクの評価が始まってすぐにそれをブラックホール化するようにする。デフォルトは「遅延ブラックホール化」であり、こちらでは、スレッドが何らかの理由で一時停止した場合にのみサンクに評価中の印が付けられる。遅延ブラックホール化において、大部分のサンクはブラックホール化される必要がないので、典型的にはこちらの方が効率的(1-2&percnt;程度)である。しかし、並列プログラムでは積極的ブラックホール化によってより多くの計算の繰り返しを防ぐことができ、これが実際並列性にとって重要である場合がよくある。</para>

          <para>我々は、並列に走ることを意図したコードは何でも<option>-feager-blackholing</option>付きでコンパイルすることを推奨する。
          </para>
          </listitem>
        </varlistentry>
      </variablelist>
    </sect2>

    <sect2 id="parallel-options">
      <title>SMP並列性のためのRTSオプション</title>

      <para>プログラムを複数のCPU上で走らせるには二つの方法がある。プログラムから<literal>Control.Concurrent.setNumCapabilities</literal>を呼ぶか、RTSの<option>-N</option>オプションを使う。</para>

      <variablelist>
	<varlistentry>
	  <term><option>-N<optional><replaceable>x</replaceable></optional></option></term>
	  <listitem>
	    <para><indexterm><primary><option>-N<replaceable>x</replaceable></option></primary><secondary>RTS option</secondary></indexterm>プログラムの実行中、同時に<replaceable>x</replaceable>個のスレッドを使う。通常、<replaceable>x</replaceable>は機械のCPUコア数と一致するべきである<footnote><para>hyperthreadingコアの数を含めるべきかどうかは未解決の問題である。遠慮なく実験して結果を知らせてほしい。</para></footnote>。例えば、デュアルコアの機械ではおそらく<literal>+RTS -N2 -RTS</literal>を使うことになるだろう。</para>

            <para><replaceable>x</replaceable>を省略する、つまり<literal>+RTS -N -RTS</literal>とすると、マシンにあるプロセッサの数に基いてランタイムが自分で値を決定する。</para>

            <para>マシンの全てのプロセッサを使う時には注意すること。もし他のプログラムがプロセッサをいくつか使っているなら、これによってパフォーマンスを改善するどころか悪影響になることがある。</para>

            <para><option>-N</option>を設定することには、並列ガベッジコレクタを有効にするという効果もある(<xref linkend="rts-options-gc"/>を見よ)。</para>

            <para>現在の<option>-N</option>オプションの値は、<literal>Control.Concurrent.getNumCapabilities</literal>でHaskellプログラムから得られ、<literal>Control.Concurrent.setNumCapabilities</literal>を呼ぶことで実行中に変更することができる。
            </para>
	  </listitem>
	</varlistentry>
      </variablelist>

      <para>以下のオプションは、ランタイムがスレッドをCPUに割り振る方法に影響する。</para>

      <variablelist>
	<varlistentry>
	  <term><option>-qa</option></term>
          <indexterm><primary><option>-qa</option></primary><secondary>RTS
          option</secondary></indexterm>
	  <listitem>
            <para>OSのaffinity(親和性)機能を使ってOSスレッドをCPUコアに固定する。これは実験的な機能であり、有用かもしれないしそうでないかもしれない。役に立ったかどうか知らせてね！</para>
          </listitem>
        </varlistentry>
	<varlistentry>
	  <term><option>-qm</option></term>
          <indexterm><primary><option>-qm</option></primary><secondary>RTS
          option</secondary></indexterm>
	  <listitem>
            <para>負荷分散のための自動移住を無効にする。通常ランタイムは、暇なCPUを活用するため、CPUをまたいでスレッドをスケジュールしようとする。このオプションはこの振る舞いを無効にするものである。移住はスレッドにしか適用されないことに注意。<literal>par</literal>によって作られたスパークは、別途work-stealingによって負荷分散される。</para>
            <para>このオプションが役に立つのは、おそらく、並行プログラムで、<literal>Control.Concurrent.forkOn</literal>を使ってスレッドを明示的にCPUにスケジュールする場合だけだろう。</para>
          </listitem>
        </varlistentry>
       </variablelist>
    </sect2>

    <sect2>
      <title>SMP並列計算を使うにあたってのヒント</title>

      <para>プログラムを実行するときに<literal>-s</literal>というRTSオプションを加えると、時間統計情報を見ることができる。これを使って、使うCPUの数を増やしたことでプログラムが速くなったかどうかを確認できる。ユーザ(user)時間が消費(elapsed)時間よりも大きいなら、プログラムは単一のCPUよりも多くを使ったことになる。比較のために<literal>-N</literal>オプションなしでも走らせてみると良いだろう。</para>

      <para><literal>+RTS -s</literal>の出力によって、プログラムの実行中にいくつの「スパーク」(spark)が作られ、実行されたかが分かる(<xref linkend="rts-options-gc"/>を見よ)。これによって、あなたの<literal>par</literal>注釈がどの程度うまく働いているかについての感触が得られるだろう。</para>

      <para>たくさんの実験とランタイムシステムのチューニングにより、GHCの並列性サポートは6.12.1で改善された。我々は、これがあなたにとってどの程度うまく働くかを聴きたいと引き続き思っている。また、我々のベンチマーク一式に加えるための並列プログラムも収集したいと思っている。</para>
    </sect2>
  </sect1>

  <sect1 id="options-platform">
    <title>プラットフォーム固有のフラグ</title>

    <indexterm><primary>-m* options</primary></indexterm>
    <indexterm><primary>platform-specific options</primary></indexterm>
    <indexterm><primary>machine-specific options</primary></indexterm>

    <para>フラグには特定のプラットフォームでしか意味をなさないものがある。</para>

    <variablelist>

      <varlistentry>
	<term><option>-msse2</option>:</term>
	<listitem>
          <para>(x86のみ、GHC 7.0.1より追加) <link linkend="native-code-gen">ネイティブコード生成器</link>を使っているとき、浮動小数点演算の実装にSSE2のレジスタと命令セットを用いる。これは浮動小数点性能の相当な向上をもたらすが、出来たコードはSSE2対応のプロセッサ(Intel Pentium 4以降またはAMD Athlon 64以降)でしか走らない。<link linkend="llvm-code-gen">LLVMバックエンド</link>も、あなたのプロセッサが対応しているならSSE2を使うが、自動的にこれを検出するのでフラグは必要ない。
          </para>
          <para>x86-64プラットフォームでは、無条件にSSE2が使われる。</para>
        </listitem>
      </varlistentry>

      <varlistentry>
	<term><option>-msse4.2</option>:</term>
	<listitem>
          <para>(x86のみ、GHC 7.4.1より追加) <link linkend="native-code-gen">ネイティブコード生成器</link>を使っているとき、浮動小数点演算の実装にSSE4.2の命令セットを用いる。出来たコードはSSE4.2対応のプロセッサ(Intel Core i7以降)でしか走らない。<link linkend="llvm-code-gen">LLVMバックエンド</link>も、あなたのプロセッサが対応しているならSSE4.2を使うが、自動的にこれを検出するのでフラグは必要ない。
          </para>
        </listitem>
      </varlistentry>

    </variablelist>

  </sect1>

&runtime;

<sect1 id="ext-core">
  <title>外部コアファイルを生成・コンパイルする</title>

  <indexterm><primary>intermediate code generation</primary></indexterm>

  <para>GHCは、コンパイルの副作用として、最適化済み中間コード(「コア」形式と呼ぶ)をファイルに出力することができる。GHC以外のバックエンドツールがコアファイルを読んで処理することができる。このファイルは接尾辞<filename>.hcr</filename>を持つ。コア形式は<ulink url="../../core.pdf"><citetitle>An External Representation for the GHC Core Language</citetitle></ulink>に記述されており、コアファイルを操作するツールのサンプル(Haskell製)は<ulink url="http://hackage.haskell.org/package/extcore">Hackageのextcoreパッケージ</ulink>にある。<literal>.hcr</literal>ファイルの形式はデバッグのためにGHCが生成するコア出力(<xref linkend="options-debugging"/>)とは<emphasis>異なる</emphasis>ことに注意。(この二つの形式はやや似ているように見えるけれども)</para>

  <para>コア形式は注釈(note)を最初からサポートしている。注釈を加えるには、ソースコード中で<literal>CORE</literal>プラグマ(<xref linkend="pragmas"/>を見よ)を使えば良い。</para>

    <variablelist>

  	<varlistentry>
	  <term>
            <option>-fext-core</option>
            <indexterm><primary><option>-fext-core</option></primary></indexterm>
          </term>
	  <listitem>
            <para><literal>.hcr</literal>ファイルを生成する。</para>
	  </listitem>
	</varlistentry>

    </variablelist>

<para>現在(バージョン6.8.2以降)、GHCは外部コアファイルをソースとして読み込む能力を持たない。GHCにこの機能があって欲しいと思うなら、<ulink url="http://ghc.haskell.org/trac/ghc/wiki/MailingListsAndIRC">GHCチームにその願いを伝え</ulink>てほしい。</para>

</sect1>

&debug;
&flags;

</chapter>

<!-- Emacs stuff:
     ;;; Local Variables: ***
     ;;; sgml-parent-document: ("users_guide.xml" "book" "chapter") ***
     ;;; End: ***
 -->