Dear @jan,

In the recent commit to improve listing/1 you wrote a predicate to generalize a term, I was wondering why didn’t you use subsumes_term/2? Perhaps I am missing something?

1 Like

Have you looked at my personal notes in this post.

1 Like

The reason was to fix the @EricGT example listing. Given some head, we should list all clauses that unify with this head. So, the nice thing is that if you have a concrete goal (with some instantiated arguments) and you ask for listing of that goal you only get the matching clauses. We should however not instantiate the clause head using the goal.

The current code generates all clauses and then does unification of the head using double negation to avoid instantiation of the head. Possibly it would have been better to use clause/3 with an instantiated head to get the clause reference and then clause/3 with an instantiated clause reference to get the raw clause. That does the decompilation twice, but exploits clause indexing if there are many clauses. Probably mostly theoretical as predicates that have rules typically have few clauses and predicates with many clauses typically only have facts and you typically just call the predicate to figure out which facts match.


This is very useful, especially for large databases. Thanks!

Care to add some details with examples and post it as one of

  1. Nice to know
  2. Useful code
  3. Wiki

A post was split to a new topic: Listing example