\chapter{GearsOSのInterfaceの改良}

\section{GearsOSのInterfaceの構文の改良}
GearsOSのInterfaceでは、 従来はDataGearとCodeGearを分離して記述していた。
CodeGearの入出力をDataGearとして列挙する必要があった。
CodeGearの入出力として\texttt{\_\_code()}の間に記述したDataGearの一覧と、Interface上部で記述したDataGearの集合が一致している必要がある。
ソースコード\ref{src:old-stack}はStackのInterfaceの例である。
\lstinputlisting[label=src:old-stack, caption=従来のStack Interface]{src/old-stack.h}

従来の分離している記法の場合、 このDataGearの宣言が一致していないケースが多々発生した。
またInterfaceの入力としてのDataGearではなく、 フィールド変数としてDataGearを使うプログラミングスタイルを取るケースも見られた。
GearsOSでは、 DataGearやフィールド変数をオブジェクトに格納したい場合、 Interface側ではなくImpl側に変数を保存する必要がある。
Interface側に記述してしまう原因は複数考えられる。
GearsOSのプログラミングスタイルに慣れていないことも考えられるが、構文によるところも考えられる。
CodeGearとDataGearはInterfaceの場合は密接な関係性にあるが、 分離して記述してしまうと「DataGearの集合」と「CodeGearの集合」を別個で捉えてしまう。
あくまでInterfaceで定義するCodeGearとDataGearはInterfaceのAPIである。
これをユーザーに強く意識させる必要がある。

golangにもInterfaceの機能が実装されている。
golangの場合はInterfaceは関数の宣言部分のみを記述するルールになっている。
変数名は含まれていても含まなくても問題ない。

\begin{lstlisting}[frame=lrbt,label=src:golang_interface,caption={golangのinterface宣言}]
type geometry interface {
    area() float64
    perim() float64
}
\end{lstlisting}

GearsOSのInterfaceは入力と出力のAPIを定義するものであるので、 golangのInterfaceのように、関数のAPIを並べて記述するほうが簡潔であると考えた。
改良したInterfaceの構文でStackを定義したものをソースコード\ref{src:stack}に示す。
\lstinputlisting[label=src:stack, caption=変更後のStack Interface]{src/stack.h}


従来のInterfaceでは\texttt{<Type, Impl>}キーワードが含まれていた。
これはジェネリクスの機能を意識して導入された構文である。
\texttt{Impl}キーワードは実装自身の型を示す型変換として使われていた。
しかし基本Interfaceの定義を行う際にGearsOSのシステム上、CodeGearの第一引数は\texttt{Impl}型のポインタが来る。
これはオブジェクト指向言語で言う\texttt{self}に相当するものであり、 自分自身のインスタンスを示すポインタである。
Implキーワードは共通して使用されるために、 宣言部分からは取り外し、デフォルトの型キーワードとして定義した。
\texttt{Type}キーワードは型変数としての利用を意識して導入されていたが、現在までのGearsOSの例題では導入されていなかった。
ジェネリクスとしての型変数の利用の場合は\texttt{T}などの1文字変数がよく使われる。
変更後の構文ではのちのジェネリクス導入のことを踏まえて、\texttt{Type}キーワードは削除した。



構文を変更するには、 GearsOSのビルドシステム上でInterfaceを利用している箇所を修正する必要がある。
Interfaceはgenerate\_stub.plで読み込まれ、 CodeGearと入出力のDataGearの数え上げが行われる。
この処理はInterfaceのパースに相当するものである。
当然ではあるが、パース対象のInterfaceの構文は、変更前の構文にしか対応していない。


\section{Implementの型定義ファイルの導入}
Interfaceを使う言語では、 Interfaceが決まるとこれを実装するクラスや型が生まれる。
GearsOSもInterfaceに対応する実装が存在する。
例えばStack Interfaceの実装はSingleLinkedStackであり、 Queueの実装はSingleLinkedQueueやSynchronizedQueueが存在する。

このSynchronizedQueueはGearsOSではDataGearとして扱われる。
Interfaceの定義と同等な型定義ファイルが、 実装の型については存在しなかった。
従来はcontext.hのDataGearの宣言部分に、構造体の形式で表現したものを手で記述していた。(ソースコード\ref{src:singleContext.h})
\lstinputlisting[label=src:singleContext.h, caption=cotnext.hに直接書かれた型定義]{src/singleContext.h}

CbCファイルからはcontext.hをインクルードすることで問題なく型の使用は可能である。
Perlのトランスコンパイラであるgenerate\_stub.plはInterfaceの型定義ファイルをパースしていた。
しかし型定義ファイルの存在の有無がInterfaceと実装で異なっている為に、 generate\_stub.plでImplementの型に関する操作ができない。
Implementの型も同様に定義ファイルを作製すれば、generate\_stub.plで型定義を用いた様々な処理が可能となり、ビルドシステムが柔軟な挙動が可能となる。
また型定義は一貫して\texttt{*.h}に記述すれば良くなるため、 プログラマの見通しも良くなる。
本研究では新たにImplementの型定義ファイルを考案する。

GearsOSではすでにInterfaceの型定義ファイルを持っている。
Implementの型定義ファイルも、 Interfaceの型定義ファイルと似たシンタックスにしたい。
Implementの型定義ファイルで持たなければいけないのは、 どのInterfaceを実装しているかの情報である。
この情報は他言語ではInterfaceの実装を持つ型の宣言時に記述するケースと、型名の記述はせずに言語システムが実装しているかどうかを確認するケースが存在する。
Javaでは\texttt{implements}キーワードを用いてどのInterfaceを実装しているかを記述する。\cite{javaimpl}
ソースコード\ref{src:javaimpl}では、\texttt{Pig}クラスは\texttt{Animal} Interfaceを実装している。
\lstinputlisting[label=src:javaimpl, caption=JavaのImplementキーワード]{src/java-interface-implements.java}
golangではInterfaceの実装は特にキーワードを指定せずに、 そのInterfaceで定義しているメソッドを、Implementに相当する構造体がすべて実装しているかどうかでチェックされる。
これはgolangはクラスを持たず、構造体を使ってInterfaceの実装を行う為に、 構造体の定義にどのInterfaceの実装であるかの情報をシンタックス上書けない為である。
GearsOSでは型定義ファイルを持つことができるために、 golangのような実行時チェックは行わず、 Javaに近い形で表現したい。

導入した型定義でSynchronizedQueueを定義したものをソースコード\ref{src:syncqueue}に示す。
大まかな定義方法はInterface定義のものと同様である。
違いとして\texttt{impl}キーワードを導入した。
これはJavaの\texttt{implements}に相当する機能であり、 実装したInterfaceの名前を記述する。
現状のGearsOSではImplが持てるInterfaceは1つのみであるため、\texttt{impl}の後ろにはただ1つの型が書かれる。
型定義の中では独自に定義したCodeGearを書いてもいい。
これはJavaのプライベートメソッドに相当するものである。
特にプライベートメソッドがない場合は、 実装側で所持したい変数定義を記述する。
SynchronizedQueueの例では\texttt{top}などが実装側で所持している変数である。
\lstinputlisting[label=src:syncqueue, caption=SynchronizedQueueの定義ファイル]{src/SynchronizedQueue.h}
従来context.hに直接記述していたすべてのDataGearの定義は、 スクリプトで機械的にInterfaceおよびImplementの型定義ファイルに変換している。

\section{Implementの型をいれたことによる間違ったGearsプログラミング}
Implementの型を導入したが、 GearsOSのプログラミングをするにつれていくつかの間違ったパターンがあることがわかった。
自動生成されるStubCodeGearは、 goto metaから遷移するのが前提であるため、 引数をContextから取り出す必要がある。
Contextから取り出す場合は、 実装しているInterfaceに対応している置き場所からデータを取り出す。
この置き場所は\texttt{data}配列であり、 配列の添え字は\texttt{enum Data}と対応している。
また各CodeGearからgotoする際に、 遷移先のInterfaceに値を書き込みに行く。


Interfaceで定義したCodeGearと対応しているImplementのCodeGearの場合はこのデータの取り出し方で問題はない。
しかしImplementのCodeGearから内部でgotoするCodeGearの場合は事情が異なる。
内部でgotoするCodeGearは、 Javaなどのプライベートメソッドとして使用できる。
このCodeGearのことをprivate CodeGearと呼ぶ。
privateCodeGearにgotoする場合、 goto元のCodeGearからは\texttt{goto meta}経由で遷移する。
goto metaが発行されるとStub Code Gearに遷移するが、現在のシステムではInterfaceから値を取得しに行く。
private CodeGearの入力もStubから取得したいと考え、 ImplementをInterfaceのつもりでGearsOSのコードを記述した。


\section{Interfaceのパーサーの構築}

\section{Interfaceの実装のCbCファイルへの構文の導入}

\section{GearsCbCのInterfaceの実装時の問題}

Interfaceとそれを実装するImplの型が決定すると、最低限満たすべきCodeGearのAPIは一意に決定する。
ここで満たすべきCodeGearは、Interfaceで定義したCodeGearと、 Impl側で定義した privateなCodeGearとなる。
例えばStack Interfaceの実装を考えると、各Implで\texttt{pop}, push, shift, isEmptyなどを実装する必要がある。

従来はプログラマが手作業でヘッダーファイルの定義を参照しながら\texttt{.cbc}ファイルを作成していた。
手作業での実装のため、 コンパイル時に下記の問題点が多発した。

\begin{itemize}
  \item CodeGearの入力のフォーマットの不一致
  \item Interfaceの実装のCodeGearの命名規則の不一致
  \item 実装を忘れているCodeGearの発生
\end{itemize}


特にGearsOSの場合はPerlスクリプトによって純粋なCbCに一度変換されてからコンパイルが行われる。
実装の状況とトランスコンパイラの組み合わせによっては、 CbCコンパイラレベルでコンパイルエラーを発生させないケースがある。
この場合は実際に動作させながら、gdb, lldbなどのCデバッガを用いてデバッグをする必要がある。
またCbCコンパイラレベルで検知できても、すでに変換されたコード側でエラーが出る。
このため、 トランスコンパイラの挙動をトレースしながらデバッグをする必要がある。
Interfaceの実装が不十分であることのエラーは、 GearsOSレベル、最低でもCbCコンパイラのレベルで完全に検知したい。

\section{Interfaceを満たすコード生成の他言語の対応状況}

Interfaceを機能として所持している言語の場合、Interfaceを完全に見たいしているかどうかはコンパイルレベルか実行時レベルで検知される。
例えばJavaの場合はInterfaceを満たしていない場合はコンパイルエラーになる。


InterfaceのAPIを完全に実装するのを促す仕組みとして、Interfaceの定義からエディタやツールが満たすべき関数と引数の組を自動生成するツールがある。

Javaでは様々な手法でこのツールを実装している。
Microsoftが提唱しているIDEとプログラミング言語のコンパイラをつなぐプロトコルにLanguage Serverがある。
Language Serverはコーディング中のソースコードをコンパイラ自身でパースし、 型推論やエラーの内容などをIDE側に通知するプロトコルである。
主要なJavaのLanguage Serverの実装であるeclipse.jdt.ls\cite{eclipse.jdt.ls}では、 LanguageServerの機能として未実装のメソッドを検知する機能が実装されている。\cite{eclipse_pull322}
この機能を応用してvscode上から未実装のメソッドを特定し、 雛形を生成する機能がある。
他にもIntelliJ IDEなどの商用IDEでは、 IDEが独自に未実装のメソッドを検知、雛形を生成する機能を実装している。


golangの場合は主に\texttt{josharian/impl}\cite{golang_impl}が使われている。
これはインストールすると\texttt{impl}コマンドが使用可能になり、 実装したいInterfaceの型と、 Interfaceを実装するImplの型(レシーバ)を与えることで雛形が生成される。
主要なエディタであるvscodeのgolangの公式パッケージである\texttt{vscode-go}\cite{vscode-go}でも導入されており、 vscodeから呼び出すことが可能である。
vscode以外にもvimなどのエディタからの呼び出しや、 シェル上で呼び出して標準出力の結果を利用することが可能である。

\section{GearsOSでのInterfaceを満たすCbCの雛形生成}
GearsOSでも同様のInterfaceの定義から実装するCodeGearの雛形を生成したい。
LanguageServerの導入も考えられるが、 今回の場合はC言語のLanguageServerをCbC用にまず改良し、 さらにGearsOS用に書き換える必要がある。
現状のGearsOSが持つシンタックスはCbCのシンタックスを拡張しているものではあるが、これはCbCコンパイラ側には組み込まれていない。
LanguageServerをGearsOSに対応する場合、 CbCコンパイラ側にGearsOSの拡張シンタックスを導入する必要がある。
CbCコンパイラ側への機能の実装は、 比較的難易度が高いと考えらる。
CbCコンパイラ側に手をつけず、 Interfaceの入出力の検査は既存のGearsOSのビルドシステム上に組み込みたい。

対してgolangの\texttt{impl}コマンドのように、 シェルから呼び出し標準出力に結果を書き込む形式も考えられる。
この場合は実装が比較的容易かつ、 コマンドを呼び出して標準出力の結果を使えるシェルやエディタなどの各プラットフォームで使用可能となる。
先行事例を参考に、コマンドを実行して雛形ファイルを生成するコマンド\texttt{impl2cbc.pl}をGearsOSに導入した。
\texttt{impl2cbc.pl}の処理の概要を図\ref{fig:impl2cbc}に示す。


\begin{figure}[hp]
  \begin{center}
   \includegraphics[width=130mm]{drawio/impl2cbc.pdf}
  \end{center}
  \caption{impl2cbcの処理の流れ}
  \label{fig:impl2cbc}
 \end{figure}

\subsection{雛形生成の手法}


Interfaceでは入力の引数がImplと揃っている必要があるが、 第一引数は実装自身のインスタンスがくる制約となっている。
実装自身の型は、Interface定義時には不定である。
その為、 GearsOSではInterfaceのAPIの宣言時にデフォルト型変数\texttt{Impl}を実装の型として利用する。
デフォルト型\texttt{Impl}を各実装の型に置換することで自動生成が可能となる。


実装すべきCodeGearはInterfaceとImpl側の型を見れば定義されている。
\texttt{\_\_code}で宣言されているものを逐次生成すればよいが、 継続として呼び出されるCodeGearは具体的な実装を持たない。
GearsOSで使われているInterfaceには概ね次の継続である\texttt{next}が登録されている。
\texttt{next}そのものはInterfaceを呼び出す際に、入力として与える。
その為各Interfaceに入力として与えられた\texttt{next}を保存する場所は存在するが、 nextそのものの独自実装は各Interfaceは所持しない。
したがってこれをInterfaceの実装側で明示的に実装することはできない。
雛形生成の際に、入力として与えられるCodeGearを生成してしまうと、プログラマに混乱をもたらしてしまう。

入力として与えられているCodeGearは、Interfaceに定義されているCodeGearの引数として表現されている。
コードに示す例では、\texttt{whenEmpty}は入力して与えられているCodeGearである。
雛形を生成する場合は、入力として与えられたCodeGearを除外して出力を行う。
順序はInterfaceをまず出力した後に、 Impl側を出力する。


\subsection{コンストラクタの自動生成}
雛形生成では他にコンストラクタの生成も行う。
GearsOSのInterfaceのコンストラクタは、 メモリの確保及び各変数の初期化を行う。
メモリ上に確保するのは主にInterfaceとImplのそれぞれが基本となっている。
Interfaceによっては別のDataGearを内包しているものがある。
その場合は別のDataGearの初期化もコンストラクタ内で行う必要があるが、 自動生成コマンドではそこまでの解析は行わない。


コンストラクタのメンバ変数はデフォルトでは変数は0、ポインタの場合はNULLで初期化するように生成する。
このスクリプトで生成されたコンストラクタを使う場合、 CbCファイルから該当する部分を削除すると、\texttt{generate\_stub.pl}内でも自動的に生成される。
自動生成機能を作成すると1CbCファイルあたりの記述量が減る利点がある。



明示的にコンストラクタが書かれていた場合は、 Perlスクリプト内での自動生成は実行しないように実装した。
これはオブジェクト指向言語のオーバーライドに相当する機能と言える。
現状のGearsOSで使われているコンストラクタは、 基本は\texttt{struct Context*}型の変数のみを引数で要求している。
しかしオブジェクトを識別するためにIDを実装側に埋め込みたい場合など、 コンストラクタ経由で値を代入したいケースが存在する。
この場合はコンストラクタの引数を増やす必要や、 受け取った値をインスタンスのメンバに書き込む必要がある。
具体的にどの値を書き込めば良いのかまではPerlスクリプトでは判定することができない。
このような細かな調整をする場合は、 generate\_stub.pl側での自動生成はせずに、 雛形生成されたコンストラクタを変更すれば良い。
あくまで雛形生成スクリプトはプログラマ支援であるため、 いくつかの手動での実装は許容している。


\section{Interfaceの引数の検知}

\section{InterfaceのAPIの未実装の検知}

\section{par goto のInterface経由の呼び出しの対応}