Go to the first, previous, next, last section, table of contents.


The Ciao assertion package

Author(s): Manuel Hermenegildo, Francisco Bueno, German Puebla.

Version: 1.11#222 (2004/5/24, 13:8:7 CEST)

Version of last change: 1.5#8 (1999/12/9, 21:1:11 MET)

The assertions package adds a number of new declaration definitions and new operator definitions which allow including program assertions in user programs. Such assertions can be used to describe predicates, properties, modules, applications, etc. These descriptions can be formal specifications (such as preconditions and post-conditions) or machine-readable textual comments.

This module is part of the assertions library. It defines the basic code-related assertions, i.e., those intended to be used mainly by compilation-related tools, such as the static analyzer or the run-time test generator.

Giving specifications for predicates and other program elements is the main functionality documented here. The exact syntax of comments is described in the autodocumenter ( lpdoc [Knu84,Her99]) manual, although some support for adding machine-readable comments in assertions is also mentioned here.

There are two kinds of assertions: predicate assertions and program point assertions. All predicate assertions are currently placed as directives in the source code, i.e., preceded by ":-". Program point assertions are placed as goals in clause bodies.

More info

The facilities provided by the library are documented in the description of its component modules. This documentation is intended to provide information only at a "reference manual" level. For a more tutorial introduction to the subject and some more examples please see the document "An Assertion Language for Debugging of Constraint Logic Programs (Technical Report CLIP2/97.1)". The assertion language implemented in this library is modeled after this design document, although, due to implementation issues, it may differ in some details. The purpose of this manual is to document precisely what the implementation of the library supports at any given point in time.

Some attention points

Usage and interface (assertions)

Documentation on new declarations (assertions)

DECLARATION: pred/1:

This assertion provides information on a predicate. The body of the assertion (its only argument) contains properties or comments in the formats defined by assrt_body/1.

More than one of these assertions may appear per predicate, in which case each one represents a possible " mode" of use ( usage) of the predicate. The exact scope of the usage is defined by the properties given for calls in the body of each assertion (which should thus distinguish the different usages intended). All of them together cover all possible modes of usage.

For example, the following assertions describe (all the and the only) modes of usage of predicate length/2 (see lists):

:- pred length(L,N) : list * var => list * integer
	# "Computes the length of L.".
:- pred length(L,N) : var * integer => list * integer
	# "Outputs L of length N.".
:- pred length(L,N) : list * integer => list * integer
	# "Checks that L is of length N.".

Usage: :- pred(AssertionBody).

DECLARATION: pred/2:

This assertion is similar to a pred/1 assertion but it is explicitely qualified. Non-qualified pred/1 assertions are assumed the qualifier check.

Usage: :- pred(AssertionStatus, AssertionBody).

DECLARATION: calls/1:

This assertion is similar to a pred/1 assertion but it only provides information about the calls to a predicate. If one or several calls assertions are given they are understood to describe all possible calls to the predicate.

For example, the following assertion describes all possible calls to predicate is/2 (see arithmetic):

:- calls is(term,arithexpression).

Usage: :- calls(AssertionBody).

DECLARATION: calls/2:

This assertion is similar to a calls/1 assertion but it is explicitely qualified. Non-qualified calls/1 assertions are assumed the qualifier check.

Usage: :- calls(AssertionStatus, AssertionBody).

DECLARATION: success/1:

This assertion is similar to a pred/1 assertion but it only provides information about the answers to a predicate. The described answers might be conditioned to a particular way of calling the predicate.

For example, the following assertion specifies the answers of the length/2 predicate if it is called as in the first mode of usage above (note that the previous pred assertion already conveys such information, however it also compelled the predicate calls, while the success assertion does not):

:- success length(L,N) : list * var => list * integer.

Usage: :- success(AssertionBody).

DECLARATION: success/2:

This assertion is similar to a success/1 assertion but it is explicitely qualified. Non-qualified success/1 assertions are assumed the qualifier check.

Usage: :- success(AssertionStatus, AssertionBody).

DECLARATION: comp/1:

This assertion is similar to a pred/1 assertion but it only provides information about the global execution properties of a predicate (note that such kind of information is also conveyed by pred assertions). The described properties might be conditioned to a particular way of calling the predicate.

For example, the following assertion specifies that the computation of append/3 (see lists) will not fail if it is called as described (but does not compel the predicate to be called that way):

:- comp append(Xs,Ys,Zs) : var * var * var + not_fail.

Usage: :- comp(AssertionBody).

DECLARATION: comp/2:

This assertion is similar to a comp/1 assertion but it is explicitely qualified. Non-qualified comp/1 assertions are assumed the qualifier check.

Usage: :- comp(AssertionStatus, AssertionBody).

DECLARATION: prop/1:

This assertion is similar to a pred/1 assertion but it flags that the predicate being documented is also a " property."

Properties are standard predicates, but which are guaranteed to terminate for any possible instantiation state of their argument(s), do not perform side-effects which may interfere with the program behaviour, and do not further instantiate their arguments or add new constraints.

Provided the above holds, properties can thus be safely used as run-time checks. The program transformation used in ciaopp for run-time checking guarantees the third requirement. It also performs some basic checks on properties which in most cases are enough for the second requirement. However, it is the user's responsibility to guarantee termination of the properties defined. (See also section Declaring regular types for some considerations applicable to writing properties.)

The set of properties is thus a strict subset of the set of predicates. Note that properties can be used to describe characteristics of arguments in assertions and they can also be executed (called) as any other predicates.

Usage: :- prop(AssertionBody).

DECLARATION: prop/2:

This assertion is similar to a prop/1 assertion but it is explicitely qualified. Non-qualified prop/1 assertions are assumed the qualifier check.

Usage: :- prop(AssertionStatus, AssertionBody).

DECLARATION: entry/1:

This assertion provides information about the external calls to a predicate. It is identical syntactically to a calls/1 assertion. However, they describe only external calls, i.e., calls to the exported predicates of a module from outside the module, or calls to the predicates in a non-modular file from other files (or the user).

These assertions are trusted by the compiler. As a result, if their descriptions are erroneous they can introduce bugs in programs. Thus, entry/1 assertions should be written with care.

An important use of these assertions is in providing information to the compiler which it may not be able to infer from the program. The main use is in providing information on the ways in which exported predicates of a module will be called from outside the module. This will greatly improve the precision of the analyzer, which otherwise has to assume that the arguments that exported predicates receive are any arbitrary term.

Usage: :- entry(AssertionBody).

DECLARATION: modedef/1:

This assertion is used to define modes. A mode defines in a compact way a set of call and success properties. Once defined, modes can be applied to predicate arguments in assertions. The meaning of this application is that the call and success properties defined by the mode hold for the argument to which the mode is applied. Thus, a mode is conceptually a "property macro".

The syntax of mode definitions is similar to that of pred declarations. For example, the following set of assertions:

:- modedef +A : nonvar(A) # "A is bound upon predicate entry.".

:- pred p(+A,B) : integer(A) =>  ground(B).

is equivalent to:

:- pred p(A,B) : (nonvar(A),integer(A)) =>  ground(B)
   # "A is bound upon predicate entry.".

Usage: :- modedef(AssertionBody).

DECLARATION: decl/1:

This assertion is similar to a pred/1 assertion but it is used for declarations instead than for predicates.

Usage: :- decl(AssertionBody).

DECLARATION: decl/2:

This assertion is similar to a decl/1 assertion but it is explicitely qualified. Non-qualified decl/1 assertions are assumed the qualifier check.

Usage: :- decl(AssertionStatus, AssertionBody).

DECLARATION: comment/2:

Usage: :- comment(Pred, Comment).

Documentation on exports (assertions)

PREDICATE: check/1:

Usage: check(PropertyConjunction)

PREDICATE: trust/1:

Usage: trust(PropertyConjunction)

PREDICATE: true/1:

Usage: true(PropertyConjunction)

PREDICATE: false/1:

Usage: false(PropertyConjunction)


Go to the first, previous, next, last section, table of contents.