ISO/IEC JTC1 SC22 WG17 Post-N225
Built-in predicates, current practice

Ulrich Neumerkel (Version history)

This is the final state of the document as it was used for the resolutions in Edinburgh. In the meantime many systems adopted accordingly. This document is superseded by DTC2.

5.5.9 Built-in predicates
A processor may support one or more additional built-in
predicates (8) as an implementation specific feature.

Implementation specific built-in predicates

Implementors interested in standardization who wish to see their system listed in this table are asked to provide a table in HTML with the complete first row and one row for their system. Please consider only additional built-in predicates if you believe that they should be part of the Prolog core.

bip :	built-in predicate
lib :	library - must be loaded explicitly
pdp :	pre-defined predicate - either autoloaded or pre-defined otherwise.
alt :	alternate name or very close alternate definition
- :	this built-in is not present
empty :	this field is unknown, please help to remove the unknowns!

call/2-8

setup_call_cleanup/3

subsumes/2

Changed by A.1 c, Pasadena 2009 (removed text striked through, new text highlighted, problematic text underscored):

8.2.4.1 Description
subsumes(General, Specific) is true iff there is a substitution θ, including the empty substitution, such that the term General is instantiated. Generalθ = Specific = Specificθ . This predicate provides a one-way unification.

The last sentence should go reformulated into subclause 8.2.4 (precedent: 8.10.2 bagof/3).

---

In the literature one sided unification (semi-unification) is defined as Generalθ = Specificθ = Specific. Related to this is the notion of matching, that sometimes is referred to as one-way unification. That other kind of matching is defined as General θ = Specific. Now for f(X) and f(g(X)) the substitution (3.171) θ = {X → g(X)} is a matcher, but this is not one-sided unification. Example from Hans-Jürgen Bürckert, Matching - A Special Case of Unification? in Claude Kirchner (ed.), Unification, Academic Press, 125-138 1990.

---

Proposal for a property: For all terms X, Y: subsumes(X,Y) iff subsumes(g(X),g(Y)). (This property allows to wrap terms up).

---

Originally from O'Keefe's METUTL.PL (1983-05-20).

---

subsumes/2 could be expressed as a bootstrapped built-in predicate:

subsumes(General, Specific) :-
   subsumes_chk(General, Specific),
   General = Specific.

subsumes_term/2

The following definition has not yet been presented to WG17. It may replace the current definition of subsumes/2. There has been a vivid discussion on the SWI list.

8.2.4 subsumes_term/2

This built-in predicate provides a test for syntactic one-sided unification.

8.2.4.1 Description

subsumes_term(General, Specific) is true iff there is a substitution θ such that

Generalθ and Specificθ are identical, and
Specificθ and Specific are identical.

Procedurally, subsumes_term(General, Specific) simply succeeds or fails accordingly. There is no side effect or unification.

8.2.4.2 Template and modes

subsumes_term(@term, @term)

8.2.4.3 Errors

None.

8.2.4.4 Examples

subsumes_term(a, a).
   Succeeds.

subsumes_term(f(X,Y), f(Z,Z)).
   Succeeds.

subsumes_term(f(Z,Z), f(X,Y)).
   Fails.

subsumes_term(g(X), g(f(X))).
   Fails.

subsumes_term(X, f(X)).
   Fails.

subsumes_term(X, Y), subsumes_term(Y, f(X)).
   Succeeds.

NOTES
1 subsumes_term/2 is not transitive. The last two examples above illustrate this.
2 A related built-in predicate subsumes/2 is implemented in many existing processors. In addition to testing for one-sided unifiability, it binds the first argument to become the second. In many situations this binding leads to erroneous programs. The following definition is deprecated and is mentioned here only for backwards compatibility.

subsumes(General, Specific) :-
   subsumes_term(General, Specific),
   General = Specific.

In SICStus since 2.1#7 (1993-02-08), originally from Richard O'Keefe's METUTL.PL (1983-05-20).

(>=<)/2

Defined for arithmetics

(?=)/2

X and Y are either syntactically identical or syntactically non-unifiable.

arity/2

arity(Term, Arity) is the same as functor(Term, _, Arity). Maybe rather an evaluable functor arity/1.

between/4

between(+From, +To, +Step, ?Result)

between/3

between(+From, +To, ?I)

is_list/1

True iff Argument is a list (3.99). [a,b|c] is not a list, [_|_] is not a list.

sort/2

Bootstrapped definition

sort(Xs, Sorted) :-
   setof(X, member(X,Xs), Sorted).
sort([], []).

Is sort(@list, ?list) a good mode? After all

?- sort([A],[a]).
A = a.

keysort/2

Bootstrapped definition

mykeysort(KV_s, Sorted) :-
   bagof(K-V,
      Vs^
         ( setof(K-Vs, bagof(V, member(K-V,KV_s), Vs), KVs_s),
           member(K-Vs, KVs_s),
	   member(V, Vs)
         ),
      Sorted).
mykeysort([], []).

Is keysort(@list, ?list) a good mode? After

term_variables/2

Unify VARIABLES with the list of all variables of term TERM. The variables occur in depth-first, left-to-right traversal order.

variant/2.

Implementations do not implement the logical form of variant, but rather a very "implementation oriented" one which works safely only if there is no variable occuring in both arguments. In particular, variant(A-B,B-A). and variant(A-B,B-C). most often fail. This behaviour can be easily emulated with:

variant_halfcorrect(A, B) :-
   subsumes_term(A, B),
   subsumes_term(B, A).

The more costly version would them be:

variant_correct(A, B) :-
   copy_term(A, AC),
   subsumes_term(AC, B),
   subsumes_term(B, AC).

Previous documents