prolog 在方法中被截断
我有一个问题想问您一些有关代码片段的问题：
insert_pq(State, [], [State]) :- !.
insert_pq(State, [H|Tail], [State, H|Tail]) :-
precedes(State, H).
insert_pq(State, [H|T], [H|Tnew]) :-
insert_pq(State, T, Tnew).
precedes(X, Y) :- X < Y. % < needs to be defined depending on problem
该函数非常清楚地将一个项目添加到优先级队列中。我遇到的问题是第一行的切断运算符。据推测，每当调用到达这行代码时，这是查询的唯一可能的解决方案，并且函数调用将简单地展开（或者结束？），无需回溯并搜索该查询的另一个解决方案询问。
所以这里的这个切断是多余的。我的推论正确吗？
I have a question I would like to ask you something about a code snippet:
insert_pq(State, [], [State]) :- !.
insert_pq(State, [H|Tail], [State, H|Tail]) :-
precedes(State, H).
insert_pq(State, [H|T], [H|Tnew]) :-
insert_pq(State, T, Tnew).
precedes(X, Y) :- X < Y. % < needs to be defined depending on problem
the function quite clearly adds an item to a priority queue. The problem I have is the cut off operator in the first line. Presumably whenever the call reaches this line of code this is the only possible solution to the query, and the function calls would simply unwind (or is it wind up?), there would be no need to back track and search for another solution to the query.
So this cut off here is superfluous. Am I correct in my deduction?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
是的，任何还算不错的 Prolog 编译器都会注意到没有其他子句的第二个参数是空列表。
在第二个子句的末尾会更有用，尽管我宁愿结合第二个和第三个子句并使用局部剪切（precedes(...) -> ... ; ...）。
Yes, any half-decent Prolog compiler will notice that there is no other clause where the second argument is an empty list.
It would be more useful at the end of the second clause, though I'd rather combine the second and the third clause and use a local cut (precedes(...) -> ... ; ...).
编译器用来消除匹配候选谓词的特殊技术称为参数索引。默认情况下，不同的 prolog 实现可能会索引不同数量的参数。
因此，如果您担心某个参数是否被索引，您应该检查您正在使用索引的序言中有多少个参数。根据 SWI 参考手册 默认情况下仅索引第一个参数。所以在你的情况下，削减实际上并不是多余的。不过，您可以使用上面链接中链接的谓词
index/1和hash/1明确规定应对哪些参数建立索引。或者你可以重新排序参数，或者你可以保留剪辑。
The particular technique that the compiler users to eliminate candidate predicates for matching is called argument indexing. Different prolog implementations could potentially index different numbers of arguments by default.
So if you're worried about whether an argument is being indexed or not, you should check how many arguments the prolog you're using indexes. According to the SWI reference manual it only indexes the first argument by default. So in your case the cut is actually not redundant. You can however explicitly stipulate which arguments should be indexed using the predicates
index/1andhash/1which are linked to in the above link.Or you could just reorder the arguments, or you could just keep the cut.
是的，你是对的。即使编译器不太好（SWI Prolog 肯定是这样），它能做的最糟糕的事情就是匹配第二个和第三个子句，这将立即失败。
但是，如果第二个子句匹配，则第三个子句也匹配。这是预期的行为吗？
Yes, you are correct. Even if the compiler isn't half-decent (which SWI Prolog certainly is), the worst it can do is match the second and third clauses, which will fail immediately.
However, if the second clause matches, the third does as well. Is this the intended behaviour?