5

正如我似乎再也找不到的另一个 StackOverflow 答案中所述，这种模式经常出现在实际的 Prolog 代码中：

pred(X) :-
    guard(X),
    ...
pred(X) :-
    \+ guard(X),
    ...

许多人试图将其浓缩为

pred(X) :-
    (guard(X) ->
    ...
    ;
    ...).

然而众所周知，箭头结构破坏了选择点并且不合逻辑。

在 Ulrich Neumerkel 和 Stefan Kral 的Indexing dif/2中，提出了一个单调且合乎逻辑的谓词if_/3，但是在论文中他们提到了另一个引起我注意的构造：*->.

该*->构造函数的功能与上面的未加糖保护子句示例完全相同，因此它似乎非常适合我的使用，因为我不想拥有所需的具体条件，if_/3而且我不太关心额外的选择点。如果我没记错的话（编辑：我是），它提供了与条件谓词相同的语义，if_/3但不需要将“具体化”添加到条件谓词中。

然而，在它的 SWI 文档中，它声称“这种结构很少使用”，这对我来说似乎很奇怪。在我看来，这比您尝试进行纯逻辑编程时要*->好得多。->是否有任何理由避免这种结构，或者是否有更好的替代整个保护条款/否定保护条款模式？

4

2 回答 2

4

让我们试试吧！你给的模式是：

预测（X）：-
    （守卫（X）->
         ...
    ; ...
    ）。

我现在使用(*->)/2并填写“...”如下：

预测（X）：-
        （守卫（X）*->
            假
        ；   真
        ）。

此外，作为guard/1，我定义了明显的纯谓词：

后卫（一）。

现在，让我们问pred/1一个最普遍的问题：有什么解决方案吗？

?- pred(X)。
错误的。

所以，根据谓词，没有X这样的词pred(X)是真的。

但这是错误的，因为实际上有这样一个术语：

?- pred(b)。
真的。

事实上，pred/1有无穷多的解。在这种情况下，谓词状态根本没有是可以接受的吗？当然，因为答案的计算效率非常高，不是吗？

我们得出的结论是，它(*->)/2有一个重要的缺点：如果仅进一步实例化条件中出现的变量，则在适用不同(->)/2分支的情况下，它可能会错误地提交到其中一个分支。以这种方式依赖于其参数的实例化的谓词永远不可能是纯的，因为它抵消了我们期望适用于纯逻辑程序的单调推理。特别是，从逻辑的角度来看，既然成立，我们期望是 的概括，一定不能失败pred(b)pred(X)pred(b). 一旦这个属性被破坏，你就不能再应用声明式调试和其他让你更容易理解、推理和管理 Prolog 程序的重要方法，而这首先构成了声明式编程的主要吸引力。

您提到的问题可能是What uses does if_3/have ? .

于 2018-10-31T17:44:46.587 回答
1

通常命名的软切割控制结构在几个 Prolog 系统中可用。CxProlog、ECLiPSe、JIProlog、SWI-Prolog 和 YAP 将它作为*->/2谓词和中缀运算符提供。Ciao Prolog、SICStus Prolog 和 YAP 提供if/3具有相同语义的谓词。

我对这个软切割控制结构的主要用途是在 Logtalk 中实现coduction，它在其中起着关键作用。在这种情况下，我很少使用它。

->/2另一方面，它被广泛使用。if部分中的隐式切割对于 结构来说是本地的，并且它的使用避免了，如在您的示例中，尝试两次证明守卫，这在计算上可能是昂贵的。它可能不是纯粹的，但与剪辑一样，只要您完全了解它的优缺点，它就是一个有用的控制结构。

PS Logtalk 为https://github.com/LogtalkDotOrg/logtalk3/tree/master/tests/prolog/control/soft_cut_2_3上的变体和https://github.com/LogtalkDotOrg*->/2上的变体提供此控制构造的单元测试/logtalk3/tree/master/tests/prolog/control/if_3if/3

于 2018-10-31T16:56:32.140 回答