术语扩展工作流

Question

我正在为常见的术语扩展工作流添加库支持(1)。目前，我已经定义了一个" set“工作流，其中一组术语扩展规则(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)在此上下文中，一组扩展规则应理解为在Prolog模块或Logtalk对象(不同于user伪模块/对象)中定义的term_expansion/2用户定义的钩谓词(也可能是goal_expansion/2用户定义的钩谓词，尽管这不太可能是用于目标扩展的定点语义)的一组子句。

Answer 1

在扩展过程中，固定点既是集合又是某个级别上的管道。它的expand_term/2只是一步term_expansion/2子句的传递闭包。但这只在下降到一个术语期间有效，在我看来，我们在重新组合术语时也需要一些东西。

在极少数情况下，这种传递闭包甚至需要(==)/2检查，就像在一些Prolog系统中发现的那样。最有可能的是，如果没有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在扩展后交付如stage。

Jekejeke Prolog简化器和它集成到扩展框架中的是开源的here和here。例如，它用于对连接进行重新排序，以下是用于此目的的示例规则：

/* 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简化器是非常有效的，因为它可以在假设它接收到已经标准化的项的情况下工作。它不会在整个给定项上不必要地重复进行模式匹配。

但是它需要一些重写系统的通用实践来编写简化规则。简化规则应该在构造新术语时调用简化。

在上面的示例中，这些是两个sys_simplify_goal/2调用，例如，我们不会像扩展规则那样简单地返回一个包含(B,C)的新术语。由于(B,C)不是sys_goal_simplification/2的规范化参数的一部分，我们必须首先对其进行规范化。

但由于简化框架与扩展框架交织在一起，我怀疑它是否可以被称为工作流架构。没有明确的流向，结果就是乒乓球。然而，简化框架可以以模块化的方式使用。

Jekejeke Prolog简化程序也用于正向链子句重写。在那里，它确实从一个正向子句生成多个增量计算子句。

再见