\chapter{Agda による Continuation based C の表現}
\label{chapter:cbc-type}
~\ref{chapter:agda}章では Curry-Howard 同型対応により、型付きラムダ計算を用いて命題が証明できることを示した。
加えて、証明支援系言語 Agda を用いてデータの定義とそれを扱う関数の性質の証明が行なえることを確認した。

CbC で自身を証明するために依存型を利用したいが、CbC には専用の型システムが存在しない。
依存型をCbCコンパイラで扱うためにもまず現状の CbC を型付けする必要がある。

~\ref{chapter:cbc-type}章では CbC の項が部分型で型付けできることを示す。
定義した型システムを用いて、Agda 上に DataSegment と CodeSegment の定義、CodeSegment の接続と実行、メタ計算を定義し、それらが型付けされることを確認する。
また、Agda 上で定義した DataSegment とそれに付随する CodeSegment の持つ性質を Agda で証明する。

% {{{ DataSegment の定義
\section{DataSegment の定義}
まず DataSegment から定義していく。
DataSegment はレコード型で表現できるため、Agda のレコードをそのまま利用できる。
例えは~\ref{src:goto} に示していた a と b を加算して c を出力するプログラムに必要な DataSegment を記述すると~\ref{src:agda-ds}のようになる。
cs0 は a と b の二つの Int 型の変数を利用するため、対応する ds0 は a と b のフィールドを持つ。
cs1 は計算結果を格納する c という名前の変数のみを持つので、同様にds1もcのみを持つ。

\lstinputlisting[label=src:agda-ds, caption=Agda における DataSegment の定義] {src/DataSegment.agda.replaced}
% }}}

% {{{ CodeSegment の定義
\section{CodeSegment の定義}
次に CodeSegment を定義する。
CodeSegment は DataSegment を取って DataSegment を返すものである。
よって $ I \rightarrow O $ を内包するデータ型を定義する。

レコード型の型は Set なので、Set 型を持つ変数 I と O を型変数に持ったデータ型 CodeSegment を定義する。
I は Input DataSegment の型であり、 O は  Output DataSegment である。

CodeSegment 型のコンストラクタには \verb/cs/ があり、Input DataSegment を取って Output DataSegment を返す関数を取る。
具体的なデータ型の定義はリスト ~\ref{src:agda-cs} のようになる。

\lstinputlisting[label=src:agda-cs, caption= Agda における CodeSegment 型の定義] {src/CodeSegment.agda.replaced}

この CodeSegment 型を用いて CodeSegment の処理本体を記述する。

まず計算の本体となる cs0 に注目する。
cs0 は二つのInt型変数を持つ ds0 を取り、一つのInt型変数を作った上で cs1 に軽量継続を行なう。
DataSegment はレコードなので、a と b のフィールドから値を取り出した上で加算を行ない、cを持つレコードを生成する。
そのレコードを引き連れたまま cs1 へと goto する。

次に cs1 に注目する。
cs1 は値に触れず cs2 へと goto するだけである。
よって何もせずにそのまま goto する関数をコンストラクタ\verb/cs/ に渡すだけで良い。

最後に cs2 である。
cs2 はリスト~\ref{src:goto}では省略していたが、今回は計算を終了させる CodeSegment として定義する。
どの CodeSegment にも軽量継続せずに値を持ったまま計算を終了させる。
コンストラクタ \verb/cs/ には関数を与えなくては値を構成できないため、何もしない関数である id を渡している。

最後に計算をする cs0 へと軽量継続する main を定義する。
例として、 a の値を 100 とし、 b の値を50としている。

cs0, cs1, cs2, main をAgda で定義するとリスト~\ref{src:agda-css}のようになる。

\lstinputlisting[label=src:agda-css, caption= Agda における CodeSegment の定義] {src/CodeSegments.agda.replaced}

正しく計算が行なえたなら値150が得られるはずである。
% }}}

% {{{ ノーマルレベル計算の実行
\section{ノーマルレベル計算の実行}
\label{section:normal-level-exec}
プログラムを実行することは \verb/goto/ を定義することと同義である。
軽量継続\verb/goto/ の性質としては

\begin{itemize}
    \item 次に実行する CodeSegment を指定する
    \item CodeSegment に渡すべき DataSegment を指定する
    \item 現在実行している CodeSegment から制御を指定された CodeSegment へと移動させる
\end{itemize}

がある。
Agda における CodeSegment の本体は関数である。
関数をそのまま使用すると再帰を許してしまうために CbC との対応が失われてしまう。
よって、\verb/goto/を利用できるのは関数の末尾のみである、という制約を関数に付け加える必要がある。

この制約さえ満たせば、CodeSegment の実行は CodeSegment 型から関数本体を取り出し、レコード型を持つ値を適用することに相当する。
具体的に \verb/goto/ を関数として適用するとリスト~\ref{src:agda-goto}のようになる。

\lstinputlisting[label=src:agda-goto, caption=Agdaにおける goto の定義] {src/Goto.agda.replaced}

この \verb/goto/ の定義を用いることで main などの関数が評価できるようになり、値150が得られる。
本文中での CodeSegment の定義は一部を抜粋している。
実行可能な Agda のソースコードは付録に載せる。

% }}}

% {{{ Meta DataSegment の定義

\section{Meta DataSegment の定義}
ノーマルレベルの CbC を Agda 上で記述し、実行することができた。
次にメタレベルの計算を Agda 上で記述していく。

Meta DataSegment はノーマルレベルの DataSegment の集合として定義できるものであり、全ての DataSegment の部分型であった。
ノーマルレベルの DataSegment はプログラムによって変更されるので、事前に定義できるものではない。
ここで、Agda の Parameterized Module を利用して、「Meta DataSegment の上位型は DataSegment である」のように DataSegment を定義する。
こうすることにより、全てのプログラムは一つ以上の Meta DataSegment を持ち、任意の個数の DataSegment を持つ。
また、Meta DataSegment をメタレベルの DataSegment として扱うことにより、「Meta DataSegment の部分型である Meta Meta DataSegment」を定義できるようになる。
階層構造でメタレベルを表現することにより、計算の拡張を自在に行なうことができる。

具体的な Meta DataSegment の定義はリスト~\ref{src:agda-mds}のようになる。
型システム \verb/subtype/ は、Meta DataSegment である \verb/Context/ を受けとることにより構築される。
Context を Meta DataSegment とするプログラム上では DataSegment は Meta CodeSegment の上位型となる。
その制約を \verb/DataSegment/ 型は表わしている。

\lstinputlisting[label=src:agda-mds, caption=Agda における Meta DataSegment の定義] {src/MetaDataSegment.agda.replaced}


ここで、関数を部分型に拡張する S-ARROW をもう一度示す。

\begin{align*}
    \AxiomC{$ T_1 <: S_1$}
    \AxiomC{$ S_2 <: T_2$}
    \BinaryInfC{$ S_1 \rightarrow S_2 <: T_1 \rightarrow T_2 $}
    \DisplayProof && \text{S-ARROW}
\end{align*}

S-ARROW は、前提である部分型関係 $ T_1 <: S_1 $ と $ S_2 <: T_2 $ が成り立つ時に、 上位型 $ S_1 \rightarrow S_2 $ の関数を、部分型 $ T_1 \rightarrow T_2 $ に拡張できた。
ここでの上位型は DataSegment であり、部分型は Meta DataSegment である。
制約\verb/DataSegment/ の \verb/get/ は、 Meta DataSegment から DataSegment が生成できることを表す。
これは前提 $ T_1 <: S_1 $ に相当する。
そして、\verb/set/ は $ S_2 <: T_2 $ に相当する。
しかし、任意の DataSegment が Meta DataSegment の部分型となるには、 DataSegment が Meta DataSegment よりも多くの情報を必ず持たなくてはならないが、これは通常では成り立たない。
だが、メタ計算を行なう際には常に Meta DataSegment を一つ以上持っていると仮定するならば成り立つ。
実際、GearsOS における赤黒木では Meta DataSegment に相当する \verb/Context/ を常に持ち歩いている。
GearsOS における計算結果はその持ち歩いている Meta DataSegment の更新に相当するため、常に Meta DataSegment を引き連れていることを無視すれば DataSegment から Meta DataSegment を導出できる。
よって $ S_2 <: T_2 $ が成り立つ。

なお、 $ S_2 <: T_2 $ は Output DataSegment を Meta DataSegment を格納する作業に相当し、 $ T_1 <: S_1 $ は Meta DataSegment から Input DataSegment を取り出す作業であるため、これは明らかに \verb/stub/ である。

% }}}

% {{{ Meta CodeSegment の定義

\section{Meta CodeSegment の定義}
Meta DataSegment が定義できたので Meta CodeSegment を定義する。
実際、DataSegment が Meta DataSegment に拡張できたため、Meta CodeSegment の定義には比較的変更は無い。
ノーマルレベルの \verb/CodeSegment/ 型に、DataSegment を取って DataSegment を返す、という制約を明示的に付けるだけである(リスト~\ref{src:agda-mcs})

\lstinputlisting[label=src:agda-mcs, caption=Agda における Meta CodeSegment の定義] {src/MetaCodeSegment.agda.replaced}

メタレベルの定義を部分型で行なって分かったことには以下のようなものがある。

\begin{itemize}
    \item メタ計算は階層構造化できる

        メタ計算は階層構造を取ることができるため、組み合わせることも可能である。

    \item 継続先が不定の場合は型を一様に扱う必要がある

        メタ計算がノーマルレベルの具体的な型を知ることができるのはコンパイル時のみである。
        よってメタ計算を定義する時は部分型制約しか記述できない。
        逆に言えばノーマルレベル計算のみであれば部分型は解決され、レコード型で型付けができる。

    \item \verb/stub/ は部分型付けにおいても必要である

        GearsOS では Meta DataSegment から DataSegment を取り出すための処理として \verb/stub/ が存在していた。
        これは Meta DataSegment で一様に扱っていた DataSegment に型を戻す処理として、型システムにおいても必要なものである。'
        また、型システム経由で \verb/stub/ を生成することも可能であると考えられる。

\end{itemize}

% }}}

% {{{ メタレベル計算の実行
\section{メタレベル計算の実行}
\label{section:meta-level-exec}
Meta DataSegment と Meta CodeSegment の定義を行なったので、残るは実行である。

実行はノーマルレベルにおいては軽量継続 \verb/goto/ を定義することによって表せた。
メタレベル実行ではそれを Meta CodeSegment と Meta DataSegment を扱えるように拡張する。
Meta DataSegment は Parameterized Module の引数 \verb/Context/ に相当するため、Meta CodeSegment は Context を取って Context を返す CodeSegment となる。
軽量継続 \verb/goto/ と区別するために名前を \verb/exec/ とするリスト~\ref{src:agda-exec}のように定義できる。
行なっていることは Meta CodeSegment の本体部分に Meta DataSegment を渡す、という \verb/goto/ と変わらないが、\verb/set/ と \verb/get/ を用いることで上位型である任意の DataSegment を実行する CodeSegment も Meta CodeSegment として一様に実行できる。

\lstinputlisting[label=src:agda-exec, caption=Agda におけるメタレベル実行の定義] {src/Exec.agda.replaced}

実行例として、リスト~\ref{src:goto} に示していた a と b の値を加算して c に代入するプログラムを考える。
実行する際に c の値を \verb/c'/ に保存してから加算ようなメタ計算を考える。
c の値を \verb/c'/ に保存するタイミングは軽量継続時にユーザが指定する。
よって軽量継続を行なうのと同等の情報を保持してなくてはならない。
そのために Meta Meta DataSegment \verb/Meta/ には制御を移す対象であるノーマルレベル CodeSegment を持つ。
値を格納する \verb/c'/ の位置は Meta DataSegment でも Meta Meta DataSegment でも構わないが、今回は Meta Meta DataSegemnt に格納するものとする。
それらを踏まえた上での Meta Meta DataSegment の Agda 上での定義は~\ref{src:agda-mmds}のようになる。
なお、\verb/goto/ などの名前の衝突を避けるためにノーマルレベルの定義は \verb/N/ に、メタレベルの定義は \verb/M/ へと名前を付けかえている。

\lstinputlisting[label=src:agda-mmds, caption=Agda における Meta Meta DataSegment の定義例] {src/MetaMetaDataSegment.agda.replaced}

定義した \verb/Meta/ を利用して、c を \verb/c'/に保存するメタ計算 \verb/push/ を定義する。
より構文が CbC に似るように \verb/gotoMeta/ を糖衣構文的に定義する。
\verb/gotoMeta/ や \verb/push/ で利用している \verb/liftContext/ や \verb/liftMeta/ はノーマルレベル計算をメタ計算レベルとするように型を明示的に変更するものである。
結果的に \verb/main/ の \verb/goto/ を \verb/gotoMeta/ に置き換えることにより、c の値を計算しながら保存できる。
リスト~\ref{src:agda-mmcs} に示したプログラムでは、通常レベルのコードセグメントを全く変更せずにメタ計算を含む形に拡張している。
加算を行なう前の \verb/c/ の値が \verb/70/ であったとした時、計算結果 \verb/150/ は \verb/c/ に格納されるが、\verb/c'/には\verb/70/に保存されている。

\lstinputlisting[label=src:agda-mmcs, caption=Agda における Meta Meta CodeSegment の定義と実行例] {src/MetaMetaCodeSegment.agda.replaced}

CodeSegment や Meta CodeSegment などの定義が多かっため、どの処理やデータがどのレベルに属するか複雑になったため、一度図~\ref{fig:meta-hierarchy}にてまとめる。
Meta DataSegment を含む任意の DataSegment は Meta DataSegment になりえるので、この階層構造は任意の段数定義することが可能である。

\begin{figure}[htbp]
    \begin{center}
        \includegraphics[width=450pt]{fig/meta-hierarchy.pdf}
        \caption{メタの階層構造}
        \label{fig:meta-hierarchy}
    \end{center}
\end{figure}

また、この節で取り扱ったソースコードは付録に付す。

% }}}

% {{{ Agda を用いた Continuation based C の証明

\section{Agda を用いた Continuation based C の証明}
\label{section:cbc-proof}
Agda において CbC の CodeSegment と DataSegment を定義することができた。
実際の CbC のコードを Agda で記述し、それらの性質を証明していく。

ここではGearsOS が持つ DataSegment \verb/SingleLinkedStack/ を証明していく。
この\verb/SingleLinkedStack/はポインタを利用した片方向リストを用いて実装されている。

CbC における DataSegment \verb/SingleLinkedStack/ の定義はリスト~\ref{src:cbc-stack}のようになっている。

\lstinputlisting[label=src:cbc-stack, caption=CbC における構造体 stack の定義] {src/stack.h}

次に Agda における \verb/SingleLinkedStack/の定義について触れるが、Agda にはポインタが無いため、メモリ確保や\verb/NULL/の定義は存在しない。
CbC におけるメモリ確保部分はノーマルレベルには出現しないと仮定し、\verb/NULL/の表現にはAgda の標準ライブラリに存在する \verb/Data.Maybe/ を用いる。

\verb/Data.Maybe/ の \verb/maybe/ 型は、コンストラクタを二つ持つ。
片方のコンストラクタ \verb/just/ は値を持ったデータであり、ポインタの先に値があることに対応している。
一方のコンストラクタ \verb/nothing/ は値を持たない。
これは値が存在せず、ポインタの先が確保されていない(\verb/NULL/ ポインタである)ことを表現できる。

\lstinputlisting[label=src:agda-maybe, caption=Agda における Maybe の定義] {src/Maybe.agda.replaced}

Maybe を用いて片方向リストを Agda 上に定義するとリスト~\ref{src:agda-stack}のようになる。
CbC とほぼ同様の定義ができている。
CbC、 Agda 共に\verb/SingleLinkedStack/ は \verb/Element/ 型の \verb/top/ を持っている。
\verb/Element/ 型は値と次の \verb/Element/ を持つ。
CbC ではポインタで表現していた部分が Agda では Maybe で表現されているが、\verb/Element/ 型の持つ情報は変わっていない。

\lstinputlisting[label=src:agda-stack, caption=Agda における片方向リストを用いたスタックの定義] {src/AgdaStack.agda.replaced}

Agda で片方向リストを利用する DataSegment の定義をリスト~\ref{src:agda-stack-ds}に示す。
ノーマルレベルからアクセス可能な場所として \verb/Context/ に \verb/element/ フィールドを追加する。
そしてノーマルレベルからアクセスできないよう分離した Meta Meta DataSegment である \verb/Meta/ にスタックの本体を格納する。
CbC における実装では \verb/.../ で不定であった \verb/next/ も、agda ではメタレベルのコードセグメント \verb/nextCS/ となり、きちんと型付けされている。

\lstinputlisting[label=src:agda-stack-ds, caption=スタックを利用するための DataSegment の定義] {src/AgdaStackDS.agda.replaced}

次にスタックへの操作に注目する。
スタックへと値を積む \verb/pushSingleLinkedStack/ と値を取り出す \verb/popSingleLinkedStack/ の CbC 実装をリスト~\ref{src:cbc-push-pop}に示す。
\verb/SingleLinkedStack/ は Meta CodeSegment であり、メタ計算を実行した後には通常の CodeSegment へと操作を移す。
そのために \verb/next/ という名前で次のコードセグメントを保持している。
具体的な \verb/next/ はコンパイル時にしか分からないため、\verb/.../ 構文を用いて不定としている。

\verb/pushSingleLinkedStack/ は \verb/element/ を新しく確保し、値を入れた後に \verb/next/ へと繋げ、 \verb/top/ を更新して軽量継続する。
\verb/popSingleLinkedStack/ は先頭が空でなければ先頭の値を \verb/top/ から取得し、\verb/element/を一つ進める。
値が空であれば \verb/data/ を \verb/NULL/ にしたまま軽量継続を行なう。

\lstinputlisting[label=src:cbc-push-pop, caption= CbC における SingleLinkedStack を操作する Meta CodeSegment] {src/singleLinkedStack.c}

次に Agda における定義をリスト~\ref{src:agda-push-pop}に示す。
同様に \verb/pushSingleLinkedStack/ と \verb/popSingleLinkedStack/ を定義している。
\verb/pushsinglelinkedstack/ では、スタックの値を更新したのちにノーマルレベルの CodeSegment である \verb/n/ を \verb/exec/ している。
なお、 \verb/liftMeta/ はノーマルレベルの計算をメタレベルとする関数である。

実際に値を追加する部分は where 句に定義された関数 \verb/push/ である。
これはスタックへと積む値が空であれば追加を行なわず、値がある時は新たに element を作成して top を更新している。
本来の CbC の実装では空かチェックはしていないが、値が空であるかに関わらずにスタックに積んでいるために挙動は同じである。

次に \verb/popSingleLinkedStack/ に注目する。
こちらも操作後に \verb/nextCS/ へと継続を移すようになっている。

実際に値を取り出す操作はノーマルレベルからアクセスできる \verb/element/ の値の確定と、アクセスできない \verb/stack/ の更新である。

\verb/element/については、 \verb/top/ が空なら取り出した後の値は無いので \verb/element/ は \verb/nothing/ である。
\verb/top/ が空でなければ \verb/element/ は \verb/top/ の値となる。

\verb/stack/ は空なら空のままであり、\verb/top/ に値があればその先頭を捨てる。
ここで、\verb/pop/ の実装はスタックが空であっても、例外を送出したり停止したりせずに処理を続行できることが分かる。

\lstinputlisting[label=src:agda-push-pop, caption=Agda における片方向リストを用いたスタックの定義] {src/AgdaPushPop.agda.replaced}

また、この章で取り上げた CbC と Agda の動作するソースコードは付録に載せる。

% }}}

% {{{ スタックの実装の証明
\section{スタックの実装の証明}
\label{section:stack-proof}
定義した SingleLinkedStack に対して証明を行なっていく。
ここでの証明は SingleLinkedStack の処理が特定の性質を持つことを保証することである。

例えば

\begin{itemize}
    \item スタックに積んだ値は取り出せる
    \item 値は複数積むことができる
    \item スタックから値を取り出すことができる
    \item スタックから取り出す値は積んだ値である
    \item スタックから値を取り出したらその値は無くなる
    \item スタックに値を積んで取り出すとスタックの内容は変わらない
\end{itemize}

といった多くの性質がある。

ここでは、最後に示した「スタックに値を積んで取り出すとスタックの内容は変わらない」ことについて示していく。
この性質を具体的に書き下すと以下のようになる。

\begin{definition}
    任意のスタック s に対して

    \begin{itemize}
        \item 任意の値n
        \item 値xを積む操作 push(x, s)
        \item 値を一つスタックから取り出す操作 pop(s)
    \end{itemize}

    がある時、

    pop . push(n) s = s

    である。
\end{definition}

これを Agda 上で定義するとリスト~\ref{src:agda-push-pop-type-1} のようになる。
Agda 上の定義ではスタックそのものではなく、スタックを含む任意の \verb/Meta/ に対してこの性質を証明する。
この定義が \verb/Meta/ の値によらず成り立つことを、自然数の加算の交換法則と同様に等式変形を用いて証明していく。

\lstinputlisting[label=src:agda-push-pop-type-1, caption=Agda におけるスタックの性質の定義(1)] {src/PushPopType.agda.replaced}

今回注目する条件分けは、スタック本体である \verb/stack/ と、push や pop を行なうための値を格納する \verb/element/ である。
それぞれが持ち得る値を場合分けして考えていく。

\begin{itemize}
    \item スタックが空である場合

        \begin{itemize}
            \item element が存在する場合

                値が存在するため、 push は実行される。
                push が実行されたためスタックに値があるため、pop が成功する。
                pop が成功した結果スタックは空となるため元のスタックと同一となり成り立つ。

            \item element が存在しない場合

                値が存在しないため、 push が実行されない。
                push が実行されなかったため、スタックは空のままであり、pop も実行されない。
                結果スタックは空のままであり、元のスタックと一致する。
        \end{itemize}

    \item スタックが空でない場合

        \begin{itemize}
            \item element が存在する場合

                element に設定された値 n が push され、スタックに一つ値が積まれる。
                スタックの先頭は n であるため、pop が実行されて n は無くなる。
                結果、スタックは実行する前の状態に戻る。

            \item element が存在しない場合

                element に値が存在しないため、push は実行されない。
                スタックは空ではないため、popが実行され、先頭の値が無くなる。
                実行後、スタックは一つ値を失なっているため、これは成りたたない。
        \end{itemize}
\end{itemize}

スタックが空でなく、push する値が存在しないときにこの性質は成り立たないことが分かった。
また、\verb/element/ が空でない制約を仮定に加えることでこの命題は成り立つようになる。

push 操作と pop 操作を連続して行なうとスタックが元に復元されることは分かった。
ここで SingleLinkedStack よりも範囲を広げて \verb/Meta/ も復元されるかを考える。
一見これも自明に成り立ちそうだが、push 操作と pop 操作は操作後に実行される CodeSegment を持っている。
この CodeSegment は任意に設定できるため、\verb/Meta/ 内部の DataSegement が書き換えられる可能性がある。
よってこれも制約無しでは成り立たない。

逆にいえば、CodeSegment を指定してしまえば \verb/Meta/ に関しても push/pop の影響を受けないことを保証できる。
全く値を変更しない CodeSegment \verb/id/ を指定した際には自明にこの性質が導ける。
実際、 Agda 上でも等式変形を明示的に指定せず、定義からの推論でこの証明を導ける(リスト~\ref{src:agda-push-pop-proof})。

なお、今回 SingleLinkedStack に積むことができる値は Agda の標準ライブラリの(\verb/Data.Nat/)モジュールにおける自然数型 $ \mathbb{N} $ としている。
これはスタックを利用する際に具体的な値があると証明に有用であるからである。
push/pop 操作の後の継続が \verb/Meta/ に影響を与えない制約は \verb/id-meta/ に表れている。
これは \verb/Meta/ を構成する要素を受け取り、継続先の CodeSegment に恒等関数 \verb/id/ を指定している。
加えて、スタックが空で無い制約 where 句の \verb/meta/ に表れている。
必ずスタックの先頭 \verb/top/ には値xが入っており、それ以降の値は任意としている。
よってスタックは必ず一つ以上の値を持ち、空でないという制約を表わせる。
証明は refl によって与えられる。
つまり定義から自明に推論可能となっている。

\lstinputlisting[label=src:agda-push-pop-proof, caption=Agdaにおけるスタックの性質の証明(1)] {src/AgdaPushPopProof.agda.replaced}

ここで興味深い点は、 SingleLinkedStack の実装から証明に仮定が必要なことが証明途中でに分かった点にある。
例えば、CbC の SingleLinkedStack 実装の push/pop 操作は失敗しても成功しても指定された CodeSegment に軽量継続する。
この性質により、指定された CodeSegment によっては、スタックの操作に関係なく \verb/Meta/ の内部の DataSegemnt が書き換えられる可能性があることが分かった。
スタックの操作の際に行なわれる軽量継続の利用方法は複数考えられる。
例えば、スタックが空である際に pop を行なった時はエラー処理用の継続を行なう、といった実装も可能である。
実装が異なれば、同様の性質でも証明は異なるものとなる。
このように、実装そのものを適切に型システムで定義できれば、明示されていない実装依存の仕様も証明時に確定させることができる。

証明した定理をより一般的な「任意の自然数回だけスタックへ値を積み、その後同じ回数スタックから値を取り出すとスタックは操作前と変わらない」という形に拡張する。
この性質を Agda で定義するとリスト~\ref{src:agda-n-push-n-pop}のようになる。
自然数n回だけ push/pop することを記述するために Agda 上に \verb/n-push/ 関数と \verb/n-pop/ 関数を定義している。
それぞれ一度操作を行なった後に再帰的に自身を呼び出す再帰関数である。

\lstinputlisting[label=src:agda-n-push-n-pop, caption=Agda におけるスタックの性質の定義(2)] {src/AgdaNPushNPop.agda.replaced}

この性質の証明は少々複雑である。
結論から先に示すとリスト~\ref{src:agda-n-push-n-pop-proof}のように証明できる。

\lstinputlisting[label=src:agda-n-push-n-pop-proof, caption=Agda におけるスタックの性質の証明(2)] {src/AgdaNPushNPopProof.agda.replaced}

これは以下のような形の証明になっている。

\begin{itemize}
    \item 「n回pushした後にn回popしても同様になる」という定理を \verb/n-push-pop/ とおく。
    \item \verb/n-push-pop/ は自然数nと特定の \verb/Meta/ に対して \\
        \verb/exec (n-pop (suc n)) . (n-push (suc n))) m = m/ が成り立つことである
    \item 特定の \verb/Meta/ とは、 push/pop 操作の後の継続が DataSegment を変更しない \verb/Meta/ である。
    \item また、簡略化のために \verb/csComp/ による CodeSegment の合成を二項演算子 \verb/./ とおく
        \begin{itemize}
            \item 例えば \verb/exec (csComp f g) x/ は \verb/exec (f . g) x/ となる。
        \end{itemize}

    \item \verb/n-push-pop/ を証明するための補題 \verb/pop-n-push/ を定義する
    \item \verb/n-push-pop/ とは「n+1回push して1回 pop することは、n回pushすることと等しい」という補題である。
    \item \verb/n-push-pop/ は \verb/exec (pop . n-push (suc n)) m = exec (n-push n) m/ と表現できる。
    \item \verb/n-push-pop/ の n が zero の時は直ちに成り立つ。
    \item \verb/n-push-pop/ の n が zero でない時(suc n である時)は以下のように証明できる。

        \begin{itemize}
            \item \verb/exec (n-push (suc n)) m/ を \verb/X/ とおく
            \item \verb/exec (pop . n-push (suc (suc n))) m = X/
            \item n-push の定義より \verb/exec (pop . (n-push (suc n) . push)) m = X/
            \item 補題 exec-comp より \verb/exec (pop (exec (n-push (suc n) . push) m)) = X/
            \item 補題 exec-comp より \verb/exec (pop (exec (n-push (suc n) (exec push m)))) = X/
            \item 一度pushした結果を \verb/m'/とおくと \verb/exec (pop (exec (n-push (suc n) m'))) = X/
            \item \verb/n-push-pop/ より \verb/exec (exec (n-push n m')) = X/
            \item push の定義より \verb/exec (exec (n-push n (exec push m))) = X/
            \item n-push の定義より \verb/exec (exec (n-push (suc n) m) = X/ となる
            \item 全く同一の項に変更できたので証明終了
        \end{itemize}


    \item 次に \verb/n-push-pop/ の証明を示す。
    \item \verb/n-push-pop/ の n が zero の時は、 \verb/suc zero/ 回の push/pop が行なわれるため、\verb/push-pop/より成り立つ。
    \item \verb/n-push-pop/ の n が zero でない時は以下により証明できる。

        \begin{itemize}
            \item \verb/exec ((n-pop (suc n)) . (n-push (suc n))) m = m / を示せれば良い。
            \item \verb/X/ に注目した時 n-pop の定義より \verb/exec (n-pop n) . pop . (n-push (suc n)) m = m/
            \item exec-comp より \verb/exec (n-pop n) (exec pop (n-push (suc n)) m) = m/
            \item exec-comp より \verb/exec (n-pop n) (exec pop (exec (n-push (suc n)) m)) = m/
            \item exec-comp より \verb/exec (n-pop n) (exec pop . (n-push (suc n)) m) = m/
            \item pop-n-push より \verb/exec (n-pop n) (exec (n-push n) m) = m/
            \item n-push-pop より \verb/m = m/ となり証明終了。
            \item なお、n-push-pop は (suc n) が n に減少するため、確実に停止することから自身を自身の証明に適用している。
        \end{itemize}
\end{itemize}

push-pop を一般化した n-push-pop を証明することができた。
n-push-pop は証明の途中で補題 pop-n-push と push-pop を利用した定理である。
このように、CbC で記述されたプログラムを Agda 上に記述することで、データ構造の性質を定理として証明することができた。
これらの証明機構を CbC のコンパイラやランタイム、モデルチェッカなどに組み込むことにより CbC は CbC で記述されたコードを証明することができるようになる。
なお、本論文で取り扱っている Agda のソースコードは可読性の向上のために暗黙的な引数を省略している。
完全なコードは付録に付す。

% }}}