什么是最好的 Prolog 编程实践和风格指南? [英] What are the best Prolog programming practices and style guidelines?

问题描述

好的，我知道这是一个非常笼统的问题，并且已经写了一些关于该主题的论文，但我觉得这些出版物涵盖了非常基本的材料，我正在寻找更高级的东西，以改善风格和效率.这是我在纸上写的:

OK, I know that this is very general question and that there were written some papers on the subject, but I have a feeling that these publications cover very basic material and I'm looking for something more advanced which would improve style and efficency. This is what I have in paper:

• 研究报告 AI-1989-08 高效序言:实用指南"，Michael A. Covington，1989 年
• Timo Knuutila 的高效 Prolog 编程"，1992 年
• Prolog 编码指南"，作者:Covington、Bagnara、O'Keefe、Wielemaker，Price，2011 年

这些内容涵盖的示例主题:尾递归和差异列表、正确使用索引、正确使用剪切、避免断言和撤回、避免 CONSing、代码格式指南(缩进、if-then-elses 等)、命名约定、代码文档、参数顺序、测试.

Sample subjects covered in these: tail recursion and differential lists, proper use of indexing, proper use of cuts, avoiding asserts and retracts, avoiding CONSing, code formatting guidelines (indentation, if-then-elses etc.), naming conventions, code documenting, arguments order, testing.

根据您个人使用 Prolog 的经验，您会在这里添加什么?是否有任何仅适用于 CLP 编程的特殊风格指南?您是否了解一些常见的效率问题并知道如何处理?

What would you add here from your own personal experience with Prolog? Are there any special style guidelines applicable only to CLP programming? Do you know of some common efficiency problems and know how to deal with them?

更新:

这里提出了一些有趣的(但对我来说仍然太基本和太笼统)的观点:Lifeware 团队的 Prolog 编程指南

Some interesting (but still too basic and too general for me) points are made here: Prolog programming guidelines of Lifeware Team

为了突出整个问题，我想引用Prolog 的编码指南"(Covington 等人):

Just to highlight the whole problem I would like to qoute "Coding guidelines for Prolog" (Covington et al.):

据我们所知，Prolog 的一套连贯且合理完整的编码指南从未出版过.此外，当我们查看已发布的 Prolog 程序的语料库时，我们没有看到事实上的标准正在出现.这种明显遗漏背后的最重要原因是，由于缺乏全面的语言标准，小型 Prolog 社区进一步分裂为以各个 Prolog 系统为中心的子社区，没有一个处于主导地位.

As far as we know, a coherent and reasonably complete set of coding guidelines for Prolog has never been published. Moreover, when we look at the corpus of published Prolog programs, we do not see a de facto standard emerging. The most important reason behind this apparent omission is that the small Prolog community, due to the lack of a comprehensive language standard, is further fragmented into sub-communities centered around individual Prolog systems, none of which has a dominant position.

推荐答案

对于在 Prolog 中设计干净的界面，我建议阅读 Prolog 标准，请参阅 iso-prolog.

For designing clean interfaces in Prolog, I recommend reading the Prolog standard, see iso-prolog.

特别是内置谓词如何编码的特定格式，其中包括特定的文档样式以及如何发出错误信号的方式.参见 ISO/IEC 13211-1:1995 的8.1 内置谓词定义的格式.您可以在 Cor.2 和这序言序言.

In particular the specific format how built-in predicates are codified which includes a particular style of documentation but also the way how errors are signaled. See 8.1 The format of built-in predicate definitions of ISO/IEC 13211-1:1995. You find definitions in that style online in Cor.2 and the Prolog prologue.

在 SICStus 和 SWI 中实现了 library(clpfd) 是一个很好的例子，它完全遵循 ISO 错误信号约定(但尚未标准化).虽然这两种实现在方法上有着根本的不同，但它们利用错误约定发挥了最大的优势.

A very good example of a library that follows the ISO error signaling conventions up to the letter (and yet is not standardized) is the implementation of library(clpfd) in SICStus and SWI. While both implementations are fundamentally different in their approach, they use the error conventions to their best advantage.

回到 ISO.这是内置谓词的 ISO 格式:

Back to ISO. This is ISO's format for built-in predicates:

一开始，可能有一个简短的可选非正式评论.

In the beginning, there may be a short optional informal remark.

给出了一个声明性描述，它通常以最一般的目标开始，使用描述性变量名称，以便以后可以引用它们.如果谓词的含义根本不是声明性的，则要么声明为是真的"，要么使用一些其他不必要的操作词，如统一"、组装".我举个例子:

A declarative description is given which starts very often with the most general goal using descriptive variable names such that they can be referred to later on. Should the predicate's meaning be not declarative at all, it is either stated "is true" or some otherwise unnecessary operationalizing word like "unifies", "assembles" is used. Let me give an example:

8.5.4 copy_term/2

8.5.4.1 说明

copy_term(Term_1, Term_2) 为真，仅当 Term_2 与术语 T 统一，后者是Term_1.

copy_term(Term_1, Term_2) is true iff Term_2 unifies with a term T which is a renamed copy (7.1.6.2) of Term_1.

所以这个unifying是一个很大的红色警告信号:永远不要认为这个谓词是一个关系，它只能在程序上理解.更重要的是，它(隐含地)声明第二个参数中的定义坚定.

So this unifies is a big red warning sign: Don't ever think this predicate is a relation, it can only be understood procedurally. And even more so it (implicitly) states that the definition is steadfast in the second argument.

另一个例子:sort/2.这现在是关系还是不是?

Another example: sort/2. Is this now a relation or not?

8.4.3 sort/2

8.4.3.1 说明

sort(List, Sorted) 为真，仅当 Sorted 与 List (7.1.6.5) 的排序列表统一.

sort(List, Sorted) is true iff Sorted unifies with the sorted list of List (7.1.6.5).

所以，再次，没有关系.惊讶?查看8.4.3.4 示例:

So, again, no relation. Surprised? Look at 8.4.3.4 Examples:

8.4.3.4 示例

...

sort([X, 1], [1, 1]).
   Succeeds, unifying X with 1.

sort([1, 1], [1, 1]).
   Fails.

如有必要，会添加单独的程序说明，​​以Procedurally,"开头.它也完全没有涵盖任何错误.这是标准描述的一大优点:错误都与做"分开，这有助于程序员(=内置用户)更系统地捕捉错误.公平地说，它稍微增加了想要手动和逐案优化的实现者的负担.无论如何，这种优化的代码通常容易出现细微的错误.

If necessary, a separate procedural description is added, starting with "Procedurally,". It again does not cover any errors at all. This is one of the big advantages of the standard descriptions: Errors are all separated from "doing", which helps a programmer (= user of the built-in) catching errors more systematically. To be fair, it slightly increases the burden of the implementor who wants to optimize by hand and on a case-to-case basis. Such optimized code is often prone to subtle errors anyway.

这里给出了参数模式和类型的全面的、单行或两行说明.该符号与其他起源于 1978 DECsystem-10 模式声明的符号非常相似.

Here, a comprehensive, one or two line specification of the arguments' modes and types is given. The notation is very similar to other notations which finds its origin in the 1978 DECsystem-10 mode declarations.

8.5.2.2 模板和模式

arg(+integer, +compound_term, ?term)

然而，ISO 的方法与 Covington 等人的指南之间存在很大差异，后者仅具有非正式性质并说明程序员应如何使用谓词.ISO 的方法描述了内置函数的行为 - 特别是应该预期哪些错误.(上面有 4 个错误，还有 1 个从上面的规范中看不到的额外错误，见下文).

There is, however, a big difference between ISO's approach and Covington et al.'s guideline which is of informal nature only and states how a programmer should use a predicate. ISO's approach describes how the built-in will behave - in particular which errors should be expected. (There are 4 errors following from above plus one extra error that cannot be seen from above spec, see below).

给出了所有错误条件，每个错误条件都在其自己的子条款中，按字母顺序编号.7.12 Errors 中的代码:

All error conditions are given, each in its own subclause numbered alphabetically. The codex in 7.12 Errors:

当满足多个错误条件时，Prolog 处理器报告的错误取决于实现.

When more than one error condition is satisfied, the error that is reported by the Prolog processor is implementation dependent.

这意味着，每个错误条件都必须说明其适用的所有先决条件.他们都是.错误条件不像 if-then-elsif-then...

That means, that each error condition must state all preconditions where it applies. All of them. The error conditions are not read like an if-then-elsif-then...

这也意味着编码人员必须付出额外的努力来寻找良好的错误条件.这完全有利于实际的用户程序员，但对于编码者和实现者来说肯定有点痛苦.

It also means that the codifier has to put extra effort for finding good error conditions. This is all to the advantage of the actual user-programmer but certainly a bit of a pain for the codifier and implementor.

根据8.1.3 错误 中的NOTES 和7.12.2 错误分类xyz2 中给出的规范，许多错误条件直接遵循/strong>(摘要).对于内置谓词 arg/3，错误 a、b、c、d 遵循规范.只有错误 e 不跟随.

Many error conditions directly follow from the spec given in x.y.z.2 according to the NOTES in 8.1.3 Errors and according to 7.12.2 Error classification (summary). For the built-in predicate arg/3, errors a, b, c, d follow from the spec. Only error e does not follow.

8.5.2.3 错误

a) N 是一个变量
—instantiation_error.

b) Term 是一个变量
—instantiation_error.

c) N 既不是变量也不是整数
—type_error(integer, N).

c) N is neither a variable nor an integer
—type_error(integer, N).

d) Term 既不是变量也不是复合词
—type_error(compound, Term).

d) Term is neither a variable nor a compound term
— type_error(compound, Term).

e) N 是一个小于零的整数
—domain_error(not_less_than_zero, N).

e) N is an integer less than zero
— domain_error(not_less_than_zero, N).

x.y.z.4 示例

(可选).

(可选).定义其他非常相似的谓词，它们可以被引导".

(Optional). Defines other predicates that are so similar, they can be "bootstrapped".

这篇关于什么是最好的 Prolog 编程实践和风格指南?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！