The Ciao assertion package

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

Version: 1.5#118 (2000/4/19, 18:13:43 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,Her99a]) 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
• Some attention points
• Usage and interface (assertions)
• Documentation on new declarations (assertions)
• Documentation on exports (assertions)

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

• Formatting commands within text strings: many of the predicates defined in these modules include arguments intended for providing textual information. This includes titles, descriptions, comments, etc. The type of this argument is a character string. In order for the automatic generation of documentation to work correctly, this character string should adhere to certain conventions. See the description of the docstring/1 type/grammar for details.
• Referring to variables: In order for the automatic documentation system to work correctly, variable names (for example, when referring to arguments in the head patterns of pred declarations) must be surrounded by an @var command. For example, @var{VariableName} should be used for referring to the variable "VariableName", which will appear then formatted as follows: VariableName. See the description of the docstring/1 type/grammar for details.

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).

• The following properties should hold at call time: AssertionBody is an assertion body. (assertions_props:assrt_body/1)

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).

• The following properties should hold at call time: AssertionStatus is an acceptable status for an assertion. (assertions_props:assrt_status/1) AssertionBody is an assertion body. (assertions_props:assrt_body/1)

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).

• The following properties should hold at call time: AssertionBody is a call assertion body. (assertions_props:c_assrt_body/1)

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).

• The following properties should hold at call time: AssertionStatus is an acceptable status for an assertion. (assertions_props:assrt_status/1) AssertionBody is a call assertion body. (assertions_props:c_assrt_body/1)

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).

• The following properties should hold at call time: AssertionBody is a predicate assertion body. (assertions_props:s_assrt_body/1)

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).

• The following properties should hold at call time: AssertionStatus is an acceptable status for an assertion. (assertions_props:assrt_status/1) AssertionBody is a predicate assertion body. (assertions_props:s_assrt_body/1)

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).

• The following properties should hold at call time: AssertionBody is a comp assertion body. (assertions_props:g_assrt_body/1)

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).

• The following properties should hold at call time: AssertionStatus is an acceptable status for an assertion. (assertions_props:assrt_status/1) AssertionBody is a comp assertion body. (assertions_props:g_assrt_body/1)

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).

• The following properties should hold at call time: AssertionBody is an assertion body. (assertions_props:assrt_body/1)

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).

• The following properties should hold at call time: AssertionStatus is an acceptable status for an assertion. (assertions_props:assrt_status/1) AssertionBody is an assertion body. (assertions_props:assrt_body/1)

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).

• The following properties should hold at call time: AssertionBody is a call assertion body. (assertions_props:c_assrt_body/1)

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).

• The following properties should hold at call time: AssertionBody is an assertion body. (assertions_props:assrt_body/1)

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).

• The following properties should hold at call time: AssertionBody is an assertion body. (assertions_props:assrt_body/1)

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).

• The following properties should hold at call time: AssertionStatus is an acceptable status for an assertion. (assertions_props:assrt_status/1) AssertionBody is an assertion body. (assertions_props:assrt_body/1)

DECLARATION: comment/2:

Usage: :- comment(Pred,Comment).

• Description: This assertion gives a text Comment for a given predicate Pred.
• The following properties should hold at call time: Pred is a head pattern. (assertions_props:head_pattern/1) Comment is a text comment with admissible documentation commands. The usual formatting commands that are applicable in comment strings are defined by stringcommand/1. See the lpdoc manual for documentation on comments. (assertions_props:docstring/1)

Documentation on exports (assertions)

PREDICATE: check/1:

Usage: check(PropertyConjunction)

• Description: This assertion provides information on a clause program point (position in the body of a clause). Calls to a check/1 assertion can appear in the body of a clause in any place where a literal can normally appear. The property defined by PropertyConjunction should hold in all the run-time stores corresponding to that program point. See also section Run-time checking of assertions.
• The following properties should hold at call time: PropertyConjunction is either a term or a conjunction of terms. The main functor and arity of each of those terms corresponds to the definition of a property. The first argument of each such term is a variable which appears as a head argument. (assertions_props:property_conjunction/1)

PREDICATE: trust/1:

Usage: trust(PropertyConjunction)

• Description: This assertion also provides information on a clause program point. It is identical syntactically to a check/1 assertion. However, the properties stated are not taken as something to be checked but are instead trusted by the compiler. While the compiler may in some cases detect an inconsistency between a trust/1 assertion and the program, in all other cases the information given in the assertion will be taken to be true. As a result, if these assertions are erroneous they can introduce bugs in programs. Thus, trust/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 (either because the information is not present or because the analyzer being used is not precise enough). In particular, providing information on external predicates which may not be accessible at the time of compiling the module can greatly improve the precision of the analyzer. This can be easily done with trust assertion.
• The following properties should hold at call time: PropertyConjunction is either a term or a conjunction of terms. The main functor and arity of each of those terms corresponds to the definition of a property. The first argument of each such term is a variable which appears as a head argument. (assertions_props:property_conjunction/1)

PREDICATE: true/1:

Usage: true(PropertyConjunction)

• Description: This assertion is identical syntactically to a check/1 assertion. However, the properties stated have been proved to hold by the analyzer. Thus, these assertions often represent the analyzer output.
• The following properties should hold at call time: PropertyConjunction is either a term or a conjunction of terms. The main functor and arity of each of those terms corresponds to the definition of a property. The first argument of each such term is a variable which appears as a head argument. (assertions_props:property_conjunction/1)

PREDICATE: false/1:

Usage: false(PropertyConjunction)

• Description: This assertion is identical syntactically to a check/1 assertion. However, the properties stated have been proved not to hold by the analyzer. Thus, these assertions often represent the analyzer output.
• The following properties should hold at call time: PropertyConjunction is either a term or a conjunction of terms. The main functor and arity of each of those terms corresponds to the definition of a property. The first argument of each such term is a variable which appears as a head argument. (assertions_props:property_conjunction/1)

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