このブログの更新は Twitterアカウント @m_hiyama で通知されます。
Follow @m_hiyama

メールでのご連絡は hiyama{at}chimaira{dot}org まで。

はじめてのメールはスパムと判定されることがあります。最初は、信頼されているドメインから差し障りのない文面を送っていただけると、スパムと判定されにくいと思います。

参照用 記事

HoareRulesの実行フレームワーク

構文だけを示しても実感がないでしょうから、どのように実行されるかを記述します。実装言語はJavaということにします。

●コーラブルの実装方式

コーラブル(述語、関数、コマンド)に組み込みのものは存在しません。すべてユーザー定義です。次のようなインターフェースの実装クラスとしてコーラブルを定義します。


public interface Callable {
public Object call(Object[] args) throws Exception;
}


public interface Function extends Callable {
}


public interface Predicate extends Function {
Boolean call(Object[] args) throws Exception;
}


public interface Command extends Callable {
}

コーラブルの名前は、getName()を設けるとかアノテーションで書くとかの方法もありますが、ここでは素朴に“設定ファイル”を使うことにします。設定ファイルの1行は、「種別 名前 クラス名」とでもしておきましょう。例えば:


predicate empty org.example.hoge.Empty
predicate less org.example.hoge.Less
function add org.example.hoge.Add
command doUpdate com.example.foo.DoUpdate

この方式では次の点を注意する必要があります。

  1. 設定ファイルには引数・戻り値の情報がないので、引数の個数・型のチェックはコーラブル実装側の責任になる。
  2. ==, <, + などの基本的演算子もないので、コーラブルとして実装する必要がある。
  3. コーラブルが所属する名前空間はフラットなので、名前の衝突に気を付ける。

いずれも好ましくない特徴ですが、まー、これでもいいとします。ユーザー定義の(プラグインの)コーラブルは、引数なしコンストラクタで生成されて、設定された種別と名前で使用されます。

問題や要求があれば、コーラブルに関する情報を(アノテーションを含む)リフレクションにより取得して、精密な引数・戻り値情報に基づいた型チェックをフレームワーク側で行うことも考慮します(ってことは、問題/要求がなければやらないってこと)。

フレームワークの仕事

構文解析によって作られたルールのデータ構造をたどりながら、次のチェックをします。

  1. 条件式のトップレベルに出現するコーラブルが“存在する述語”であるかどうか。
  2. アクションのトップレベルに出現するコーラブルが“存在する”かどうか。
  3. 引数内に出現するコーラブルが“存在する関数”であるかどうか。

以前と考えが変わったのは、「アクションのトップレベルはコマンド」の制限をはずして、どんなコーラブルでもよい、としたところです。

次に、式とアクションの評価ですが:

  1. 変数は出現したら生成し(データ構造をたどったときに作っておいてもいいが)、初期値はnullとする。
  2. リテラルはそれ自身に評価される。
  3. コーラブルの呼び出しは、事前に全ての引数を評価して引数リスト(配列)を作り、生成したコーラブル実体のcallを呼び出す。
  4. 代入文は、右辺を評価した結果を変数としてセットする。代入文以外の“文の値”は捨てる。

変数とコーラブルは、名前をキーとしてマップで管理するでしょうが、変数とコーラブルで別なマップを使うことにします。つまり、同じ名前の変数とコーラブルを許します(この事を後で使うかもしれない)。

●それから

以上のような評価に便利なようにパーズ結果データ構造を考えることにします。それと、ルールの成功・失敗に応じた処理についても考える必要があります。