最好的 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 Efficient Prolog:实用指南"，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 和这Prolog 序言.

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 相结合，该术语是 7.1.6.2 的重命名副本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.

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

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 排序/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.

如有必要，将添加一个单独的程序描述，以程序上"开头.它再次完全不涵盖任何错误.这是标准描述的一大优点:错误都与做"分开，这有助于程序员(=内置用户)更系统地捕获错误.公平地说，它略微增加了想要手动优化的实施者的负担，并根据具体情况进行优化.无论如何，这种优化的代码往往容易出现细微的错误.

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 个错误，还有一个从上面的规范看不到的额外错误，见下文).

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 错误 中的注释和7.12.2 错误分类(总结).对于内置谓词 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屋！