Which (part of the) database do clause/2 operate on?

Discussion related to the compliance of Prolog compilers with the current core standard

Moderator: Paulo Moura

Which (part of the) database do clause/2 operate on?

Postby gpiancastelli » Mon Mar 02, 2009 3:15 pm

Hello everyone,

I noticed that the specification for clause/2 (section 8.8.1) seems to contradict one of its examples, specifically the one searching for clauses of atom/1. While the example says that the outcome must be:

Code: Select all
permission_error(access, private_procedure, atom/1).


I simply expect a failure. In fact, the clause/2 description (8.8.1.1) prescribes:

Procedurally, clause(Head, Body) is executed as follows: a) Searches sequentially through each public user-defined procedures in the database and creates a list L of all the terms clause(H, B) such that: [...]


However, atom/1 is not a user-defined procedure, but a built-in. So, the list L for atom/1 should result as an empty list, and the goal should simply fail (as prescribed by 8.8.1.1 c) instead of throwing a permission error.

On a related note, section 7.5 tries to precisely define the differences between the concept of "database", i.e. the set of user-defined procedures which currently exist during execution, and of "complete database", i.e. a collection including the "database", the set of control constructs and the set of built-in predicates. In 8.8.1.1, however, the description of clause/2 just mention the "database":

clause(Head, Body) is true iff: [...] There is a clause in the database which corresponds to a term H :- B which unifies with Head :- Body.


and never says anything about the "complete database". So, it seems that clause/2 is only able to access the former, not the latter. As such, clause/2 shouldn't be able to say anything about built-in predicates such as atom/1, and should simply silently fail when asked to retrieve clauses for a built-in predicate.

(Note, also, the difference between the behaviour of clause/2 and current_predicate/1 in section 8.8.2. Indeed, current_predicate/1 is unable to access its own definition, and I think this happens because it is a built-in predicate, not a user-defined procedure.)

Does this reasonate with you, or have I missed something about the definition of the (complete) database and (user-defined) procedures?

Thank you!
gpiancastelli
 
Posts: 1
Joined: Mon Mar 02, 2009 2:50 pm
Location: Italy

Return to Core compliance

Who is online

Users browsing this forum: No registered users and 1 guest

cron