▲◄►The lpdoc Documentation Generator » PART I - LPdoc Reference Manual »

The Ciao assertion language

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

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 contain formal specifications (such as sets of preconditions, post-conditions, or descriptions of computations) as well as 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 [PBH00]. 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

Documentation on new declarations

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:
    (assrt_body/1)AssertionBody is an assertion body.

DECLARATION
pred/2:
A pred assertion (see pred/1) can be qualified (as most other assertions) by an assertion status (assrt_status/1). If no assertion status is present (as in pred/1 assertions) the status is assumed to be check.

For example, the following assertion: 

:- pred length(L,N) : list * var => list * integer.
is equivalent to: 
:- check pred length(L,N) : list * var => list * integer.

Usage::- pred(AssertionStatus,AssertionBody).

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

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:
    (c_assrt_body/1)AssertionBody is a call assertion body.

DECLARATION
calls/2:
This assertion is similar to a calls/1 assertion but it is explicitely qualified with an assertion status. Non-qualified calls/1 assertions are assumed to have check status.

Usage::- calls(AssertionStatus,AssertionBody).

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

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:
    (s_assrt_body/1)AssertionBody is a predicate assertion body.

DECLARATION
success/2:
success assertion This assertion is similar to a success/1 assertion but it is explicitely qualified with an assertion status. The status of non-qualified success/1 assertions is assumed to be check.

Usage::- success(AssertionStatus,AssertionBody).

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

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:
    (g_assrt_body/1)AssertionBody is a comp assertion body.

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:
    (assrt_status/1)AssertionStatus is an acceptable status for an assertion.
    (g_assrt_body/1)AssertionBody is a comp assertion body.

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 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:
    (assrt_body/1)AssertionBody is an assertion body.

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:
    (assrt_status/1)AssertionStatus is an acceptable status for an assertion.
    (assrt_body/1)AssertionBody is an assertion body.

DECLARATION
texec/1:
This assertion is similar to a calls/1 assertion but it is used to provide input data and execution commands for run-time testing.

Usage::- texec(AssertionBody).

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

DECLARATION
texec/2:
This assertion is similar to a texec/1 assertion but it is explicitely qualified with an assertion status. Non-qualified texec/1 assertions are assumed to have check status.

Usage::- texec(AssertionStatus,AssertionBody).

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

DECLARATION
test/1:
This assertion is similar to a success assertion but it specifies a concrete test case to be run in order verify (partially) that the predicate is working as expected. For example, the following test will verify that the length predicate works well for the particular list given: 
:- test length(L,N) : ( L = [1,2,5,2] ) => ( N = 4 ).

Usage::- test(AssertionBody).

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

DECLARATION
test/2:
This assertion is similar to a test/1 assertion but it is explicitely qualified with an assertion status. Non-qualified test/1 assertions are assumed to have check status. In this context, check means that the test should be executed when the developer runs the test battery.

Usage::- test(AssertionStatus,AssertionBody).

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

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:
    (c_assrt_body/1)AssertionBody is a call assertion body.

DECLARATION
exit/1:
This type of assertion provides information about the answers that an (exported) predicate provides for external calls. It is identical syntactically to a success/1 assertion. However, it describes only external answers, i.e., answers to the exported predicates of a module from outside the module, or answers to the predicates in a non-modular file from other files (or the user). The described answers may be conditioned to a particular way of calling the predicate. E.g.:

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

Usage::- exit(AssertionBody).

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

DECLARATION
exit/2:
exit assertion This assertion is similar to an exit/1 assertion but it is explicitely qualified with an assertion status. Non-qualified exit/1 assertions are assumed the qualifier check.

Usage::- exit(AssertionStatus,AssertionBody).

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

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:
    (assrt_body/1)AssertionBody is an assertion body.

DECLARATION
decl/1:
This assertion is similar to a pred/1 assertion but it is used to describe declarations instead of predicates.

Usage::- decl(AssertionBody).

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

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:
    (assrt_status/1)AssertionStatus is an acceptable status for an assertion.
    (assrt_body/1)AssertionBody is an assertion body.

DECLARATION
doc/2:

Usage::- doc(Pred,Comment).

Documentation . This assertion provides a text Comment for a given predicate Pred, as well as other directives for the documenter.

  • The following properties should hold at call time:
    (head_pattern/1)Pred is a head pattern.
    (docstring/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.

DECLARATION
comment/2:

Usage::- comment(Pred,Comment).

An alias for doc/2 (deprecated, for compatibility with older versions).

  • The following properties should hold at call time:
    (head_pattern/1)Pred is a head pattern.
    (docstring/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.
  • The following properties should hold globally:
    (deprecated/1)DEPRECATED.

Documentation on exports

PREDICATE
check/1:

Usage:check(PropertyConjunction)

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 Run-time checking of assertions.

  • The following properties should hold at call time:
    (property_conjunction/1)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.

PREDICATE
trust/1:

Usage:trust(PropertyConjunction)

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:
    (property_conjunction/1)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.

PREDICATE
true/1:

Usage:true(PropertyConjunction)

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:
    (property_conjunction/1)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.

PREDICATE
false/1:

Usage:false(PropertyConjunction)

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:
    (property_conjunction/1)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.

Package Sections

Global Links

Indices

▲◄► 
Generated with LPdoc using Ciao