\chapter{評価}


\section{GearsOSの構文作製}
GearsOSで使われるInterface、およびそのImplementの型定義ファイルを導入した。
GearsOSでプログラミングする際に通常のC言語やJavaなどの言語の様に、まず型を作成してからプログラミングすることが可能になった。
言語機能としてはC言語や純粋なCbCより進化しており、現代的と言われるRustやgolangと比較しても十分に実用的な言語になったと言える。

ただし現状のGearsOSでは1ファイルに1つの型定義しかできない。
これは今回実装したInterfaceのパーサーであるGears::Interfaceや、generate\_stub.plのInterfaceのインクルード処理が、現状InterfaceまたImplのファイル名と型名が同じである前提でプログラミングされている為である。
アプリケーションとしてGearsOSを動かす現在の例題ではそこまで問題になっていない。
しかし、CbC xv6などの実用的なアプリケーションを実装する場合は、ファイルの数が莫大になる可能性がある。
1ファイル内で様々な型が定義可能になれば、 より見通しの良いプログラミングが可能であると考えられる。
改善の手法としては、トランスパイル時にすべてのヘッダファイルをパースし、型名とファイルパスの対応表を作れば可能であると推測される。
ただし本研究ではファイルごと作製すれば、ひとまずは問題ない為に実装を見送っている。

\section{GearsOSのトランスパイラ}
GearsOSのトランスパイラは、従来はエラーを出さずCbCファイルを変換するだけであった。
本研究によってPerlトランスパイラレベルでのエラーの生成を可能にし、 GearsOSのメタレベルのコードを読まずともバグ検知が可能となった。
またInterfaceのパーサーなどのAPIを定義したことによって、 トランスパイラ側での様々な処理の拡張性を高めることが可能となった。

今まではGearsOSのモジュール化の仕組みとして使っていたInterfaceであるが、より一般的なInterfaceの使いかたに近づいたと言える。
特に今まではInterfaceで定義したAPIを満たしていなくても、 GearsOSは容赦なくビルドを進めてしまう問題があった。
これによりメタコードが含まれた状態でしかコンパイルエラーを発見できなかった。
またコンパイルエラーも出ず、動作させてみないと解らないエラーも存在していた。

Interface機能が充実したことにより、これらのエラーがビルド時に明確に解るようになった。
従来行っていたデバッグもコンパイルエラーが発生するため不必要になり、よりプログラミングすることがやりやすい言語になった。
また、目的としていたメタレベルとノーマルレベルの分離を、コンパイルエラーという観点でもできるようになったと考える。
従来の実装との後方互換性も高く保証している。
GearsOSで現在実装されている例題は、 CMakeListの中に定義されているが、おおよその例題でビルドが通ることが確認された。
これによって本研究で実装したInterface機能は、従来のInterface機能と干渉せずに、すでに実装された資産を活用することが可能となった。


しかし導入したジェネリクス機能については議論の余地がある。
Perlトランスパイラ側での実装を行ったが、非常に実装するのが困難であった。
これはC言語から派生したGearsOSのシンタックスと、それを正規表現を主に使ってコード変換を行うPerlトランスパイラが、ジェネリクスとの相性が合わなかった為である。
ジェネリクスを使う場合、GearsOSのコードを字句解析や構文解析を詳細にする必要があることが実装を通して判明した。
しかしこれをPerlトランスパイラで行うと、Perl側でCbCコンパイラを実装することになる。
これはもはやCbCコンパイラ側にジェネリクスを導入したほうが信頼性が高い。
さらにPerlトランスパイラは基本置換で処理を行う。
ジェネリクスの場合、型名を置換する必要があり、不必要な場所まで置換してしまう恐れがある。
その為Perlトランスパイラレベルではジェネリクスのサポートを続けるのは困難であると考える。

\section{GearsOSのメタ計算}
従来のGearsOSではcontext.hやStubCodeGearなどのメタレベルのコードは、比較的手動で実装する必要があった。
自由度は高いものの、様々な場面で登場するメタレベルのコードをすべて書くのは煩雑である。
本研究によってメタ計算の自動生成機能がより強化され、さらにメタレベルの計算を活用することが可能となった。
特にmeta.pmによるMetaCodeGearの切り替えは強力であり、任意のMetaCodeGearに継続することで、モデル検査やGearsOSのデバッグ機能などを組み込むことが可能となった。