修正点は、展開中の特定のレベルで既にセットであり、パイプラインでもあります。その expand_term/2 は、1 ステップの term_expansion/2 節の推移的な閉包です。しかし、これは用語への下降中にのみ機能します。私の意見では、用語を再度組み立てるときにも何かが必要です。
まれに、一部の Prolog システムで見られるように、この推移閉包では (==)/2 チェックが必要になることさえあります。ほとんどの場合、term_expansions/2 のどれも何もしない場合、単純に停止できます。したがって、基本的に (==)/2 チェックなしで次のようになります。
expand_term(X, Y) :- term_expansion(X, H), !, expand_term(H, Y).
expand_term(.. ..) :- /* possibly decend into meta predicate */
しかし、私が見たいのは、拡張フレームワークに追加された一種の単純化フレームワークです。したがって、メタ述語に落ち込んで戻ってくるときは、単純化フックを呼び出す必要があります。
これは、用語の書き換えに関するいくつかの理論に従っています。つまり、化合物の正規形 (nf) は、その部分の正規形の関数です。したがって、拡張フレームワークは通常の形式を処理せず、述語の再定義のみを提供しますが、単純化フレームワークは通常の形式の作業を行います。
nf(f(t_1,..,t_n)) --> f'(nf(t_1),..nf(t_n))
したがって、単純化フックはf(nf(t_1), .., nf(t_n))
、メタ述語に降りるときの expand_term がメタ引数に対して既にnf(t_1)
..を生成すると仮定して、単純化子に単純に与えることになります。nf(t_n)
f(nf(t_1), .., nf(t_n))
f'(nf(t_1), .., nf(t_n))
つまり、引数が既に簡略化されているという仮定に基づいて、作業を行い、簡略化された形式を返します。このような単純化は非常に強力です。Jekejeke Prolog はステージ アフター エキスパンションなどをお届けします。
Jekejeke Prolog simplifier とその拡張フレームワークへの統合は、こことここでオープン ソースです。たとえば、結合を並べ替えるために使用されます。この目的のルールの例を次に示します。
/* Predefined Simplifications */
sys_goal_simplification(( ( A, B), C), J) :-
sys_simplify_goal(( B, C), H),
sys_simplify_goal(( A, H), J).
Example:
(((a, b), c), d) --> (a, (b, (c, d)))
Jekejeke Prolog 単純化機能は、既に正規化された項を受け取るという前提で機能するため、非常に効率的です。指定された用語全体にわたってパターン マッチングを不必要に繰り返し実行することはありません。
ただし、単純化ルールを記述するには、システムの一般的な慣行を書き直す必要があります。単純化ルールは、新しい項を構成するたびに単純化を呼び出す必要があります。
上記の例では、これらは 2 つの呼び出しです。たとえば、拡張ルールが行うようにsys_simplify_goal/2
、新しい項を単純に返すわけではありません。は の正規化された引数の一部ではないため(B,C)
、最初に正規化する必要があります。(B,C)
sys_goal_simplification/2
しかし、単純化フレームワークは拡張フレームワークと絡み合っているため、ワークフロー アーキテクチャと呼ぶことができるかどうかは疑問です。特定の流れの方向はなく、結果はどちらかというとピンポンです。それにもかかわらず、単純化フレームワークはモジュール方式で使用できます。
Jekejeke Prolog 簡略化は、前方連鎖節の書き換えにも使用されます。そこでは、1 つの forward 句から複数のデルタ計算句が生成されます。
さよなら