3

一般的な用語拡張ワークフローのライブラリ サポートを追加しています (1)。現在、用語拡張ルールのセット (2) がいずれかが成功するまで試行される「セット」ワークフローと、用語拡張ルールのセットからの拡張結果が渡される「パイプライン」ワークフローを定義しました。パイプラインの次のセット。あまり一般的ではありませんが、実用的な用途があり、ライブラリサポートの価値がある他の賢明な用語展開ワークフローがあるのではないかと思います.

(1) Logtalk の場合、現在のバージョンは次の場所にあります。

https://github.com/LogtalkDotOrg/logtalk3/blob/master/library/hook_pipeline.lgt https://github.com/LogtalkDotOrg/logtalk3/blob/master/library/hook_set.lgt

(2) 拡張規則のセットは、このコンテキストでは、term_expansion/2ユーザー定義のフック述語 (ユーザー定義のフック述語の可能性もありgoal_expansion/2ますが、ゴールに使用される固定小数点セマンティクスを考えると可能性は低いですが) の句のセットとして理解される必要があります。 -expansion) は、Prolog モジュールまたは Logtalk オブジェクト (user疑似モジュール/オブジェクト以外) で定義されています。

4

1 に答える 1

2

修正点は、展開中の特定のレベルで既にセットであり、パイプラインでもあります。その 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 句から複数のデルタ計算句が生成されます。

さよなら

于 2016-03-20T02:05:22.727 に答える