\chapter{ラムダ計算と型システム}
\label{chapter:type}
\ref{chapter:cbc} では CbC のモデル検査的検証アプローチとして、akasha を用いた有限の要素数の挿入時の仕様の検証を行なった。
しかし、さらに多くの要素を検証したり無限回の挿入を検証するには状態の抽象化や CbC 側に記号実行の機構を組み込んだり証明を行なう必要がある。
CbC は直接自身を証明する機構が存在しない。
プログラムの性質を証明するには CbC の形式的な定義が必須となる。
\ref{chapter:type} 章ではCbC の項の形式的な定義の一つとして、部分型を用いて CbC の CodeSegment と DataSegment が定義できることを示していく。
また、型システムの別の利用方法として命題が型で表現できる Curry-Howard 対応を利用した証明が存在するが、その利用方法については\ref{chapter:agda}章で述べる。

% {{{ 型システムとは
\section{型システムとは}
型システムとは、計算する値を分類することにでプログラムがある種の振舞いを行なわないことを保証する機構の事である\cite{Pierce:2002:TPL:509043}\cite{pierce2013型システム入門プログラミング言語と型の理論}。
ある種の振舞いとはプログラム中の評価不可能な式や、言語として未定義な式などが当て嵌まる。
例えば、gcc や clang といったコンパイラは関数定義時に指定された引数の型と呼び出し時の値の型が異なる時に警告を出す。
% TODO: C の warning?
この警告は関数が受けつける範囲以外の値をプログラマが渡してしまった場合などに有効に働く。
加えて、関数を定義する側も受け付ける値の範囲を限定できるため関数内部の処理を記述しやすい。

型システムで行なえることには以下のようなものが存在する。

\begin{itemize}
    \item エラーの検出

        文字列演算を行なう関数に整数を渡してしまったり、データの単位を間違えてしまったり、複雑な場合分けで境界条件を見落すなど、プログラマの不注意が型の不整合となって早期に指摘できる。
        この指摘できる詳細さは、型システムの表現力とプログラムの内容に依存する。
        多用なデータ構造を扱うプログラム(コンパイラのような記号処理アプリケーションなど)は数値計算のような数種類の単純な型しか使わないプログラムよりも型検査器から受けられる恩恵が大きい。
        他にも、ある種のプログラムにとっては型は保守のためのツールともなる。
        複雑なデータ構造を変更する時、その構造に関連するソースコードを型検査器は明らかにしてくれる。

    \item 抽象化

        型は大規模プログラムの抽象化の単位にもなる。
        例えば特定のデータ構造に対する処理をモジュール化し、パッケージングすることができる。
        モジュール化されたデータ構造は厳格に定義されたインターフェースを経由して呼び出すことになる。
        このインターフェースは利用する側に取っては呼び出しの規約となり、実装する側にとってはモジュールの要約となる。

    \item ドキュメント化

        型はプログラムを理解する際にも有用である。
        関数やモジュールの型を確認することにより、どのデータを対象としているのかといった情報が手に入る。
        また、型はコンパイラが実行されるために検査されるため、コメントに埋め込まれた情報と異なり常に正しい情報を提供する。

    \item 言語の安全性

        安全性のの定義は言語によって異なるが、型はデータの抽象化によってある種の安全性を確保できる。
        例えば、プログラマは配列をソートする関数があった場合、与えられた配列のみがソートされ、他のデータには影響が無いことを期待するだろう。
        しかし、低水準言語ではメモリを直接扱えるため、予想された処理の範囲を越えてデータを破壊する可能性がある。
        より安全な言語ではメモリアクセスが抽象化し、データを破壊する可能性をプログラマに提供しないという選択肢がある。

    \item 効率性

        そもそも、科学計算機における最初の型システムは Fortran などにおける式の区別であった。% TODO ref fortran
        整数の算術式と実数の算術式を区別し、数値計算の効率化を測るために導入されたのである。
        型の導入により、コンパイラはプリミティブな演算とは異なる表現を用い、実行コードを生成する時に適切な機械語表現を行なえるようになった。
        昨今の高性能コンパイラでは最適化とコード生成のフェーズにおいて型検査器が収集する情報を多く利用している。

\end{itemize}

型システムの定義には多くの定義が存在する。
型の表現能力には単純型や総称型、部分型などが存在し、動的型付けや静的型付けなど、言語によってどの型システムを採用するかは言語の設計に依存する。
例えば C言語では数値と文字を二項演算子 \verb/+/ で加算できるが、Haskell では加算することができない。
これは Haskell が C言語よりも厳密な型システムを採用しているからである。
具体的には Haskell は暗黙的な型変換を許さず、 C 言語は言語仕様として暗黙の型変換を持っている。

型システムを定義することはプログラミング言語がどのような特徴を持つか決めることにも繋がる。

% }}}

% {{{ 型なしラムダ計算
\section{型なしラムダ計算}
まず、プログラミング言語における計算を形式的に定義する。
プログラミング言語は複雑だが、その計算はある本質的な仕組みからの派生形式として定式化可能であることを Peter Ladin が示した。 % TODO: ref TaPL 61
この時 Landin が使った本質的な仕組みとしての核計算がラムダ計算だった。
ラムダ計算は Alonzo Church が発明した形式的体系の一つである。 % TODO: ref
ラムダ計算では全ての計算が関数定義と関数適用の基本的な演算に帰着される。
ラムダ計算はプログラミング言語の機能の仕様記述や、言語設計と実装、型システムの研究に多く使われている。
この計算体系の重要な点は、ラムダ計算内部で計算が記述できるプログラミング言語であると同時に、それ自身について厳格な証明が可能な数学的対象としてみなせる点にある。

ラムダ計算はいろいろな方法で拡張できる。
数や組やレコードなどはラムダ計算そのもので模倣することができるが、記述が冗長になってしまう。
それらの機能のための具体的な特殊構文を加えることは言語の利用者の視点で便利である。
他にも書き換え可能な参照セルや非局所的な例外といった複雑な機能を表現することもできるが、膨大な変換を用いなければモデル化できない。
それらを言語として備えた拡張に ML や Haskell といったものがある。 % TODO: ref

ラムダ計算(または $ \lambda $ 計算) とは、関数定義と関数適用を純粋な形で表現する。
ラムダ計算においてはすべてが関数である。
関数によって受け付ける引数も関数であり、関数が返す結果もまた関数である。

ラムダ計算の項は変数と抽象と適用の3種類の項からなり、以下の文法に要約される。
変数 $ x $ は項であり、項 $ t_1 $ から変数 $ x $ を抽象化した $ \lambda x . t_1 $ も項であり、項 $ t_1 $ を他の項 $ t_2 $ に適用した $ t_1 t_2 $ も項である。

\begin{multline*}
    t ::= \\
        x \\
        \lambda x . t \\
        t \, t  \\
\end{multline*}

ラムダ計算において関数適用は左結合とする。
つまり、 $ s \, t \, u $ は $ (s \, t) \, u $ となる。

また、抽象の本体はできる限り右側へと拡大する。
例えば $ \lambda x . \;  \lambda y . \; x \, y \, x $ は $ \lambda x . (\lambda . y ((x \, y) \, x)) $ となる。

ラムダ計算には変数のスコープが存在する。
抽象 $ \lambda x . t $ の本体 $ t $ の中に変数 $ x $ がある時、 $ x $ の出現は束縛されていると言う。
同様に、 $ \lambda x $ は $ t $ をスコープとする束縛子であると言う。
なお、 $ x $ を囲む抽象によって束縛されていない場所の $ x $ の出現は自由であると言う。
例えば $ x \; y $ や $ \lambda y . \; x \; y $  における $ x $ の出現は自由だが、 $ \lambda x . x $ や $ \lambda z . \lambda x . \lambda y . x (y \; z) $ における $ x $ の出現は束縛されている。
$ (\lambda x . x) \;x $ においては、最初の $ x $ の出現は束縛されているが、2つ目の出現は自由である。

ラムダ計算において、計算とは引数に対する関数の適用である。
抽象に対して項を適用した場合、抽象の本体に存在する束縛変数に適用する項を代入したもので書き換える。
図式的には

\begin{equation*}
    (\lambda x . t_{12}) t_2 \rightarrow [ x \mapsto t_2] t_{12}
\end{equation*}

と記述する。
ここで $ [ x \mapsto t_2] t_{12} $ とは、$ t_12 $ 中の自由な $ x $ を全て $ t_2 $ で置換した項を意味する。
例えば、 $ (\lambda x . x) \; y $ は $ y $ となり、項 $ (\lambda x . x (\lambda x . x)) (y \; z) $ は $ y \; z \; (\lambda x . x) $ となる。

なお、 $ (\lambda x . t_{12}) t_2 $ という形の項を簡約基(redex, reducible expression) と呼び、上記の規則で簡約基を置換する操作をベータ簡約と呼ぶ。
ラムダ計算のための評価戦略には数種類の戦略がある。

\begin{itemize}
    \item 完全ベータ簡約

        任意の簡約基がいつでも簡約されうる。
        つまり項の中からどの順番で簡約しても良い。

    \item 正規順序簡約

        最も左で最も外側の簡約基が最初に簡約される。

    \item 名前呼び

        正規順序の中でも抽象の内部での簡約を許さない。
        名前呼びの変種は Algol-60 や Haskell で利用されている。
        なお、Haskell においては必要呼びという最適化された変種を利用している。

    \item 値呼び

        ほとんどの言語はこの戦略を用いている。
        基本的には最も左の簡約基をを簡約するが、右側が既に値(計算が終了してもう簡約できない閉じた項)になっている簡約基のみを簡約する。
\end{itemize}

値呼び戦略は関数の引数が本体で使われるかに関わらず評価され、これは正格と呼ばれる。
名前呼びなどの非正格な戦略は引数が使われる時のみ評価され、これは遅延評価とも呼ばれる。

ラムダ計算において、複数の引数は、関数を返り値として返す高階関数として定義できる。
項 $ s $ が二つの自由変数 $ x $ と $ y $ を含むとすれば、 $ \lambda x . \lambda y . s $ と書くことで二つの引数を持つ関数を表現できる。
これは $ x $ に $ v $ が与えられた時、$ y $ を受けとり、 $ s $ の抽象内の自由な $ x $ を $ v $ に置き換えた部分を置換する関数、を返す。
例えば $ (\lambda x . \lambda y . s) \; v \; w $ は $ (\lambda y . [x \mapsto v] s) w $ に簡約され、 $ [y \mapsto w][x \mapsto v]s $ に簡約される。
なお、複数の引数を取る関数を高階関数に変換することはカリー化と呼ばれる。

代入の操作は直感的には置換であるが、変数の束縛に注意しなくてはならない。
例えば抽象への代入を以下のように定義する。

\begin{equation*}
    [ x \mapsto s ] (\lambda y . t_1) = \lambda y . [ x \mapsto s] t_1
\end{equation*}

この場合、束縛変数の名前によっては定義が破綻してしまう。例えば以下のようになる。

\begin{equation*}
    [x \mapsto y](\lambda x . x) = \lambda x . y
\end{equation*}

$ \lambda $ よって束縛されているはずの $ x $ が書き変わっている。
これはスコープとして振る舞っていないので誤っている。
この問題は項 $ t $ 内の変数 $ x $ の自由な出現と束縛された出現を区別しなかったために出現した誤りである。

そこで、$ x $ を束縛する項に対しては置換行なわないように定義を変える。

\begin{itemize}
    \item $ y = x $ の場合
        \begin{equation*}
            [ x \mapsto s ] (\lambda y . t_1) = \lambda y . t_1
        \end{equation*}

    \item $ y \neq x $ の場合
        \begin{equation*}
            [ x \mapsto s ] (\lambda y . t_1) = \lambda y . [ x \mapsto s] t_1
        \end{equation*}
\end{itemize}

この場合は束縛された変数を上書きしないが、逆に自由変数を束縛するケースが発生する。
具体的には以下である。

\begin{equation*}
    [ x \mapsto z] (\lambda z . x) = \lambda z . z
\end{equation*}

項 $ s $ 中の自由変数が項 $ t $ に代入されて束縛される現象は変数捕獲と呼ばれる。
これを避けるためには $ t $ の束縛変数の名前が $ s $ の自由変数の名前と異なることを保証する必要がある。
変数捕獲を回避した代入操作は捕獲回避代入と呼ばれる。
代入における名前の衝突を回避するために項の束縛変数の名前を一貫して変更することで変数捕獲を回避する方法も存在する。
束縛変数の名前を一貫して変更することをアルファ変換と呼ばれる。
これは関数抽象に対する束縛変数は問わないという直感からくるもので、 $ \lambda x . x $ も $ \lambda y . y $ も振舞いとしては同じ関数であるとみなすものである。
捕獲回避の条件を追加した代入の定義は以下のような定義となる。

\begin{itemize}
    \item 変数への代入

        \begin{equation*}
            [ x \mapsto s ] x = s
        \end{equation*}

    \item 存在しない変数への代入($ y \neq x $ の時)

        \begin{equation*}
            [ x \mapsto s ] y = y
        \end{equation*}

    \item 抽象内の項への代入($ y \neq x $ かつ $ y $ が $ s $ の自由変数でない)

        \begin{equation*}
            [ x \mapsto s ] (\lambda y . t_1) = \lambda y . [ x \mapsto s] t_1
        \end{equation*}

    \item 適用への代入

        \begin{equation*}
            [x \mapsto s] (t_1 \; t_2) = (t_1[x\mapsto s])([x \mapsto s] t_2)
        \end{equation*}

\end{itemize}

この定義は少なくとも代入が行なわれる際には正しく代入が行なえる。
さらに、抽象が束縛している変数を名前では無く数字として扱う名無し表現も存在する。
これは De Brujin 表現と呼ばれ、コンパイラ内部などでの項表現として用いられる。 % TODO: ref and spell check

最終的に形無しラムダ計算 $ \lambda $ の項の定義と評価の要約を示す。
% TODO: TaPL 54 の図5-3

項は変数かラムダ抽象か関数適用の3つにより構成される。
また、ラムダ抽象値は全て値である。
加えて評価は関数適用を行なう E-APPABS 計算規則と、適用の項を書き換える E-APP1 と E-APP2 合同規則により定義される。

% TODO: ラムダの再帰とかペアとかの解説

%TODO ラムダの操作的意味論の説明。それとも算術式を前のセクションに入れるか?

% }}}

\section{単純型}
\section{単純型付きラムダ計算}
\section{部分型付け}
\section{部分型と Continuation based C}