CVC4 - User contributions [en]

Sets

2018-04-24T21:56:41Z

Tinelli:

=Finite Sets=

As of July 2014 (CVC4 v1.4), we include support for theory of finite sets. The simplest way to get a sense of the syntax is to look at an example:
* [https://github.com/CVC4/CVC4/blob/1.4/test/regress/regress0/sets/cvc-sample.cvc CVC language example]
* [https://github.com/CVC4/CVC4/blob/1.4/test/regress/regress0/sets/sets-sample.smt2 SMT language example]
* API example: [[Tutorials#Sets|tutorial]], [https://github.com/CVC4/CVC4/blob/1.4/examples/api/sets.cpp source code]

For reference, below is a short summary of the sorts, constants, functions and predicates.

{| class="wikitable" cellpadding="5" border="0" style="border-collapse:collapse"
|-
!
! CVC language
! SMTLIB language
! C++ API
|-
| Logic string
| Not needed
| append "FS" for finite sets
| append "FS" for finite sets
|-
|
|
| <code>(set-logic QF_UFLIA'''FS''')</code>
| <code>smt.setLogic("QF_UFLIA'''FS'''");</code>
|-
| Sort
| SET OF <Element Sort>
| (Set <Element Sort>)
| CVC4::ExprManager::mkSetType(CVC4::Type elementType)
|-
|
| <code>X: '''SET OF INT''';</code>
| <code>(declare-fun X () '''(Set Int)''')</code>
| <code>em.'''mkSetType'''( em.integerType() );</code>
|-
| Union
| <code>X '''<nowiki>|</nowiki>''' Y</code>
| <code>('''union''' X Y)</code>
| <code>em.mkExpr('''kind::UNION''', X, Y);</code>
|-
| Intersection
| <code>X '''<nowiki>&</nowiki>''' Y</code>
| <code>('''intersection''' X Y)</code>
| <code>em.mkExpr('''kind::INTERSECTION''', X, Y);</code>
|-
| Set subtraction
| <code>X '''<nowiki>–</nowiki>''' Y</code>
| <code>('''setminus''' X Y)</code>
| <code>em.mkExpr('''kind::SETMINUS''', X, Y);</code>
|-
| Membership
| <code>x '''<nowiki>IS_IN</nowiki>''' X</code>
| <code>('''member''' x X)</code>
| <code>em.mkExpr('''kind::MEMBER''', x, X);</code>
|-
| Subset
| <code>X '''<nowiki><=</nowiki>''' Y</code>
| <code>('''subset''' X Y)</code>
| <code>em.mkExpr('''kind::SUBSET''', X, Y);</code>
|-
| Empty set
| {} :: <Type Ascription>
| (as emptyset <Type Ascription>)
| CVC4::EmptySet(CVC4::SetType setType)
|-
|
| <code>'''{}''' :: SET OF INT</code>
| <code>(as '''emptyset''' (Set Int))</code>
| <code>em.mkConst('''EmptySet'''(em.mkSetType(em.integerType())));</code>
|-
| Singleton set
| <code>'''{1}'''</code>
| <code>('''singleton''' 1)</code>
| <code>em.mkExpr('''kind::SINGLETON''', oneExpr);</code>
|-
| Cardinality
| <code>'''<nowiki>CARD</nowiki>'''( X )</code>
| <code>('''card''' X)</code>
| <code>em.mkExpr('''kind::CARD''', X);</code>
|-
| Insert/finite sets
| <code>'''{1, 2, 3, 4}'''</code>
| <code>('''insert''' 1 2 3 (singleton 4))</code>
| <code>em.mkExpr('''kind::INSERT''', c1, c2, c3, sgl4);</code>
|-
| Complement
| <code>'''<nowiki>~</nowiki>''' X</code>
| <code>('''complement''' X)</code>
| <code>em.mkExpr('''kind::COMPLEMENT''', X);</code>
|-
| Universe set
| UNIVERSE :: <Type Ascription>
| (as univset <Type Ascription>)
|
|-
|
| <code>'''UNIVERSE''' :: SET OF INT</code>
| <code>(as '''univset''' (Set Int))</code>
| <code>em.mkNullaryOperator(em.mkSetType(em.integerType()),'''kind::UNIVERSE_SET''');</code>
|}

Operator precedence for CVC language:
<code><nowiki>&</nowiki></code>
<code><nowiki>|</nowiki></code>
<code><nowiki>–</nowiki></code>
<code><nowiki>IS_IN</nowiki></code>
<code><nowiki><=</nowiki></code>
<code><nowiki>=</nowiki></code>. For example, <code>A - B | A & C <= D</code> is read as <code>( A - ( B | (A & C) ) ) <= D</code>.

=Finite Relations=

{| class="wikitable" cellpadding="5" border="0" style="border-collapse:collapse"
|-
!
! CVC language
! SMTLIB language
! C++ API
|-
| Logic string
| Not needed
| --
| --
|-
|
|
| --
| --
|-
| Sort
| SET OF [ElementSort_1, ..., ElementSort_n]
| (Set (Tuple ElementSort_1, ..., ElementSort_n))
| --
|-
|
| <code>X: '''SET OF [INT, INT]''';</code>
| <code> (declare-fun X () (Set (Tuple Int Int))) </code>
| <code> -- </code>
|-
| Transpose
| <code>'''<nowiki>TRANSPOSE</nowiki>'''(X) </code>
| <code> ('''transpose''' X) </code>
| <code> -- </code>
|-
| Transitive Closure
| <code>'''<nowiki>TCLOSURE</nowiki>'''(X) </code>
| <code> ('''tclosure''' X) </code>
| <code> -- </code>
|-
| Join
| <code> X '''<nowiki>JOIN</nowiki>''' Y </code>
| <code> ('''join''' X Y) </code>
| <code> -- </code>
|-
| Product
| <code> X '''<nowiki>PRODUCT</nowiki>''' Y </code>
| <code> ('''product''' X Y) </code>
| <code> -- </code>
|-

Note: Currently, we only support encoding relational constraints in CVC4 native language. Support for SMT-LIB language is coming soon.

About CVC4

2018-04-24T21:55:35Z

Tinelli:

CVC4 is an automatic theorem prover for [http://en.wikipedia.org/wiki/Satisfiability_Modulo_Theories Satisifiability Modulo Theories (SMT)] (for a more formal introduction to SMT see the following book chapter [https://cs.stanford.edu/~barrett/pubs/BSST09.pdf Satisfiability Modulo Theories] ). Technically, it is an automated validity checker for a many-sorted (i.e., typed) first-order logic with built-in theories.
It can be used to prove the validity (or, dually, the satisfiability) of a formula with respect to several built-in logical theories and their combination.

CVC4 currently has support for the following theories:
* equality over free (aka uninterpreted) function and predicate symbols
* real and integer linear arithmetic
* bit-vectors
* arrays
* tuples
* records
* user-defined inductive [[Datatypes|datatypes]]
* [[Strings|strings]]
* [[Sets|finite sets and relations]]
* [[Separation Logic|separation logic]]

CVC4 has a wide variety of features including:

* support for quantifiers through heuristic instantiation;
* an interactive text-based interface;
* a rich [http://cvc4.cs.stanford.edu/cvc4-builds/documentation/public/latest/ C++ API] for embedding in other systems;
* model generation abilities;
* source compatibility with much of the CVC3 API via a "compatibility library";
* essentially no limit on its use for research or commercial purposes (see [https://github.com/CVC4/CVC4/blob/master/COPYING license]).

=Web site=

For more information and the latest news about CVC4, visit the [http://cvc4.cs.stanford.edu CVC4 web site].

=Decision Procedures=
* Architecture
** See the [http://dl.acm.org/citation.cfm?id=2032319 CVC4 tool paper].
* Arithmetic
** CVC4 solves linear real arithmetic using an implementation of [http://link.springer.com/chapter/10.1007%2F11817963_11? Simplex for DPLL(T)]. For a more complete introduction see the [http://yices.csl.sri.com/sri-csl-06-01.pdf tech report].
** The linear arithmetic module includes heuristics from [http://eprints-phd.biblio.unitn.it/166/2/thesis.pdf Section 2.5 of Alberto Griggio's thesis] and a few currently unpublished ones.
** Integers are currently handled by first solving the real relaxation of the constraints, and then using a combination of [http://www.cs.wm.edu/~idillig/cav2009.pdf Cuts from Proofs] and branching to ensure integer solutions. This approach and the equational solver used are described in [https://es.fbk.eu/people/griggio/papers/jsat12.pdf A Practical Approach to Satisfiability Modulo Linear Integer Arithmetic].
** A technical report is planned to explain a number of small details and extensions including analysis to improve simplex's conflicts, handling disequalities, supporting model generation in CVC4's combination framework, heuristically propagating equalities over sharing terms, tableau row based propagation, and terminating simplex with unknown.
** Non-linear arithmetic support is currently rudimentary to non-existent. In CVC4 v1.0, non-linearity is handled by abstracting monomials as unique new variables. We plan on implementing [http://cs.nyu.edu/~dejan/papers/jovanovic-ijcar2012.pdf Solving Non-Linear Arithmetic] this spring.
* Arrays
** Arrays are implemented in a manner inspired by the [http://research.microsoft.com/en-us/um/people/leonardo/files/fmcad09.pdf Generalized, efficient array decision procedures] paper with a few major modifications.
* Bitvectors
** Bitvectors is implemented primarily via a lazy schema for bitblasting. See [http://eprints-phd.biblio.unitn.it/345/ Anders Franzen's thesis chapter 3].
* Combination
** Theory combination is based on the care graph framework described in both [http://cs.nyu.edu/~dejan/papers/jovanovic-fmsd2012.pdf Being careful about theory combination] and [http://cs.nyu.edu/~dejan/papers/jovanovic-frocos2011.pdf Sharing is Caring: Combination of Theories].
* Datatypes
** CVC4 implements [http://homepage.cs.uiowa.edu/~tinelli/papers/BarST-JSAT-07.pdf An Abstract Decision Procedure for a Theory of Inductive Data Types].
** This procedure has been extended to incorporate coinductive datatypes [http://homepage.cs.uiowa.edu/~ajreynol/cade15.pdf].
* Quantifiers
** E-matching and conflict-based quantifier instantiation [http://homepage.cs.uiowa.edu/~ajreynol/fmcad14.pdf].
** Finite model finding [http://homepage.cs.uiowa.edu/~ajreynol/thesis.pdf].
** Techniques for finding counterexamples for conjectures in the presence of recursive functions [http://homepage.cs.uiowa.edu/~ajreynol/ijcar16a.pdf].
** Automated induction for datatypes [http://homepage.cs.uiowa.edu/~ajreynol/vmcai15.pdf].
** A decision procedure for quantified linear arithmetic with one alternation [http://homepage.cs.uiowa.edu/~ajreynol/report-inst-la15.pdf].
** Support for syntax-guided synthesis, as described in [http://homepage.cs.uiowa.edu/~ajreynol/cav15a.pdf].
* SAT Solver
** The main sat solver is based on [http://minisat.se/ minisat v2.2.0].
** Additionally, we (optionally, and enabled by default for certain theories) use non-clausal analysis to cut down search space of minisat. For more details see the article [http://cs.nyu.edu/~kshitij/articles/cvc4-branching-heuristic.pdf A branching heuristic in CVC4].
* Separation Logic
** A decision procedure for a fragment quantifier-free separation logic containing negation, separation star and magic wand is implemented and can be composed with other decision procedures supported by CVC4. For details see [http://homepage.divms.uiowa.edu/~ajreynol/atva16.pdf A Decision Procedure for Separation Logic in SMT].
* Sets
** Adaptation of tableau-based decision procedure described [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.10.5176 here].
* Strings
** Original approach described in our [http://www.cs.stanford.edu/~barrett/pubs/LRT+14.pdf CAV 2014 paper: A DPLL(T) Theory Solver for a Theory of Strings and Regular Expressions].
** Decision procedure for regular memberships with length [http://homepage.cs.uiowa.edu/~ajreynol/frocos15.pdf].
* Uninterpreted functions
** UF (without cardinality) is handled in a manner inspired by [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.70.1745 Simplify's tech report].
** UF + cardinality is described [http://www.divms.uiowa.edu/~ajreynol/pres-fmf12.pdf this presentation] and is used for finite model finding.

=History of CVC=

[[File:svc.gif|thumb|border|100px|The SVC logo.]]
[[File:cvc3_logo.jpg|thumb|border|100px|The CVC3 logo.]]
[[File:cvc3_night_logo.png|thumb|border|100px|The CVC3 "by night" logo, used for nightly builds and regressions.]]
[[File:cvc3cvc4.png|thumb|border|100px|An early CVC4 logo.]]

The Cooperating Validity Checker series has a long history. The
Stanford Validity Checker (SVC) came first in 1996, incorporating
theories and its own SAT solver. Its successor, the Cooperating
Validity Checker (CVC), had a more optimized internal design, produced
proofs, used the Chaff SAT solver, and featured a number of usability
enhancements. Its name comes from the cooperative nature of decision
procedures in Nelson-Oppen theory combination, which share amongst
each other equalities between shared terms. CVC Lite, first made
available in 2003, was a rewrite of CVC that attempted to make CVC
more flexible (hence the "lite") while extending the feature set: CVC
Lite supported quantifiers where its predecessors did not. CVC3 was a
major overhaul of portions of CVC Lite: it added better decision
procedure implementations, added support for using MiniSat in the
core, and had generally better performance.

[[File:cvc4-logo.png|thumb|border|100px|The CVC4 logo.]]
CVC4 is the new version, the fifth generation of this validity checker
line that is now celebrating sixteen years of heritage. It represents
a complete re-evaluation of the core architecture to be both
performant and to serve as a cutting-edge research vehicle for the
next several years. Rather than taking CVC3 and redesigning problem
parts, we've taken a clean-room approach, starting from scratch.
Before using any designs from CVC3, we have thoroughly scrutinized,
vetted, and updated them. Many parts of CVC4 bear only a superficial
resemblance, if any, to their correspondent in CVC3.

However, CVC4 is fundamentally similar to CVC3 and many other modern
SMT solvers: it is a DPLL(T) solver, with a SAT solver at its core and
a delegation path to different decision procedure implementations,
each in charge of solving formulas in some background theory.

The re-evaluation and ground-up rewrite was necessitated, we felt, by
the performance characteristics of CVC3. CVC3 has many useful
features, but some core aspects of the design led to high memory use,
and the use of heavyweight computation (where more nimble engineering
approaches could suffice) makes CVC3 a much slower prover than other
tools. As these designs are central to CVC3, a new version was
preferable to a selective re-engineering, which would have ballooned
in short order.

User Registration

2017-06-07T20:44:26Z

Tinelli:

To register as a new user, please contact a member of the Stanford team, especially:

* [http://theory.stanford.edu/~barrett/ Clark Barrett]

CVC4's native language

2015-11-01T18:06:09Z

Tinelli: /* Global symbol definitions */

= CVC4 native input language =

The native input language consists of a sequence of symbol declarations and commands, each followed by a semicolon (<code>;</code>).

Any text after the first occurrence of a percent character and to the end of the current line is a comment:

%%% This is a native language comment

== Type System ==

CVC4's type system includes a set of built-in types which can be expanded with additional user-defined types.

The type system consists of ''first-order'' types, ''subtypes'' of first-order types, and ''higher-order'' types, all of which are interpreted as sets.
For convenience, we will sometimes identify below the interpretation of a type with the type itself.

First-order types consist of basic types and structured types. The basic types are <math>\mathrm{BOOLEAN}</math>, <math>\mathrm{REAL}</math>, <math>\mathrm{BITVECTOR}(n)</math> for all <math>n > 0</math>, as well as user-defined basic types (also called uninterpreted types).
The structured types are array, tuple, record types, and ML-style user-defined (inductive) datatypes.

'''Note:''' Currently, subtypes consist only of the built-in subtype <math>\mathrm{INT}</math> of <math>\mathrm{REAL}</math>.

Support for CVC3-style user-defined subtypes will be added in a later release.

Function types are the only higher-order types.
More precisely, they are just second-order types
since function symbols in CVC4, both built-in and user-defined, can take as argument or return only values of
a first-order type.

=== Basic Types ===

==== The BOOLEAN Type ====

The <math>\mathrm{BOOLEAN}</math> type is interpreted as the two-element set of Boolean values
<math>\{\mathrm{TRUE},\; \mathrm{FALSE}\}</math>.

'''Note:''' CVC4's treatment of this type differs from CVC3's where <math>\mathrm{BOOLEAN}</math> is used only as the type of formulas, but not as value type. CVC3 follows the two-tiered structure of classical first-order logic
which distinguishes between formulas and terms, and allows terms to occur in formulas but not vice versa (with the exception of the IF-THEN-ELSE construct).
CVC4 drops the distinction between terms and formulas and defines the latter just as terms of type <math>\mathrm{BOOLEAN}</math>. As such, formulas can occur as subterms of possibly non-Boolean terms.

Example:

% Boolean constants
a, b: BOOLEAN;

% REAL constants
x,y: REAL;

% Boolean-valued function, can be used as a predicate symbol
p: REAL -> BOOLEAN;
ASSERT a => p(x - y);

% Real-valued function with Boolean argument
f: BOOLEAN -> REAL;

% The argument of f can be a formula ...
ASSERT f(a OR b) > 0.3 OR p(x);

% ... even a quantified one
ASSERT y = f(FORALL (r: REAL): r < r + 1);

==== The REAL Type ====

The <math>\mathrm{REAL}</math> type is interpreted as the set of real numbers.

Note that these are the (infinite precision) mathematical reals,
not the floating point numbers.
Support for floating point types is planned for future versions.

x, y : REAL;
QUERY (( x <= y ) AND ( y <= x )) => ( x = y );

==== The INT Type ====

The <math>\mathrm{INT}</math> type is interpreted as the set of integer numbers
and is considered a subtype of <math>\mathrm{REAL}</math>.
The latter means in particular that it is possible to mix integer and real terms
in expressions without the need of an explicit ''upcasting'' operator.

Note that these are the (infinite precision) mathematical integers,
not the finite precision machine integers used in most programming languages.
The latter are modeled by [[ #Bitvectors | bit vector ]] types.

x, y : INT;
QUERY ((2 * x + 4 * y <= 1) AND ( y >= x)) => (x <= 0);
z : REAL;
QUERY (2 * x + z <= 3.5) AND (z >= 1);

==== Bit Vector Types ====

For every positive integer <math>n</math>, the type <math>\mathrm{BITVECTOR}(n)</math> is interpreted as the set of all bit vectors of size <math>n</math>.
A rich set of bit vector operators is supported.

==== User-defined Basic Types ====

Users can define new basic types
(often referred to as ''uninterpreted'' types in the SMT literature).
Each such type is interpreted as a set of unspecified cardinality
but disjoint from any other type.

User-defined basic types are created by declarations like the following:

% User declarations of basic types:

MyBrandNewType: TYPE;

Apples, Oranges: TYPE;

=== Structured Types ===

CVC4's structured types are divided into the following families.

==== Array Types ====

Array types are created by the mixfix type constructors <math>\mathrm{ARRAY}\ \_\ \mathrm{OF}\ \_</math>
whose arguments can be instantiated by any value type.

I : TYPE;

%% Array types:

% Arrays with indices from I and values from REAL
Array1: TYPE = ARRAY I OF REAL;

% Arrays with integer indices and array values
Array2: TYPE = ARRAY INT OF (ARRAY INT OF REAL);

% Arrays with integer pair indices and integer values
IntMatrix: TYPE = ARRAY [INT, INT] OF INT;

An array type of the form <math>\mathrm{ARRAY}\ T_1\ \mathrm{OF}\ T_2</math> is interpreted
as the set of all total maps from <math>T_1</math> to <math>T_2</math>.
The main difference with the function type <math>T_1 \to T_2</math> is that arrays,
contrary to functions, are first-class objects of the language, that is, values of an array
type can be arguments or results of functions.
Furthermore, array types come equipped with an update operation.

==== Tuple Types ====

Tuple types are created by the mixfix type constructors

<center>
<math>
\begin{array}{l} [\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ \ ,\ \_\ ] \\[1ex] \ldots \end{array}
</math>
</center>

whose arguments can be instantiated by any value type.

IntArray: TYPE = ARRAY INT OF INT;

% Tuple type declarations

EmptyTupleType: TYPE = []; % this is a unit type

RealPair: TYPE = [REAL, REAL];

MyTuple: TYPE = [ REAL, IntArray, [INT, INT] ];

A tuple type of the form <math>[T_1, \ldots, T_n]</math> is interpreted
as the Cartesian product <math>T_1 \times \cdots \times T_n</math>.

Note that while the types <math>(T_1, \ldots, T_n) \to T</math> and
<math>[T_1 \times \cdots \times T_n] \to T</math> are semantically equivalent,
they are operationally different in CVC4.
The first is the type of functions that take <math>n</math> arguments
of respective type <math>T_1</math>, <math>\ldots</math>, <math>T_n</math>,
while the second is the type of functions that take one argument of an <math>n</math>-tuple type.

==== Record Types ====

Similar to, but more general than tuple types, record types are created by type constructors of the form

<center>
<math>
[\#\ l_1: \_\ ,\ \ldots\ ,\ l_n: \_\ \#]
</math>
</center>

where <math>n \geq 0</math>, <math>l_1,\ldots, l_n</math> are field labels,
and the arguments can be instantiated with any first-order types.

MyType: TYPE;

% Record declaration

RecordType: TYPE = [# id: REAL, age: INT, info: MyType #];

The order of the fields in a record type is meaningful:
permuting the field names gives a different type.

Note that record types are non-recursive.
For instance, it is not possible to declare a record type called <code>Person</code> containing
a field of type <code>Person</code>.
Recursive types are provided in CVC4 by the more general inductive data types.
(As a matter of fact, both record and tuple types are implemented internally as inductive data types.)

==== Inductive Data Types ====

Inductive data types in CVC4 are similar to inductive data types of functional languages.
They can be parametric or not.

===== Non-Parametric Data Types =====

Non-parametric data types are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1 & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2 & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types, including any <math>A_i</math>.
Such declarations define the data types <math>A_1, \ldots, A_n</math>.
For each data type <math>A_i</math> they introduce:

* constructor symbols <math>cons</math> of type <math>(T_1, \ldots, T_k) \to \mathit{type\_name}_i</math>,
* selector symbols <math>\mathit{sel}_j</math> of type <math>\mathit{type\_name}_i \to T_j</math>, and
* tester symbols <math>\mathit{is\_cons}</math> of type <math>\mathit{type\_name}_i \to \mathrm{BOOLEAN}</math>.

Note that permitting more than one data type to be defined in the same declarations allows
the definition of mutually recursive types.

% simple enumeration type

% implicitly defined are the testers: is_red, is_yellow and is_blue
% (similarly for the other data types)

DATATYPE
PrimaryColor = red | yellow | blue
END;

% infinite set of pairwise distinct values ..., v(-1), v(0), v(1), ...

DATATYPE
Id = v (id: INT)
END;

% ML-style integer lists

DATATYPE
IntList = nil | ins (head: INT, tail: IntList)
END;

% AST for lamba calculus

DATATYPE
Term = var (index: INT)
| apply (arg_1: Term, arg_2: Term)
| lambda (arg: INT, body: Term)
END;

% Trees

DATATYPE
Tree = tree (value: REAL, children: TreeList),
TreeList = nil_tl
| ins_tl (first_t1: Tree, rest_t1: TreeList)
END;

Constructor, selector and tester symbols defined for a data type have global scope.
So, for example, it is not possible for two different data types to use
the same name for a constructor.

An inductive data type is interpreted as a term algebra constructed by the constructor symbols
over some sets of generators.
For example, the type <code>IntList</code> defined above is interpreted as the set
of all terms constructed with <code>nil</code> and <code>ins</code> over the integers.

===== Parametric Data Types =====

Parametric data types are infinite families of (non-parametric) data types
with each family parametrized by one or more type variables.
They are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1[X_{1,1}, \ldots, X_{1,p_1}] & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2[X_{2,1}, \ldots, X_{2,p_2}] & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n[X_{n,1}, \ldots, X_{n,p_n}] & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name parametrized by the type variables <math>X_{i,1}, \ldots, X_{i,p_i}</math>
and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types,
possibly parametrized by <math>X_1, \ldots, X_p</math>, including any <math>A_i</math>.

% Parametric pairs
DATATYPE
Pair[X, Y] = pair (first: X, second: Y)
END;

% Parametric lists

DATATYPE
List[X] = nil | cons (head: X, tail: List[X])
END;

% Parametric trees using the list type above

DATATYPE
Tree[X] = node (value: X, children: List[Tree[X]]),
END;

The declarations above define infinitely many types of the form
Pair[S,T], List[T] and Tree[T] where S and T are first-order types.
Note that the identifier <code>List</code> above, for example, by itself does not denote a type.
In contrast, the terms <code>List[Real]</code>, <code>List[List[Real]]</code>, <code>List[Tree[INT]]</code>,
and so on do.

===== Restriction to Inductive Types =====

By adopting a term algebra semantics, CVC4 allows only ''inductive'' data types,
that is, data types whose values are essentially (labeled, ordered) finite trees.
Infinite structures such as streams or even finite but cyclic ones
such as circular lists are then excluded.
For instance, none of the following declarations define inductive data types,
and are rejected by CVC4:

DATATYPE
IntStream = s (first:INT, rest: IntStream)
END;

DATATYPE
RationalTree = node1 (child: RationalTree)
| node2 (left_child: RationalTree, right_child:RationalTree)
END;

DATATYPE
T1 = c1 (s1: T2),
T2 = c2 (s2: T1)
END;

In concrete, a declaration of <math>n \geq 1</math> datatypes <math>T_1, \ldots, T_n</math> will be rejected if for any one of the types <math>T_1, \ldots, T_n</math>, it is impossible to build a finite term of that type using only the constructors of <math>T_1, \ldots, T_n</math> and free constants of type other than <math>T_1, \ldots, T_n</math>.

Inductive data types are the only types where the user also chooses names for the built-in operations to:

* construct a value of the type (with the constructors),
* extract components from a value (with the selectors), or
* check if a value was constructed with a certain constructor or not (with the testers).

For all the other types, CVC4 provides predefined names for the built-in operations on the type.

=== Function Types ===

Function (<math>\to</math>) types are created by the mixfix type constructors
<center>
<math>
\begin{array}{l}
\_ \to \_ \\[1ex] (\ \_\ ,\ \_\ ) \to \_
\\[1ex] (\ \_\ ,\ \_\ ,\ \_\ ) \to \_
\\[1ex] \ldots
\end{array}
</math>
</center>
whose arguments can be instantiated by any first-order type.

% Function type declarations

UnaryFunType: TYPE = INT -> REAL;

BinaryFunType: TYPE = (REAL, REAL) -> ARRAY REAL OF REAL;

TernaryFunType: TYPE = (REAL, BITVECTOR(4), INT) -> BOOLEAN;

A function type of the form <math>(T_1, \ldots, T_n) \to T</math> with <math>n > 0</math> is interpreted as the set of all ''total'' functions from the Cartesian product <math>T_1 \times \cdots \times T_n</math> to <math>T</math>.

The example above also shows how to introduce type names.
A name like <code>UnaryFunType</code> above is just an abbreviation for the type <math>\mathrm{INT} \to \mathrm{REAL}</math> and can be used interchangeably with it.

In general, any type defined by a type expression <code>E</code> can be given a name with the declaration:

name : TYPE = E;

=== Type Checking ===

In CVC4, formulas and terms are statically typed at the level of types
(as opposed to subtypes) according to the usual rules of first-order many-sorted logic,
with the main difference that formulas are just terms of type <math>BOOLEAN</math>:

* each variable has one associated first-order type,
* each constant symbol has one or more associated first-order types,
* each function symbol has one or more associated function types,
* the type of a term consisting just of a variable is the type associated to that variable,
* the type of a term consisting just of a constant symbol is the type associated to that constant symbol,
* the term obtained by applying a function symbol <math>f</math> to the terms <math>t_1, \ldots, t_n</math> is <math>T</math> if <math>f</math> has type <math>(T_1, \ldots, T_n) \to T</math> and each <math>t_i</math> has type <math>T_i</math>.

Attempting to enter an ill-typed term will result in an error.

Another significant difference with standard many-sorted logic is that
some built-in symbols are parametrically polymorphic.
For instance, the function symbol for extracting the element of any array has
type <math>(\mathit{ARRAY}\ T_1\ \mathit{OF}\ T_2,\; T_1) \to T_2</math>
for all first-order types <math>T_1, T_2</math>.

==== Type Ascription ====

By the type inference rules above some terms might have more than one type.
This can happen with terms built with polymorphic data type constructors
that have more than one return type for the same input type.
In that case, a type ascription operator (<code>::</code>) must be applied
to the constructor to specify the intended return type.

DATATYPE [X]
List[X] = nil | cons (head: X, tail: List[X])
END;

ASSERT y = cons(1, nil::List[REAL]);

DATATYPE [X, Y]
Union[X, Y] = left(val_l: X) | right(val_r: Y)
END;

ASSERT y = left::Union[BOOLEAN, REAL](TRUE);

The constant symbol <math>\mathrm{nil}</math> declared above has infinitely many types
(<math>\mathrm{List}[\mathrm{REAL}]</math>, <math>\mathrm{List}[\mathrm{BOOLEAN}]</math>,
<math>\mathrm{List}[[\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{List}[\mathrm{List}[\mathrm{REAL}]]</math>, ...)
CVC4's type checker requires the user to indicate explicitly the type
of each occurrence of <code>nil</code> in a term.
Similarly,
the injection operator <code>left</code> has infinitely many return types
for the same input type, for instance:
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{REAL}]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, [\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{List}[\mathrm{REAL}]]</math>,
and so on.
Applications of <code>left</code> need to specify the intended returned typed, as shown above.

== Terms and Formulas ==

In addition to type expressions, CVC4 has expressions for terms and for formulas
(i.e., terms of type <math>\mathrm{BOOLEAN}</math>).
By and large, these are standard first-order terms built out of typed variables,
predefined theory-specific operators, free (i.e., user-defined) function symbols,
and quantifiers.
Extensions include an if-then-else operator, lambda abstractions, and local symbol
declarations, as illustrated below.
Note that these extensions still keep CVC4's language first-order.
In particular, lambda abstractions are restricted to take and return only terms of
a first-order type.
Similarly, variables can only be of a first-order type.

A number of built-in function symbols (for instance, the arithmetic ones) are used
as infix operators. All user-defined symbols are used as prefix ones.

User-defined, i.e., free, function symbols include ''constant symbols'' and
''predicate symbols'', respectively nullary function symbols and function symbols
with a <math>\mathrm{BOOLEAN}</math> return type.
These symbols are introduced with global declarations of the form
<math> f_1, \ldots, f_m: T;</math>
where <math>m > 0</math>, <math>f_i</math> are the names of the symbols and
<math>T</math> is their type:

% integer constants

a, b, c: INT;

% real constants

x, y, z: REAL;

% unary function

f1: REAL -> REAL;

% binary function

f2: (REAL, INT) -> REAL;

% unary function with a tuple argument

f3: [INT, REAL] -> BOOLEAN;

% binary predicate

p: (INT, REAL) -> BOOLEAN;

% Propositional "variables"

P, Q: BOOLEAN;

Like type declarations, function symbol declarations like the above have global scope
and must be unique.
In other words, it is not possible to declare a function symbol globally more than once
in the same lexical scope.
This entails among other things that globally-defined free symbols cannot be overloaded
with different types and that theory symbols cannot be redeclared globally as free symbols.

=== Global symbol definitions ===

As with types, a function symbol can be defined as the name of another term
of the corresponding type.
With constant symbols, this is done with a declaration of the form <math>f:T = t;</math> :

c: INT;

i: INT = 5 + 3*c; % i is effectively a shorthand for 5 + 3*c

j: REAL = 3/4;

t: [REAL, INT] = (2/3, -4);

r: [# key: INT, value: REAL #] = (# key := 4, value := (c + 1)/2 #);

f: BOOLEAN = FORALL (x:INT): x <= 0 OR x > c ;

A restriction on constants of type <math>\mathit{BOOLEAN}</math> is that their value
can only be a closed formula, that is, a formula with no free variables.

A term and its name can be used interchangeably in later expressions.
Named terms are often useful for shared subterms (terms used several times in different places)
since their use can make the input exponentially more concise.
Named terms are processed very efficiently by CVC4.
It is much more efficient to associate a complex term with a name directly rather than
to declare a constant and later assert that it is equal to the same term.
This point is explained in more detail later in section [[#Commands | Commands]].

More generally, in CVC4 one can associate a term to function symbols of any arity.
For non-constant function symbols this is done with a declaration of the form

<center>
<math>f:(T_1, \ldots, T_n) \to T = \mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t\;;</math>
</center>

where <math>t</math> is any term of type <math>T</math> with free variables
in <math>\{x_1, \ldots, x_n\}</math>.
The lambda binder has the usual semantics and conforms to the usual lexical scoping rules:
within the term <math>t</math> the declaration of the symbols <math>x_1, \ldots, x_n</math>
as local variables of respective type <math>T_1, \ldots, T_n</math> hides any previous
declarations of those symbols that are in scope.

As a general shorthand, when <math>k</math> consecutive types
<math>T_i, \ldots, T_{i+k-1}</math> in the lambda expression
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t</math> are identical, the syntax
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x_i,\ldots, x_{i+k-1}:T_i,\ldots, x:T_n): t</math>
can also be used.

% Global declaration of x as a unary function symbol

x: REAL -> REAL;

% Local declarations of x as variable (hiding the global one)

f: REAL -> REAL = LAMBDA (x: REAL): 2*x + 3;

p: (INT, INT) -> BOOLEAN = LAMBDA (x,i: INT): i*x - 1 > 0;

g: (REAL, INT) -> [REAL, INT] = LAMBDA (x: REAL, i:INT): (x + 1, i - 3);

Note that lambda definitions are not recursive:
the symbol being defined cannot occur in the body of the lambda term.
They should be understood as macros.
For instance, any occurrence of the term <math>f(t)</math>
where <math>f</math> is as defined above will be treated
as if it was the term <math>(2*t + 3)</math>.

=== Local symbol definitions ===

Constant and function symbols can also be declared locally anywhere within a term
by means of a let binder.
This is done with a declaration of the form

<center>
<math>
\mathrm{LET}\ f = s \ \mathrm{IN}\ t ;
</math>
</center>

where <math>t</math> is a term with no free variables, possibly a lambda term.
Let binders can be nested arbitrarily and follow the usual lexical scoping rules.
The following general form
<center>
<math>
\mathrm{LET}\ f_1 = t_1, f_2 = t_2, \ldots, f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>
can used as a shorthand for
<center>
<math>
\mathrm{LET}\ f_1 = t_1\ \mathrm{IN}\
\mathrm{LET}\ f_2 = t_2\ \mathrm{IN}\
\ldots \
\mathrm{LET}\ f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>

t: REAL =
LET x1 = 42,
g = LAMBDA(x:INT): x + 1,
x2 = 2*x1 + 7/2
IN
(LET x3 = g(x1) IN x3 + x2) / x1;

Note that the same symbol = is used, unambiguously, in the syntax of global declarations,
let declarations, and as a predicate symbol.

'''Note:'''
A <math>\mathrm{LET}</math> term with a multiple symbols defines them sequentially.
A parallel version of the <math>\mathrm{LET}</math> construct will be introduced in a later version.

== Built-in theories and their symbols ==

In addition to user-defined symbols, CVC4 terms can use a number of predefined symbols:
the logical symbols, such as <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, etc.,
as well as theory symbols, function symbols belonging to one of the built-in theories.
They are described next, with the theory symbols grouped by theory.

=== Logical Symbols ===

The logical symbols in CVC4's language include
the equality and disequality predicate symbols, respectively written as = and /=,
the multiarity disequality symbol <math>\mathrm{DISTINCT}</math>,
together with the logical constants <math>\mathrm{TRUE}</math>, <math>\mathrm{FALSE}</math>,
the connectives <math>\mathrm{NOT}</math>, <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, <math>\mathrm{XOR}</math>, <math>\Rightarrow</math>, <math>\Leftrightarrow</math>, and
the first-order quantifiers <math>\mathrm{EXISTS}</math> and <math>\mathrm{FORALL}</math>,
all with the standard many-sorted logic semantics.

The binary connectives have infix syntax and type
<math>(\mathrm{BOOLEAN},\mathrm{BOOLEAN}) \to \mathrm{BOOLEAN}</math>.
The symbols = and /=, which are also infix, are instead parametrically polymorphic,
having type <math>(T,T) \to \mathrm{BOOLEAN}</math>
for every first-order type <math>T</math>.
They are interpreted respectively as the identity relation and its complement.

The DISTINCT symbol is both overloaded and polymorphic.
It has type <math>(T,...,T) \to \mathrm{BOOLEAN}</math>
for every sequence <math>(T,...,T)</math> of length <math>n > 0</math>
and first-order type <math>T</math>.
For each <math>n > 0</math>, it is interpreted as the relation
that holds exactly for tuples of pairwise distinct elements.

The syntax for quantifiers is similar to that of the lambda binder.

Here is an example of a formula built just of these logical symbols and variables:

A, B: TYPE;

q: BOOLEAN = FORALL (x,y: A, i,j,k: B):
i = j AND i /= k => EXISTS (z: A): x /= z OR z /= y;

Binding and scoping of quantified variables follows the same rules as
in let expressions.
In particular, a quantifier will shadow in its scope any constant and function symbols
with the same name as one of the variables it quantifies:

A: TYPE;
i, j: INT;

% The first occurrence of i and of j in f are constant symbols,
% the others are variables.

f: BOOLEAN = i = j AND FORALL (i,j: A): i = j OR i /= j;

Optionally, it is also possible to specify instantiation patterns
for quantified variables.
The general syntax for a quantified formula <math>\psi</math> with patterns is

<center>
<math>
Q\;(x_1:T_1, \ldots, x_k:T_k):\; p_1: \ldots\; p_n:\; \varphi
</math>
</center>

where <math>n \geq 0</math>, <math>Q</math> is
either <math>\mathrm{FORALL}</math> or <math>\mathrm{EXISTS}</math>,
<math>\varphi</math> is a term of type <math>\mathrm{BOOLEAN}</math>,
and each of the <math>p_i</math>'s,
a pattern for the quantifier <math>Q\;(x_1:T_1, \ldots, x_k:T_k)</math>, has the form

<center>
<math>
\mathrm{PATTERN}\; (t_1, \ldots, t_m)
</math>
</center>

where <math>m > 0</math> and <math>t_1, \ldots, t_m</math> are
arbitrary binder-free terms (no lets, no quantifiers).
Those terms can contain (free) variables, typically, but not exclusively,
drawn from <math>x_1, \ldots, x_k</math>.
(Additional variables can occur if <math>\psi</math> occurs in a bigger formula
binding those variables.)

A: TYPE;
b, c: A;
p, q: A -> BOOLEAN;
r: (A, A) -> BOOLEAN;

ASSERT FORALL (x0, x1, x2: A):
PATTERN (r(x0, x1), r(x1, x2)):
(r(x0, x1) AND r(x1, x2)) => r(x0, x2) ;

ASSERT FORALL (x: A):
PATTERN (r(x, b)):
PATTERN (r(x, c)):
p(x) => q(x) ;

ASSERT EXISTS (y: A):
FORALL (x: A):
PATTERN (r(x, y), p(y)):
r(x, y) => q(x) ;

Patterns have no logical meaning:
adding them to a formula does not change its semantics.
Their purpose is purely operational, as explained in
the [[#Instantiation Patterns | Instantiation Patterns]] section.

In addition to these constructs, CVC4 also has a general mixfix conditional operator
of the form

<center>
<math>
\mathrm{IF}\ b\ \mathrm{THEN}\ t\ \mathrm{ELSIF}\ b_1\ \mathrm{THEN}\ t_1\ \ldots\ \mathrm{ELSIF}\ b_n\ \mathrm{THEN}\ t_n\ \mathrm{ELSE}\ t_{n+1}\ \mathrm{ENDIF}
</math>
</center>

with <math>n \geq 0</math> where
<math>b, b_1, \ldots, b_n</math> are terms of type <math>\mathrm{BOOLEAN}</math> and
<math>t, t_1, \ldots, t_n, t_{n+1}</math> are terms of the same first-order type <math>T</math>:

% Conditional term
x, y, z, w: REAL;

t: REAL =
IF x > 0 THEN y
ELSIF x >= 1 THEN z
ELSIF x > 2 THEN w
ELSE 2/3 ENDIF;

=== User-defined Functions and Types ===

The theory of user-defined functions,also know in the SMT literature as
the theory ''Equality over Uninterpreted Functions'', or ''EUF'', is in effect
a family of theories of equality parametrized by the basic types and the free symbols
a user can define during a run of CVC4.

This theory has no built-in symbols (other than the logical ones).
Its types consist of ''all and only'' the user-defined types.
Its function symbols consist of ''all and only'' the user-defined free symbols.

=== Arithmetic ===

The real arithmetic theory has two types:
<math>\mathrm{REAL}</math> and <math>\mathrm{INTEGER}</math>
with the latter a subtype of the first.
Its built-in symbols for the usual arithmetic constants
and operators over the type <math>\mathrm{REAL}</math>, each with the expected type:
all numerals 0, 1, ..., as well as - (both unary and binary), +, *, /, <, >, <=, >=.
Application of the binary symbols are in infix form.
Note that + is only binary, and so an expression such as +4 is ill-formed.

Rational values can be expressed in decimal or fractional format,
e.g., 0.1, 23.243241, 1/2, 3/4, and so on.
A leading 0 is mandatory for decimal numbers smaller than one
(e.g., the syntax .3 cannot be used as a shorthand for 0.3).
However, a trailing 0 is ''not'' required for decimals that are whole numbers
(e.g., 3. is allowed as a shorthand for 3.0).
The size of the numerals used in the representation of natural and rational numbers
is unbounded; more accurately, bounded only by the amount of available memory.

=== Bit vectors ===

=== Arrays ===

The theory of arrays is a parametric theory of (total) unary maps.
It comes equipped with mixfix polymorphic selection and update operators, respectively
<center>
<math>\_[\_]</math> and <math>\_\ \mathrm{WITH}\ [\_]\ := \_</math> .
</center>
The semantics of these operators is the expected one:
for all first-order types <math>T_1</math> and <math>T_2</math>,
if <math>a</math> is of type <math>\mathrm{ARRAY}\ T_1 \mathrm{OF}\ T_2</math>,
<math>i</math> is of type <math>T_1</math>, and
<math>v</math> is of type <math>T_2</math>,
* <math>a[i]</math> denotes the value that <math>a</math> associates to index <math>i</math>,
* <math>a\ \mathrm{WITH}\ [i]\ := v</math> denotes a map that associates <math>v</math> to index <math>i</math> and is otherwise identical to <math>a</math>.
Sequential updates can be chained with the shorthand syntax
<math>\_\ \mathrm{WITH}\ [\_]\ := \_, \ldots, [\_]\ := \_</math>.

A: TYPE = ARRAY INT OF REAL;
a: A;
i: INT = 4;

% selection:

elem: REAL = a[i];

% update

a1: A = a WITH [10] := 1/2;

% sequential update
% (syntactic sugar for (a WITH [10] := 2/3) WITH [42] := 3/2)

a2: A = a WITH [10] := 2/3, [42] := 3/2;

Since arrays are just maps, equality between them is extensional, that is,
for two arrays of the same type to be different they have to map at least one
index to differ values.

=== Data types ===

The theory of inductive data types is in fact a family of theories parametrized
by a data type declaration specifying constructors and selectors
for one or more user-defined data types.

No built-in operators other than equality and disequality are provided
for this family in the native language.
Each user-provided data type declaration, however, generates constructor, selector and tester operators
as described in the [[#Inductive Data Types | Inductive Data Types]] section.

=== Tuples and Records ===

Semantically both records and tuples can be seen as special instances
of inductive data types.
CVC4 implements them internally indeed as data types.
In essence, a record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math>
is encoded as a data type of the form

<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\ \ \mathrm{Record} = \mathit{rec}(l_0:T_0, \ldots, l_n:T_n) \\
\mathrm{END};
\end{array}
</math>
</center>

Tuples of length <math>n</math> are in turn special cases of records whose field names are
the numerals from <math>0</math> to <math>n-1</math>.

Externally, tuples and records have their own syntax for constructor and selector operators.
* Records of type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> have the associated record constructor <math>(\#\ l_0 := \_,\; \ldots,\; l_n := \_\ \#)</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.
* Tuples of type <math>[\ T_0, \ldots, T_n\ ]</math> have the associated tuple constructor <math>(\ \_,\; \ldots,\; \_\ )</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively. Note that the empty tuple can be created with <math>(\ )</math>; however, a single-element tuple cannot be directly created, as <math>(\ \_\ )</math> is interpreted as a parenthesized (non-tuple) expression.

The selector operators on records and tuples follows a dot notation syntax.

% Record construction and field selection
Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);
k: INT = x.key;
v: REAL = x.weight;

% Tuple construction and projection
y: [REAL, INT, REAL] = ( 4/5, 9, 11/9 );
first_elem: REAL = y.0;
third_elem: REAL = y.2;

Differently from data types, records and tuples are also provided with built-in update operators similar in syntax and semantics to the update operator for arrays.
More precisely, for each record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .l_i\ := \_
</math>
</center>

The operator maps a record <math>r</math> of that type and a value <math>v</math>
of type <math>T_i</math> to the record that stores <math>v</math> in field <math>l_i</math>
and is otherwise identical to <math>r</math>.
Analogously, for each tuple type <math>[T_0, \ldots, T_n]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .i\ := \_
</math>
</center>

with similar semantics.

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = x WITH .weight := 48;

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = y WITH .1 := 3;

Updates to a nested component can be combined in a single WITH operator:

Cache: TYPE = ARRAY [0..100] OF [# addr: INT, data: REAL #];
State: TYPE = [# pc: INT, cache: Cache #];

s0: State;
s1: State = s0 WITH .cache[10].data := 2/3;

Note that, differently from updates on arrays, tuple and record updates are
just additional syntactic sugar.
For instance, the record <code>x1</code> and tuple <code>y1</code> defined above
could have been equivalently defined as follows:

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = (# key := x.key, weight := 48 #);

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = ( y.0, 3, y.1 );

== Commands ==

In addition to declarations of types and function symbols,
the CVC4 native language contains the following commands:

* <math>\mathrm{ASSERT}\ F</math> -- Add the formula <math>F</math> to the current logical context <math>\Gamma</math>.
* [[#CHECKSAT|<math>\mathrm{CHECKSAT}\ F</math>]] -- Check if the formula <math>F</math> is satisfiable in the current logical context (<math>\Gamma \not\models_T \mathrm{NOT}\ F</math>).
* <math>\mathrm{CONTINUE}</math> -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, search for a counter-example different from the current one.
* [[#COUNTEREXAMPLE|<math>\mathrm{COUNTEREXAMPLE}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print the context that is a witness for invalidity/satisfiability.
* [[#COUNTERMODEL|<math>\mathrm{COUNTERMODEL}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print a model that makes the formula invalid/satisfiable. The model is provided in terms of concrete values for each free symbol.
* <math>\mathrm{OPTION}\ o\ v</math> -- Set the command-line option flag <math>o</math> to value <math>v</math>. The argument <math>o</math> is provide as a string literal enclosed in double-quotes and <math>v</math> as an integer value.
* <math>\mathrm{POP}</math> -- Equivalent to <math>\mathrm{POPTO}\ 1</math>
* [[#PUSH and POPTO|<math>\mathrm{POPTO}\ n</math>]] -- Restore the system to the state it was in right before the most recent call to <math>\mathrm{PUSH}</math> made from assertion (stack) level <math>n</math>. Note that the current assertion level is printed as part of the output of the <math>\mathrm{WHERE}</math> command.
* [[#PUSH and POPTO|<math>\mathrm{PUSH}</math>]] -- Save (checkpoint) the current state of the system.
* [[#QUERY|<math>\mathrm{QUERY}\ F</math>]] -- Check if the formula <math>F</math> is valid in the current logical context (<math>\Gamma\models_T F</math>).
* [[#RESTART|<math>\mathrm{RESTART}\ F</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, repeat the check but with the additional assumption <math>F</math> in the context.
* <math>\mathrm{PRINT}\ t</math> -- Parse and print back the term <math>t</math>.
* <math>\mathrm{TRANSFORM}\ t</math> -- Simplify the term <math>t</math> and print the result.
* <math>\mathrm{WHERE}</math> -- Print all the formulas in the current logical context <math>\Gamma</math>.

The remaining commands take a single argument, given as a string literal enclosed in double-quotes.

* <math>\mathrm{ECHO}\ s</math> -- Print string <math>s</math>
* <math>\mathrm{INCLUDE}\ f</math> -- Read commands from file <math>f</math>.
* <math>\mathrm{TRACE}\ f</math> -- Turn on tracing for the debug flag <math>f</math>.
* <math>\mathrm{UNTRACE}\ f</math> -- Turn off tracing for the debug flag <math>f</math>.

Here, we explain some of the above commands in more detail.

=== QUERY ===

The command <math>\mathrm{QUERY}\ F</math> invokes the core functionality of CVC4 to check
the validity of the formula <math>F</math> with respect to the assertions made thus far,
which constitute the context <math>\Gamma</math>.
The argument <math>F</math> must be well typed term of type <math>\mathrm{BOOLEAN}</math>,
as described in [[#Terms and Formulas | Terms and Formulas]].

The execution of this command always terminates and produces one of three possible answers:
<code>valid</code>, <code>invalid</code>, and <code>unknown</code>.

* A <code>valid</code> answer indicates that <math>\Gamma \models_T F</math>. After a query returning such an answer, the logical context <math>\Gamma</math> is exactly as it was before the query.
* An <code>invalid</code> answer indicates that <math>\Gamma \not\models_T F</math>, that is, there is a model of the background theory <math>T</math> that satisfies <math>\Gamma \cup \{\mathrm{NOT}\ F\}</math>. When <math>\mathrm{QUERY}\ F</math> returns <code>invalid</code>, the logical context <math>\Gamma</math> is augmented with a set <math>\Delta</math> of ground (i.e., variable-free) literals such that <math>\Gamma\cup\Delta</math> is satisfiable in <math>T</math>, but <math>\Gamma\cup\Delta\models_T \mathrm{NOT}\ F</math>. In fact, in this case <math>\Delta</math> ''propositionally entails'' <math>\mathrm{NOT}\ F</math>, in the sense that, every truth assignment to the literals of <math>\Delta</math> that satisfies <math>\Delta</math> falsifies <math>F</math>. We call the new context <math>\Gamma\cup\Delta</math> a ''counterexample'' for <math>F</math>.
* An <code>unknown</code> answer is similar to an <code>invalid</code> answer in that additional literals are added to the context which propositionally entail <math>\mathrm{NOT}\ F</math>. The difference in this case is that CVC4 cannot guarantee that <math>\Gamma\cup\Delta</math> is actually satisfiable in <math>T</math>.

CVC4 may report <code>unknown</code> when the context or the query contains
non-linear arithmetic terms or quantifiers.
In all other cases, it is expected to be sound and complete,
i.e., to report <code>Valid</code> if <math>\Gamma \models_T F</math>
and <code>Invalid</code> otherwise.

After an <code>invalid</code> (resp. <code>unknown</code>) answer,
counterexamples (resp. possible counterexamples) can be obtained with
a <math>\mathrm{WHERE}</math>, <math>\mathrm{COUNTEREXAMPLE}</math>,
or <math>\mathrm{COUNTERMODEL}</math> command.


Since the <math>\mathrm{QUERY}</math> command may modify
the current context, if one needs to check several formulas in a row
in the same context, it is a good idea to surround every
query by a <math>\mathrm{PUSH}</math> and <math>\mathrm{POP}</math> invocation
in order to preserve the context:

PUSH;
QUERY <formula>;
POP;

=== CHECKSAT ===

The command <math>\mathrm{CHECKSAT}\ F</math> behaves identically
to <math>\mathrm{QUERY}\ \mathrm{NOT}\ F</math>.

=== RESTART ===

The command <math>\mathrm{RESTART}\ F</math> can only be invoked after an invalid query.
For example, in an interactive setting:

QUERY <formula>;

CVC4> invalid

RESTART <formula2>;

Functionally, the behavior of the above command sequence is identical to the following:

PUSH;
QUERY <formula>;
POP;
ASSERT <formula2>;
QUERY <formula>;

The advantage of using the <math>\mathrm{RESTART}</math> command is that
the first command sequence may be executed much more efficiently that the second.
The reason is that with <math>\mathrm{RESTART}</math> CVC4 will re-use
what it has learned while answering the previous query rather than starting
over from scratch.

=== COUNTERMODEL ===

[More]

=== COUNTEREXAMPLE ===

[More]

=== PUSH and POPTO ===

CVC4's context can be understood as being stratified in ''assertion levels''
which are added and removed in a LIFO fashion.
The system starts at assertion level 0 and every execution of the PUSH command creates a new assertion level after the current one.
Each formula added to the context either by the user, via an ASSERT command, or internally by the system
is added to the most recent assertion level.
Executing POPTO n removes from the context the most recent n assertion levels and all the formulas in them.
So, for instance, POP 1 has the effect of retracting all formulas in the current assertion level (and removing that level).
Note that formulas at assertion level 0 cannot be retracted.

Note: Symbol declarations are always added at assertion level zero. So they are not affected by POPTO commands.

== Instantiation Patterns ==

CVC4 processes each universally quantified formula in the current context
by adding instances of the formula obtained by replacing its universal variables
with ground terms.
Patterns restrict the choice of ground terms for the quantified variables,
with the goal of controlling the potential explosion of ground instances.
In essence, adding patterns to a formula is a way for the user to tell CVC4
to focus only on certain instances which, in the user's opinion, will be
most helpful during a proof.

In more detail, patterns have the following effect on formulas that are found
in the logical context or get added to it later while CVC4 is trying to prove
the validity of some formula <math>F</math>.

If a formula in the current context starts with an existential quantifier,
CVC4 ''Skolemizes'' it, that is, replaces it in the context with the formula
obtained by substituting the existentially quantified variables
by fresh constants and dropping the quantifier.
Any patterns for the existential quantifier are simply ignored.

If a formula starts with a universal quantifier
<math>\mathrm{FORALL}\; (x_1:T_1, \ldots, x_n:T_n)</math>,
CVC4 adds to the context a number of instances of the formula,
with the goal of using them to prove the query <math>F</math> valid.
An instance is obtained by replacing each <math>x_i</math> with a ground term
of the same type occurring in one of the formulas in the context,
and dropping the universal quantifier.
If <math>x_i</math> occurs in a pattern
<math>\mathrm{PATTERN}\; (t_1, \ldots, t_m)</math> for the quantifier,
it will be instantiated only with terms obtained by simultaneously matching
all the terms in the pattern against ground terms in the current context
<math>\Gamma</math>.

Specifically, the matching process produces one or more substitutions
<math>\sigma</math> for the variables in <math>(t_1, \ldots, t_m)</math>
which satisfy the following invariant:
for each <math>i = 1, \ldots, m</math>, <math>\sigma(t_i)</math> is
a ground term and there is a ground term <math>s_i</math> in <math>\Gamma</math>
such that <math>\Gamma \models_T \sigma(t_i) = s_i</math>.
The variables of <math>(x_1:T_1, \ldots, x_n:T_n)</math> that occur
in the pattern are instantiated only with those substitutions
(while any remaining variables are instantiated arbitrarily).

The Skolemized version or the added instances of a context formula may themselves
start with a quantifier.
The same instantiation process is applied to them too, recursively.

Note that the matching mechanism is not limited to syntactic matching
but is modulo the equations asserted in the context.
Because of decidability and/or efficiency limitations, the matching process
is not exhaustive.
CVC4 will typically miss some substitutions that satisfy the invariant above.
As a consequence, it might fail to prove the validity of the query formula
<math>F</math>, which makes CVC4 incomplete for contexts containing
quantified formulas.
It should be noted though that exhaustive matching, which can be achieved
simply by not specifying any patterns, does not yield completeness anyway
since the instantiation of universal variables is still restricted
to just the ground terms in the context,
whereas in general additional ground terms might be needed.

CVC4's native language

2015-11-01T17:55:13Z

Tinelli: /* Terms and Formulas */

= CVC4 native input language =

The native input language consists of a sequence of symbol declarations and commands, each followed by a semicolon (<code>;</code>).

Any text after the first occurrence of a percent character and to the end of the current line is a comment:

%%% This is a native language comment

== Type System ==

CVC4's type system includes a set of built-in types which can be expanded with additional user-defined types.

The type system consists of ''first-order'' types, ''subtypes'' of first-order types, and ''higher-order'' types, all of which are interpreted as sets.
For convenience, we will sometimes identify below the interpretation of a type with the type itself.

First-order types consist of basic types and structured types. The basic types are <math>\mathrm{BOOLEAN}</math>, <math>\mathrm{REAL}</math>, <math>\mathrm{BITVECTOR}(n)</math> for all <math>n > 0</math>, as well as user-defined basic types (also called uninterpreted types).
The structured types are array, tuple, record types, and ML-style user-defined (inductive) datatypes.

'''Note:''' Currently, subtypes consist only of the built-in subtype <math>\mathrm{INT}</math> of <math>\mathrm{REAL}</math>.

Support for CVC3-style user-defined subtypes will be added in a later release.

Function types are the only higher-order types.
More precisely, they are just second-order types
since function symbols in CVC4, both built-in and user-defined, can take as argument or return only values of
a first-order type.

=== Basic Types ===

==== The BOOLEAN Type ====

The <math>\mathrm{BOOLEAN}</math> type is interpreted as the two-element set of Boolean values
<math>\{\mathrm{TRUE},\; \mathrm{FALSE}\}</math>.

'''Note:''' CVC4's treatment of this type differs from CVC3's where <math>\mathrm{BOOLEAN}</math> is used only as the type of formulas, but not as value type. CVC3 follows the two-tiered structure of classical first-order logic
which distinguishes between formulas and terms, and allows terms to occur in formulas but not vice versa (with the exception of the IF-THEN-ELSE construct).
CVC4 drops the distinction between terms and formulas and defines the latter just as terms of type <math>\mathrm{BOOLEAN}</math>. As such, formulas can occur as subterms of possibly non-Boolean terms.

Example:

% Boolean constants
a, b: BOOLEAN;

% REAL constants
x,y: REAL;

% Boolean-valued function, can be used as a predicate symbol
p: REAL -> BOOLEAN;
ASSERT a => p(x - y);

% Real-valued function with Boolean argument
f: BOOLEAN -> REAL;

% The argument of f can be a formula ...
ASSERT f(a OR b) > 0.3 OR p(x);

% ... even a quantified one
ASSERT y = f(FORALL (r: REAL): r < r + 1);

==== The REAL Type ====

The <math>\mathrm{REAL}</math> type is interpreted as the set of real numbers.

Note that these are the (infinite precision) mathematical reals,
not the floating point numbers.
Support for floating point types is planned for future versions.

x, y : REAL;
QUERY (( x <= y ) AND ( y <= x )) => ( x = y );

==== The INT Type ====

The <math>\mathrm{INT}</math> type is interpreted as the set of integer numbers
and is considered a subtype of <math>\mathrm{REAL}</math>.
The latter means in particular that it is possible to mix integer and real terms
in expressions without the need of an explicit ''upcasting'' operator.

Note that these are the (infinite precision) mathematical integers,
not the finite precision machine integers used in most programming languages.
The latter are modeled by [[ #Bitvectors | bit vector ]] types.

x, y : INT;
QUERY ((2 * x + 4 * y <= 1) AND ( y >= x)) => (x <= 0);
z : REAL;
QUERY (2 * x + z <= 3.5) AND (z >= 1);

==== Bit Vector Types ====

For every positive integer <math>n</math>, the type <math>\mathrm{BITVECTOR}(n)</math> is interpreted as the set of all bit vectors of size <math>n</math>.
A rich set of bit vector operators is supported.

==== User-defined Basic Types ====

Users can define new basic types
(often referred to as ''uninterpreted'' types in the SMT literature).
Each such type is interpreted as a set of unspecified cardinality
but disjoint from any other type.

User-defined basic types are created by declarations like the following:

% User declarations of basic types:

MyBrandNewType: TYPE;

Apples, Oranges: TYPE;

=== Structured Types ===

CVC4's structured types are divided into the following families.

==== Array Types ====

Array types are created by the mixfix type constructors <math>\mathrm{ARRAY}\ \_\ \mathrm{OF}\ \_</math>
whose arguments can be instantiated by any value type.

I : TYPE;

%% Array types:

% Arrays with indices from I and values from REAL
Array1: TYPE = ARRAY I OF REAL;

% Arrays with integer indices and array values
Array2: TYPE = ARRAY INT OF (ARRAY INT OF REAL);

% Arrays with integer pair indices and integer values
IntMatrix: TYPE = ARRAY [INT, INT] OF INT;

An array type of the form <math>\mathrm{ARRAY}\ T_1\ \mathrm{OF}\ T_2</math> is interpreted
as the set of all total maps from <math>T_1</math> to <math>T_2</math>.
The main difference with the function type <math>T_1 \to T_2</math> is that arrays,
contrary to functions, are first-class objects of the language, that is, values of an array
type can be arguments or results of functions.
Furthermore, array types come equipped with an update operation.

==== Tuple Types ====

Tuple types are created by the mixfix type constructors

<center>
<math>
\begin{array}{l} [\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ \ ,\ \_\ ] \\[1ex] \ldots \end{array}
</math>
</center>

whose arguments can be instantiated by any value type.

IntArray: TYPE = ARRAY INT OF INT;

% Tuple type declarations

EmptyTupleType: TYPE = []; % this is a unit type

RealPair: TYPE = [REAL, REAL];

MyTuple: TYPE = [ REAL, IntArray, [INT, INT] ];

A tuple type of the form <math>[T_1, \ldots, T_n]</math> is interpreted
as the Cartesian product <math>T_1 \times \cdots \times T_n</math>.

Note that while the types <math>(T_1, \ldots, T_n) \to T</math> and
<math>[T_1 \times \cdots \times T_n] \to T</math> are semantically equivalent,
they are operationally different in CVC4.
The first is the type of functions that take <math>n</math> arguments
of respective type <math>T_1</math>, <math>\ldots</math>, <math>T_n</math>,
while the second is the type of functions that take one argument of an <math>n</math>-tuple type.

==== Record Types ====

Similar to, but more general than tuple types, record types are created by type constructors of the form

<center>
<math>
[\#\ l_1: \_\ ,\ \ldots\ ,\ l_n: \_\ \#]
</math>
</center>

where <math>n \geq 0</math>, <math>l_1,\ldots, l_n</math> are field labels,
and the arguments can be instantiated with any first-order types.

MyType: TYPE;

% Record declaration

RecordType: TYPE = [# id: REAL, age: INT, info: MyType #];

The order of the fields in a record type is meaningful:
permuting the field names gives a different type.

Note that record types are non-recursive.
For instance, it is not possible to declare a record type called <code>Person</code> containing
a field of type <code>Person</code>.
Recursive types are provided in CVC4 by the more general inductive data types.
(As a matter of fact, both record and tuple types are implemented internally as inductive data types.)

==== Inductive Data Types ====

Inductive data types in CVC4 are similar to inductive data types of functional languages.
They can be parametric or not.

===== Non-Parametric Data Types =====

Non-parametric data types are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1 & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2 & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types, including any <math>A_i</math>.
Such declarations define the data types <math>A_1, \ldots, A_n</math>.
For each data type <math>A_i</math> they introduce:

* constructor symbols <math>cons</math> of type <math>(T_1, \ldots, T_k) \to \mathit{type\_name}_i</math>,
* selector symbols <math>\mathit{sel}_j</math> of type <math>\mathit{type\_name}_i \to T_j</math>, and
* tester symbols <math>\mathit{is\_cons}</math> of type <math>\mathit{type\_name}_i \to \mathrm{BOOLEAN}</math>.

Note that permitting more than one data type to be defined in the same declarations allows
the definition of mutually recursive types.

% simple enumeration type

% implicitly defined are the testers: is_red, is_yellow and is_blue
% (similarly for the other data types)

DATATYPE
PrimaryColor = red | yellow | blue
END;

% infinite set of pairwise distinct values ..., v(-1), v(0), v(1), ...

DATATYPE
Id = v (id: INT)
END;

% ML-style integer lists

DATATYPE
IntList = nil | ins (head: INT, tail: IntList)
END;

% AST for lamba calculus

DATATYPE
Term = var (index: INT)
| apply (arg_1: Term, arg_2: Term)
| lambda (arg: INT, body: Term)
END;

% Trees

DATATYPE
Tree = tree (value: REAL, children: TreeList),
TreeList = nil_tl
| ins_tl (first_t1: Tree, rest_t1: TreeList)
END;

Constructor, selector and tester symbols defined for a data type have global scope.
So, for example, it is not possible for two different data types to use
the same name for a constructor.

An inductive data type is interpreted as a term algebra constructed by the constructor symbols
over some sets of generators.
For example, the type <code>IntList</code> defined above is interpreted as the set
of all terms constructed with <code>nil</code> and <code>ins</code> over the integers.

===== Parametric Data Types =====

Parametric data types are infinite families of (non-parametric) data types
with each family parametrized by one or more type variables.
They are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1[X_{1,1}, \ldots, X_{1,p_1}] & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2[X_{2,1}, \ldots, X_{2,p_2}] & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n[X_{n,1}, \ldots, X_{n,p_n}] & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name parametrized by the type variables <math>X_{i,1}, \ldots, X_{i,p_i}</math>
and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types,
possibly parametrized by <math>X_1, \ldots, X_p</math>, including any <math>A_i</math>.

% Parametric pairs
DATATYPE
Pair[X, Y] = pair (first: X, second: Y)
END;

% Parametric lists

DATATYPE
List[X] = nil | cons (head: X, tail: List[X])
END;

% Parametric trees using the list type above

DATATYPE
Tree[X] = node (value: X, children: List[Tree[X]]),
END;

The declarations above define infinitely many types of the form
Pair[S,T], List[T] and Tree[T] where S and T are first-order types.
Note that the identifier <code>List</code> above, for example, by itself does not denote a type.
In contrast, the terms <code>List[Real]</code>, <code>List[List[Real]]</code>, <code>List[Tree[INT]]</code>,
and so on do.

===== Restriction to Inductive Types =====

By adopting a term algebra semantics, CVC4 allows only ''inductive'' data types,
that is, data types whose values are essentially (labeled, ordered) finite trees.
Infinite structures such as streams or even finite but cyclic ones
such as circular lists are then excluded.
For instance, none of the following declarations define inductive data types,
and are rejected by CVC4:

DATATYPE
IntStream = s (first:INT, rest: IntStream)
END;

DATATYPE
RationalTree = node1 (child: RationalTree)
| node2 (left_child: RationalTree, right_child:RationalTree)
END;

DATATYPE
T1 = c1 (s1: T2),
T2 = c2 (s2: T1)
END;

In concrete, a declaration of <math>n \geq 1</math> datatypes <math>T_1, \ldots, T_n</math> will be rejected if for any one of the types <math>T_1, \ldots, T_n</math>, it is impossible to build a finite term of that type using only the constructors of <math>T_1, \ldots, T_n</math> and free constants of type other than <math>T_1, \ldots, T_n</math>.

Inductive data types are the only types where the user also chooses names for the built-in operations to:

* construct a value of the type (with the constructors),
* extract components from a value (with the selectors), or
* check if a value was constructed with a certain constructor or not (with the testers).

For all the other types, CVC4 provides predefined names for the built-in operations on the type.

=== Function Types ===

Function (<math>\to</math>) types are created by the mixfix type constructors
<center>
<math>
\begin{array}{l}
\_ \to \_ \\[1ex] (\ \_\ ,\ \_\ ) \to \_
\\[1ex] (\ \_\ ,\ \_\ ,\ \_\ ) \to \_
\\[1ex] \ldots
\end{array}
</math>
</center>
whose arguments can be instantiated by any first-order type.

% Function type declarations

UnaryFunType: TYPE = INT -> REAL;

BinaryFunType: TYPE = (REAL, REAL) -> ARRAY REAL OF REAL;

TernaryFunType: TYPE = (REAL, BITVECTOR(4), INT) -> BOOLEAN;

A function type of the form <math>(T_1, \ldots, T_n) \to T</math> with <math>n > 0</math> is interpreted as the set of all ''total'' functions from the Cartesian product <math>T_1 \times \cdots \times T_n</math> to <math>T</math>.

The example above also shows how to introduce type names.
A name like <code>UnaryFunType</code> above is just an abbreviation for the type <math>\mathrm{INT} \to \mathrm{REAL}</math> and can be used interchangeably with it.

In general, any type defined by a type expression <code>E</code> can be given a name with the declaration:

name : TYPE = E;

=== Type Checking ===

In CVC4, formulas and terms are statically typed at the level of types
(as opposed to subtypes) according to the usual rules of first-order many-sorted logic,
with the main difference that formulas are just terms of type <math>BOOLEAN</math>:

* each variable has one associated first-order type,
* each constant symbol has one or more associated first-order types,
* each function symbol has one or more associated function types,
* the type of a term consisting just of a variable is the type associated to that variable,
* the type of a term consisting just of a constant symbol is the type associated to that constant symbol,
* the term obtained by applying a function symbol <math>f</math> to the terms <math>t_1, \ldots, t_n</math> is <math>T</math> if <math>f</math> has type <math>(T_1, \ldots, T_n) \to T</math> and each <math>t_i</math> has type <math>T_i</math>.

Attempting to enter an ill-typed term will result in an error.

Another significant difference with standard many-sorted logic is that
some built-in symbols are parametrically polymorphic.
For instance, the function symbol for extracting the element of any array has
type <math>(\mathit{ARRAY}\ T_1\ \mathit{OF}\ T_2,\; T_1) \to T_2</math>
for all first-order types <math>T_1, T_2</math>.

==== Type Ascription ====

By the type inference rules above some terms might have more than one type.
This can happen with terms built with polymorphic data type constructors
that have more than one return type for the same input type.
In that case, a type ascription operator (<code>::</code>) must be applied
to the constructor to specify the intended return type.

DATATYPE [X]
List[X] = nil | cons (head: X, tail: List[X])
END;

ASSERT y = cons(1, nil::List[REAL]);

DATATYPE [X, Y]
Union[X, Y] = left(val_l: X) | right(val_r: Y)
END;

ASSERT y = left::Union[BOOLEAN, REAL](TRUE);

The constant symbol <math>\mathrm{nil}</math> declared above has infinitely many types
(<math>\mathrm{List}[\mathrm{REAL}]</math>, <math>\mathrm{List}[\mathrm{BOOLEAN}]</math>,
<math>\mathrm{List}[[\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{List}[\mathrm{List}[\mathrm{REAL}]]</math>, ...)
CVC4's type checker requires the user to indicate explicitly the type
of each occurrence of <code>nil</code> in a term.
Similarly,
the injection operator <code>left</code> has infinitely many return types
for the same input type, for instance:
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{REAL}]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, [\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{List}[\mathrm{REAL}]]</math>,
and so on.
Applications of <code>left</code> need to specify the intended returned typed, as shown above.

== Terms and Formulas ==

In addition to type expressions, CVC4 has expressions for terms and for formulas
(i.e., terms of type <math>\mathrm{BOOLEAN}</math>).
By and large, these are standard first-order terms built out of typed variables,
predefined theory-specific operators, free (i.e., user-defined) function symbols,
and quantifiers.
Extensions include an if-then-else operator, lambda abstractions, and local symbol
declarations, as illustrated below.
Note that these extensions still keep CVC4's language first-order.
In particular, lambda abstractions are restricted to take and return only terms of
a first-order type.
Similarly, variables can only be of a first-order type.

A number of built-in function symbols (for instance, the arithmetic ones) are used
as infix operators. All user-defined symbols are used as prefix ones.

User-defined, i.e., free, function symbols include ''constant symbols'' and
''predicate symbols'', respectively nullary function symbols and function symbols
with a <math>\mathrm{BOOLEAN}</math> return type.
These symbols are introduced with global declarations of the form
<math> f_1, \ldots, f_m: T;</math>
where <math>m > 0</math>, <math>f_i</math> are the names of the symbols and
<math>T</math> is their type:

% integer constants

a, b, c: INT;

% real constants

x, y, z: REAL;

% unary function

f1: REAL -> REAL;

% binary function

f2: (REAL, INT) -> REAL;

% unary function with a tuple argument

f3: [INT, REAL] -> BOOLEAN;

% binary predicate

p: (INT, REAL) -> BOOLEAN;

% Propositional "variables"

P, Q: BOOLEAN;

Like type declarations, function symbol declarations like the above have global scope
and must be unique.
In other words, it is not possible to declare a function symbol globally more than once
in the same lexical scope.
This entails among other things that globally-defined free symbols cannot be overloaded
with different types and that theory symbols cannot be redeclared globally as free symbols.

=== Global symbol definitions ===

As with types, a function symbol can be defined as the name of another term
of the corresponding type.
With constant symbols, this is done with a declaration of the form <math>f:T = t;</math> :

c: INT;

i: INT = 5 + 3*c; % i is effectively a shorthand for 5 + 3*c

j: REAL = 3/4;

t: [REAL, INT] = (2/3, -4);

r: [# key: INT, value: REAL #] = (# key := 4, value := (c + 1)/2 #);

f: BOOLEAN = FORALL (x:INT): x <= 0 OR x > c ;

A restriction on constants of type <math>\mathit{BOOLEAN}</math> is that their value
can only be a closed formula, that is, a formula with no free variables.

A term and its name can be used interchangeably in later expressions.
Named terms are often useful for shared subterms (terms used several times in different places)
since their use can make the input exponentially more concise.
Named terms are processed very efficiently by CVC4.
It is much more efficient to associate a complex term with a name directly rather than
to declare a constant and later assert that it is equal to the same term.
This point is explained in more detail later in section [[Commands | Commands]].

More generally, in CVC4 one can associate a term to function symbols of any arity.
For non-constant function symbols this is done with a declaration of the form

<center>
<math>f:(T_1, \ldots, T_n) \to T = \mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t\;;</math>
</center>

where <math>t</math> is any term of type <math>T</math> with free variables
in <math>\{x_1, \ldots, x_n\}</math>.
The lambda binder has the usual semantics and conforms to the usual lexical scoping rules:
within the term <math>t</math> the declaration of the symbols <math>x_1, \ldots, x_n</math>
as local variables of respective type <math>T_1, \ldots, T_n</math> hides any previous
declarations of those symbols that are in scope.

As a general shorthand, when <math>k</math> consecutive types
<math>T_i, \ldots, T_{i+k-1}</math> in the lambda expression
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t</math> are identical, the syntax
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x_i,\ldots, x_{i+k-1}:T_i,\ldots, x:T_n): t</math>
can also be used.

% Global declaration of x as a unary function symbol

x: REAL -> REAL;

% Local declarations of x as variable (hiding the global one)

f: REAL -> REAL = LAMBDA (x: REAL): 2*x + 3;

p: (INT, INT) -> BOOLEAN = LAMBDA (x,i: INT): i*x - 1 > 0;

g: (REAL, INT) -> [REAL, INT] = LAMBDA (x: REAL, i:INT): (x + 1, i - 3);

Note that lambda definitions are not recursive:
the symbol being defined cannot occur in the body of the lambda term.
They should be understood as macros.
For instance, any occurrence of the term <math>f(t)</math>
where <math>f</math> is as defined above will be treated
as if it was the term <math>(2*t + 3)</math>.

=== Local symbol definitions ===

Constant and function symbols can also be declared locally anywhere within a term
by means of a let binder.
This is done with a declaration of the form

<center>
<math>
\mathrm{LET}\ f = s \ \mathrm{IN}\ t ;
</math>
</center>

where <math>t</math> is a term with no free variables, possibly a lambda term.
Let binders can be nested arbitrarily and follow the usual lexical scoping rules.
The following general form
<center>
<math>
\mathrm{LET}\ f_1 = t_1, f_2 = t_2, \ldots, f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>
can used as a shorthand for
<center>
<math>
\mathrm{LET}\ f_1 = t_1\ \mathrm{IN}\
\mathrm{LET}\ f_2 = t_2\ \mathrm{IN}\
\ldots \
\mathrm{LET}\ f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>

t: REAL =
LET x1 = 42,
g = LAMBDA(x:INT): x + 1,
x2 = 2*x1 + 7/2
IN
(LET x3 = g(x1) IN x3 + x2) / x1;

Note that the same symbol = is used, unambiguously, in the syntax of global declarations,
let declarations, and as a predicate symbol.

'''Note:'''
A <math>\mathrm{LET}</math> term with a multiple symbols defines them sequentially.
A parallel version of the <math>\mathrm{LET}</math> construct will be introduced in a later version.

== Built-in theories and their symbols ==

In addition to user-defined symbols, CVC4 terms can use a number of predefined symbols:
the logical symbols, such as <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, etc.,
as well as theory symbols, function symbols belonging to one of the built-in theories.
They are described next, with the theory symbols grouped by theory.

=== Logical Symbols ===

The logical symbols in CVC4's language include
the equality and disequality predicate symbols, respectively written as = and /=,
the multiarity disequality symbol <math>\mathrm{DISTINCT}</math>,
together with the logical constants <math>\mathrm{TRUE}</math>, <math>\mathrm{FALSE}</math>,
the connectives <math>\mathrm{NOT}</math>, <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, <math>\mathrm{XOR}</math>, <math>\Rightarrow</math>, <math>\Leftrightarrow</math>, and
the first-order quantifiers <math>\mathrm{EXISTS}</math> and <math>\mathrm{FORALL}</math>,
all with the standard many-sorted logic semantics.

The binary connectives have infix syntax and type
<math>(\mathrm{BOOLEAN},\mathrm{BOOLEAN}) \to \mathrm{BOOLEAN}</math>.
The symbols = and /=, which are also infix, are instead parametrically polymorphic,
having type <math>(T,T) \to \mathrm{BOOLEAN}</math>
for every first-order type <math>T</math>.
They are interpreted respectively as the identity relation and its complement.

The DISTINCT symbol is both overloaded and polymorphic.
It has type <math>(T,...,T) \to \mathrm{BOOLEAN}</math>
for every sequence <math>(T,...,T)</math> of length <math>n > 0</math>
and first-order type <math>T</math>.
For each <math>n > 0</math>, it is interpreted as the relation
that holds exactly for tuples of pairwise distinct elements.

The syntax for quantifiers is similar to that of the lambda binder.

Here is an example of a formula built just of these logical symbols and variables:

A, B: TYPE;

q: BOOLEAN = FORALL (x,y: A, i,j,k: B):
i = j AND i /= k => EXISTS (z: A): x /= z OR z /= y;

Binding and scoping of quantified variables follows the same rules as
in let expressions.
In particular, a quantifier will shadow in its scope any constant and function symbols
with the same name as one of the variables it quantifies:

A: TYPE;
i, j: INT;

% The first occurrence of i and of j in f are constant symbols,
% the others are variables.

f: BOOLEAN = i = j AND FORALL (i,j: A): i = j OR i /= j;

Optionally, it is also possible to specify instantiation patterns
for quantified variables.
The general syntax for a quantified formula <math>\psi</math> with patterns is

<center>
<math>
Q\;(x_1:T_1, \ldots, x_k:T_k):\; p_1: \ldots\; p_n:\; \varphi
</math>
</center>

where <math>n \geq 0</math>, <math>Q</math> is
either <math>\mathrm{FORALL}</math> or <math>\mathrm{EXISTS}</math>,
<math>\varphi</math> is a term of type <math>\mathrm{BOOLEAN}</math>,
and each of the <math>p_i</math>'s,
a pattern for the quantifier <math>Q\;(x_1:T_1, \ldots, x_k:T_k)</math>, has the form

<center>
<math>
\mathrm{PATTERN}\; (t_1, \ldots, t_m)
</math>
</center>

where <math>m > 0</math> and <math>t_1, \ldots, t_m</math> are
arbitrary binder-free terms (no lets, no quantifiers).
Those terms can contain (free) variables, typically, but not exclusively,
drawn from <math>x_1, \ldots, x_k</math>.
(Additional variables can occur if <math>\psi</math> occurs in a bigger formula
binding those variables.)

A: TYPE;
b, c: A;
p, q: A -> BOOLEAN;
r: (A, A) -> BOOLEAN;

ASSERT FORALL (x0, x1, x2: A):
PATTERN (r(x0, x1), r(x1, x2)):
(r(x0, x1) AND r(x1, x2)) => r(x0, x2) ;

ASSERT FORALL (x: A):
PATTERN (r(x, b)):
PATTERN (r(x, c)):
p(x) => q(x) ;

ASSERT EXISTS (y: A):
FORALL (x: A):
PATTERN (r(x, y), p(y)):
r(x, y) => q(x) ;

Patterns have no logical meaning:
adding them to a formula does not change its semantics.
Their purpose is purely operational, as explained in
the [[#Instantiation Patterns | Instantiation Patterns]] section.

In addition to these constructs, CVC4 also has a general mixfix conditional operator
of the form

<center>
<math>
\mathrm{IF}\ b\ \mathrm{THEN}\ t\ \mathrm{ELSIF}\ b_1\ \mathrm{THEN}\ t_1\ \ldots\ \mathrm{ELSIF}\ b_n\ \mathrm{THEN}\ t_n\ \mathrm{ELSE}\ t_{n+1}\ \mathrm{ENDIF}
</math>
</center>

with <math>n \geq 0</math> where
<math>b, b_1, \ldots, b_n</math> are terms of type <math>\mathrm{BOOLEAN}</math> and
<math>t, t_1, \ldots, t_n, t_{n+1}</math> are terms of the same first-order type <math>T</math>:

% Conditional term
x, y, z, w: REAL;

t: REAL =
IF x > 0 THEN y
ELSIF x >= 1 THEN z
ELSIF x > 2 THEN w
ELSE 2/3 ENDIF;

=== User-defined Functions and Types ===

The theory of user-defined functions,also know in the SMT literature as
the theory ''Equality over Uninterpreted Functions'', or ''EUF'', is in effect
a family of theories of equality parametrized by the basic types and the free symbols
a user can define during a run of CVC4.

This theory has no built-in symbols (other than the logical ones).
Its types consist of ''all and only'' the user-defined types.
Its function symbols consist of ''all and only'' the user-defined free symbols.

=== Arithmetic ===

The real arithmetic theory has two types:
<math>\mathrm{REAL}</math> and <math>\mathrm{INTEGER}</math>
with the latter a subtype of the first.
Its built-in symbols for the usual arithmetic constants
and operators over the type <math>\mathrm{REAL}</math>, each with the expected type:
all numerals 0, 1, ..., as well as - (both unary and binary), +, *, /, <, >, <=, >=.
Application of the binary symbols are in infix form.
Note that + is only binary, and so an expression such as +4 is ill-formed.

Rational values can be expressed in decimal or fractional format,
e.g., 0.1, 23.243241, 1/2, 3/4, and so on.
A leading 0 is mandatory for decimal numbers smaller than one
(e.g., the syntax .3 cannot be used as a shorthand for 0.3).
However, a trailing 0 is ''not'' required for decimals that are whole numbers
(e.g., 3. is allowed as a shorthand for 3.0).
The size of the numerals used in the representation of natural and rational numbers
is unbounded; more accurately, bounded only by the amount of available memory.

=== Bit vectors ===

=== Arrays ===

The theory of arrays is a parametric theory of (total) unary maps.
It comes equipped with mixfix polymorphic selection and update operators, respectively
<center>
<math>\_[\_]</math> and <math>\_\ \mathrm{WITH}\ [\_]\ := \_</math> .
</center>
The semantics of these operators is the expected one:
for all first-order types <math>T_1</math> and <math>T_2</math>,
if <math>a</math> is of type <math>\mathrm{ARRAY}\ T_1 \mathrm{OF}\ T_2</math>,
<math>i</math> is of type <math>T_1</math>, and
<math>v</math> is of type <math>T_2</math>,
* <math>a[i]</math> denotes the value that <math>a</math> associates to index <math>i</math>,
* <math>a\ \mathrm{WITH}\ [i]\ := v</math> denotes a map that associates <math>v</math> to index <math>i</math> and is otherwise identical to <math>a</math>.
Sequential updates can be chained with the shorthand syntax
<math>\_\ \mathrm{WITH}\ [\_]\ := \_, \ldots, [\_]\ := \_</math>.

A: TYPE = ARRAY INT OF REAL;
a: A;
i: INT = 4;

% selection:

elem: REAL = a[i];

% update

a1: A = a WITH [10] := 1/2;

% sequential update
% (syntactic sugar for (a WITH [10] := 2/3) WITH [42] := 3/2)

a2: A = a WITH [10] := 2/3, [42] := 3/2;

Since arrays are just maps, equality between them is extensional, that is,
for two arrays of the same type to be different they have to map at least one
index to differ values.

=== Data types ===

The theory of inductive data types is in fact a family of theories parametrized
by a data type declaration specifying constructors and selectors
for one or more user-defined data types.

No built-in operators other than equality and disequality are provided
for this family in the native language.
Each user-provided data type declaration, however, generates constructor, selector and tester operators
as described in the [[#Inductive Data Types | Inductive Data Types]] section.

=== Tuples and Records ===

Semantically both records and tuples can be seen as special instances
of inductive data types.
CVC4 implements them internally indeed as data types.
In essence, a record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math>
is encoded as a data type of the form

<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\ \ \mathrm{Record} = \mathit{rec}(l_0:T_0, \ldots, l_n:T_n) \\
\mathrm{END};
\end{array}
</math>
</center>

Tuples of length <math>n</math> are in turn special cases of records whose field names are
the numerals from <math>0</math> to <math>n-1</math>.

Externally, tuples and records have their own syntax for constructor and selector operators.
* Records of type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> have the associated record constructor <math>(\#\ l_0 := \_,\; \ldots,\; l_n := \_\ \#)</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.
* Tuples of type <math>[\ T_0, \ldots, T_n\ ]</math> have the associated tuple constructor <math>(\ \_,\; \ldots,\; \_\ )</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively. Note that the empty tuple can be created with <math>(\ )</math>; however, a single-element tuple cannot be directly created, as <math>(\ \_\ )</math> is interpreted as a parenthesized (non-tuple) expression.

The selector operators on records and tuples follows a dot notation syntax.

% Record construction and field selection
Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);
k: INT = x.key;
v: REAL = x.weight;

% Tuple construction and projection
y: [REAL, INT, REAL] = ( 4/5, 9, 11/9 );
first_elem: REAL = y.0;
third_elem: REAL = y.2;

Differently from data types, records and tuples are also provided with built-in update operators similar in syntax and semantics to the update operator for arrays.
More precisely, for each record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .l_i\ := \_
</math>
</center>

The operator maps a record <math>r</math> of that type and a value <math>v</math>
of type <math>T_i</math> to the record that stores <math>v</math> in field <math>l_i</math>
and is otherwise identical to <math>r</math>.
Analogously, for each tuple type <math>[T_0, \ldots, T_n]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .i\ := \_
</math>
</center>

with similar semantics.

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = x WITH .weight := 48;

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = y WITH .1 := 3;

Updates to a nested component can be combined in a single WITH operator:

Cache: TYPE = ARRAY [0..100] OF [# addr: INT, data: REAL #];
State: TYPE = [# pc: INT, cache: Cache #];

s0: State;
s1: State = s0 WITH .cache[10].data := 2/3;

Note that, differently from updates on arrays, tuple and record updates are
just additional syntactic sugar.
For instance, the record <code>x1</code> and tuple <code>y1</code> defined above
could have been equivalently defined as follows:

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = (# key := x.key, weight := 48 #);

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = ( y.0, 3, y.1 );

== Commands ==

In addition to declarations of types and function symbols,
the CVC4 native language contains the following commands:

* <math>\mathrm{ASSERT}\ F</math> -- Add the formula <math>F</math> to the current logical context <math>\Gamma</math>.
* [[#CHECKSAT|<math>\mathrm{CHECKSAT}\ F</math>]] -- Check if the formula <math>F</math> is satisfiable in the current logical context (<math>\Gamma \not\models_T \mathrm{NOT}\ F</math>).
* <math>\mathrm{CONTINUE}</math> -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, search for a counter-example different from the current one.
* [[#COUNTEREXAMPLE|<math>\mathrm{COUNTEREXAMPLE}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print the context that is a witness for invalidity/satisfiability.
* [[#COUNTERMODEL|<math>\mathrm{COUNTERMODEL}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print a model that makes the formula invalid/satisfiable. The model is provided in terms of concrete values for each free symbol.
* <math>\mathrm{OPTION}\ o\ v</math> -- Set the command-line option flag <math>o</math> to value <math>v</math>. The argument <math>o</math> is provide as a string literal enclosed in double-quotes and <math>v</math> as an integer value.
* <math>\mathrm{POP}</math> -- Equivalent to <math>\mathrm{POPTO}\ 1</math>
* [[#PUSH and POPTO|<math>\mathrm{POPTO}\ n</math>]] -- Restore the system to the state it was in right before the most recent call to <math>\mathrm{PUSH}</math> made from assertion (stack) level <math>n</math>. Note that the current assertion level is printed as part of the output of the <math>\mathrm{WHERE}</math> command.
* [[#PUSH and POPTO|<math>\mathrm{PUSH}</math>]] -- Save (checkpoint) the current state of the system.
* [[#QUERY|<math>\mathrm{QUERY}\ F</math>]] -- Check if the formula <math>F</math> is valid in the current logical context (<math>\Gamma\models_T F</math>).
* [[#RESTART|<math>\mathrm{RESTART}\ F</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, repeat the check but with the additional assumption <math>F</math> in the context.
* <math>\mathrm{PRINT}\ t</math> -- Parse and print back the term <math>t</math>.
* <math>\mathrm{TRANSFORM}\ t</math> -- Simplify the term <math>t</math> and print the result.
* <math>\mathrm{WHERE}</math> -- Print all the formulas in the current logical context <math>\Gamma</math>.

The remaining commands take a single argument, given as a string literal enclosed in double-quotes.

* <math>\mathrm{ECHO}\ s</math> -- Print string <math>s</math>
* <math>\mathrm{INCLUDE}\ f</math> -- Read commands from file <math>f</math>.
* <math>\mathrm{TRACE}\ f</math> -- Turn on tracing for the debug flag <math>f</math>.
* <math>\mathrm{UNTRACE}\ f</math> -- Turn off tracing for the debug flag <math>f</math>.

Here, we explain some of the above commands in more detail.

=== QUERY ===

The command <math>\mathrm{QUERY}\ F</math> invokes the core functionality of CVC4 to check
the validity of the formula <math>F</math> with respect to the assertions made thus far,
which constitute the context <math>\Gamma</math>.
The argument <math>F</math> must be well typed term of type <math>\mathrm{BOOLEAN}</math>,
as described in [[#Terms and Formulas | Terms and Formulas]].

The execution of this command always terminates and produces one of three possible answers:
<code>valid</code>, <code>invalid</code>, and <code>unknown</code>.

* A <code>valid</code> answer indicates that <math>\Gamma \models_T F</math>. After a query returning such an answer, the logical context <math>\Gamma</math> is exactly as it was before the query.
* An <code>invalid</code> answer indicates that <math>\Gamma \not\models_T F</math>, that is, there is a model of the background theory <math>T</math> that satisfies <math>\Gamma \cup \{\mathrm{NOT}\ F\}</math>. When <math>\mathrm{QUERY}\ F</math> returns <code>invalid</code>, the logical context <math>\Gamma</math> is augmented with a set <math>\Delta</math> of ground (i.e., variable-free) literals such that <math>\Gamma\cup\Delta</math> is satisfiable in <math>T</math>, but <math>\Gamma\cup\Delta\models_T \mathrm{NOT}\ F</math>. In fact, in this case <math>\Delta</math> ''propositionally entails'' <math>\mathrm{NOT}\ F</math>, in the sense that, every truth assignment to the literals of <math>\Delta</math> that satisfies <math>\Delta</math> falsifies <math>F</math>. We call the new context <math>\Gamma\cup\Delta</math> a ''counterexample'' for <math>F</math>.
* An <code>unknown</code> answer is similar to an <code>invalid</code> answer in that additional literals are added to the context which propositionally entail <math>\mathrm{NOT}\ F</math>. The difference in this case is that CVC4 cannot guarantee that <math>\Gamma\cup\Delta</math> is actually satisfiable in <math>T</math>.

CVC4 may report <code>unknown</code> when the context or the query contains
non-linear arithmetic terms or quantifiers.
In all other cases, it is expected to be sound and complete,
i.e., to report <code>Valid</code> if <math>\Gamma \models_T F</math>
and <code>Invalid</code> otherwise.

After an <code>invalid</code> (resp. <code>unknown</code>) answer,
counterexamples (resp. possible counterexamples) can be obtained with
a <math>\mathrm{WHERE}</math>, <math>\mathrm{COUNTEREXAMPLE}</math>,
or <math>\mathrm{COUNTERMODEL}</math> command.


Since the <math>\mathrm{QUERY}</math> command may modify
the current context, if one needs to check several formulas in a row
in the same context, it is a good idea to surround every
query by a <math>\mathrm{PUSH}</math> and <math>\mathrm{POP}</math> invocation
in order to preserve the context:

PUSH;
QUERY <formula>;
POP;

=== CHECKSAT ===

The command <math>\mathrm{CHECKSAT}\ F</math> behaves identically
to <math>\mathrm{QUERY}\ \mathrm{NOT}\ F</math>.

=== RESTART ===

The command <math>\mathrm{RESTART}\ F</math> can only be invoked after an invalid query.
For example, in an interactive setting:

QUERY <formula>;

CVC4> invalid

RESTART <formula2>;

Functionally, the behavior of the above command sequence is identical to the following:

PUSH;
QUERY <formula>;
POP;
ASSERT <formula2>;
QUERY <formula>;

The advantage of using the <math>\mathrm{RESTART}</math> command is that
the first command sequence may be executed much more efficiently that the second.
The reason is that with <math>\mathrm{RESTART}</math> CVC4 will re-use
what it has learned while answering the previous query rather than starting
over from scratch.

=== COUNTERMODEL ===

[More]

=== COUNTEREXAMPLE ===

[More]

=== PUSH and POPTO ===

CVC4's context can be understood as being stratified in ''assertion levels''
which are added and removed in a LIFO fashion.
The system starts at assertion level 0 and every execution of the PUSH command creates a new assertion level after the current one.
Each formula added to the context either by the user, via an ASSERT command, or internally by the system
is added to the most recent assertion level.
Executing POPTO n removes from the context the most recent n assertion levels and all the formulas in them.
So, for instance, POP 1 has the effect of retracting all formulas in the current assertion level (and removing that level).
Note that formulas at assertion level 0 cannot be retracted.

Note: Symbol declarations are always added at assertion level zero. So they are not affected by POPTO commands.

== Instantiation Patterns ==

CVC4 processes each universally quantified formula in the current context
by adding instances of the formula obtained by replacing its universal variables
with ground terms.
Patterns restrict the choice of ground terms for the quantified variables,
with the goal of controlling the potential explosion of ground instances.
In essence, adding patterns to a formula is a way for the user to tell CVC4
to focus only on certain instances which, in the user's opinion, will be
most helpful during a proof.

In more detail, patterns have the following effect on formulas that are found
in the logical context or get added to it later while CVC4 is trying to prove
the validity of some formula <math>F</math>.

If a formula in the current context starts with an existential quantifier,
CVC4 ''Skolemizes'' it, that is, replaces it in the context with the formula
obtained by substituting the existentially quantified variables
by fresh constants and dropping the quantifier.
Any patterns for the existential quantifier are simply ignored.

If a formula starts with a universal quantifier
<math>\mathrm{FORALL}\; (x_1:T_1, \ldots, x_n:T_n)</math>,
CVC4 adds to the context a number of instances of the formula,
with the goal of using them to prove the query <math>F</math> valid.
An instance is obtained by replacing each <math>x_i</math> with a ground term
of the same type occurring in one of the formulas in the context,
and dropping the universal quantifier.
If <math>x_i</math> occurs in a pattern
<math>\mathrm{PATTERN}\; (t_1, \ldots, t_m)</math> for the quantifier,
it will be instantiated only with terms obtained by simultaneously matching
all the terms in the pattern against ground terms in the current context
<math>\Gamma</math>.

Specifically, the matching process produces one or more substitutions
<math>\sigma</math> for the variables in <math>(t_1, \ldots, t_m)</math>
which satisfy the following invariant:
for each <math>i = 1, \ldots, m</math>, <math>\sigma(t_i)</math> is
a ground term and there is a ground term <math>s_i</math> in <math>\Gamma</math>
such that <math>\Gamma \models_T \sigma(t_i) = s_i</math>.
The variables of <math>(x_1:T_1, \ldots, x_n:T_n)</math> that occur
in the pattern are instantiated only with those substitutions
(while any remaining variables are instantiated arbitrarily).

The Skolemized version or the added instances of a context formula may themselves
start with a quantifier.
The same instantiation process is applied to them too, recursively.

Note that the matching mechanism is not limited to syntactic matching
but is modulo the equations asserted in the context.
Because of decidability and/or efficiency limitations, the matching process
is not exhaustive.
CVC4 will typically miss some substitutions that satisfy the invariant above.
As a consequence, it might fail to prove the validity of the query formula
<math>F</math>, which makes CVC4 incomplete for contexts containing
quantified formulas.
It should be noted though that exhaustive matching, which can be achieved
simply by not specifying any patterns, does not yield completeness anyway
since the instantiation of universal variables is still restricted
to just the ground terms in the context,
whereas in general additional ground terms might be needed.

Strings

2015-06-09T23:26:57Z

Tinelli: /* Extension */

This page describes support for the theory of strings in CVC4.

=Syntax=
This document focuses on input written in SMT-LIB 2 format.
A frontend for CVC4's native syntax is not available yet.

'''We highly recommend that users use SMT-LIB [http://smt-lib.org/language.shtml Version 2.5],
instead of Version 2.0.'''
The major difference is in the definition of escape sequences for string literals.

'''The syntax below is for CVC4 version > 1.4.''' Version 1.3 has only
''partial'' support for syntax in this document.

Since the string (sub)solver is still relatively new, the current stable version
of CVC4 (1.4) does not provide the latest version of that solver.
Please use our latest Development version instead.

Currently, the string solver supports string constants over a set of characters
limited to the printable ASCII characters. Other characters ''must'' be encoded
with escape sequences.
For arbitry alphabets, we plan to provide later a separate solver
for a theory of parametric sequences.

To use the string solver it is important to declare initially
(using the <code>set-logic</code> command) an SMT-LIB logic that includes strings.
Since the SMT-LIB standard does not have an official theory of strings and
related logics yet, the logic names described below are tentive and
might change later.

The basic logic is <code>QF_S</code> consisting of quanfier-free formulas
over just the theory of strings, e.g.:
(set-logic QF_S)

If the formulas contain sybols from theories, please add them accordingly,
e.g., if the formulas contain symbols from the BitVector theory,
the logic symbol should be <code>QF_SBV</code>.

The logic consisting of the full (quantified) theory strings is
<code>QF_SBV</code>:
(set-logic S)

==Unsat Cores==
The string solver supports the generation of unsatisfiable cores.
As with other subsolvers though, you must enable proofs at configuration time,
and then run CVC with "--dump-unsat-cores" flag.

==Options==
Some functions in the theory are have only experimental support currently and
are disabled by default (even in the <code>ALL_SUPPORTED</code> logic:
To use them:
(set-option :strings-exp true)

The solver can be run in ''finite model finding mode'' which guarantees
termination for satisfiable problems.
This mode is disabled by default. To enable it:
(set-option :strings-fmf true)
Note that in this mode the solver is much '''slower''' than in default mode,
so we recommend it only as a fall back option when the default mode fails
to find a solution with a reasonably large timeout.

To select the strategy of LB rule application: 0-lazy, 1-eager, 2-no (0 by default):
(set-option :strings-lb 1)

To set up string alphabet cardinality (256 by default, expert option):
(set-option :strings-alphabet-card n)
This is a reserved option for the extension of the sequence theory.

==Alphabet==
Currently, the solver's theory is based on an alphabet consisting of the 256
characters from (8-bit) Extended ASCII.
Since there are several versions of Extended ASCII, we allow string constants
to contain only ''printable US ASCII characters'', which are encoded
in the same way in all Extended ASCII versions.

'''Note:''' The alphabet will change to the one prescribed by the SMT-LIB standard
once there is one.

==Printable Characters==
A ''printable'' character is any character with numerical value between 0x20 and 0x7e
in the standard US ASCII encoding.

==Escape Sequences in String Constants==
String constants are denoted by SMT-LIB string literals consisting of sequences of printable characters delimited by double-quotes (<code>"</code>).

We support escape sequences used in most programming languages
to represent non-printable characters.

{| border="1"
|-
| <code>\0</code> … <code>\9</code>
| represents ASCII character 0 … 9, respectively
|-
| <code>\a</code>, <code>\b</code>, <code>\e</code>, <code>\f</code>, <code>\n</code>, <code>\r</code>, <code>\t</code>, <code>\v</code>
| represents its corresponding ASCII character (C++ convention)
|-
| <code>\</code>''ooo''
| encodes a single ASCII character where ''ooo'' consists of exactly three digits in the octal encoding of the character (from 0 to 377). For example, <code>\101</code> represents <code>A</code>. '''Note:''' going beyond value 377 might give unexpected results. For instance, <code>\437</code> will be translated in the two-character string <code>#7</code>.
|-
| <code>\x</code>''NN''
| encodes a single ASCII character, where ''NN'' consists of exactly two digits in the exadecimal encoding of the character.
|}

The backslash character (<code>\</code>) is silently ignored when it is followed by a sequence of characters not recognized as an escape sequence. For example, <code>\$ </code>, say, is parsed as if it was just <code>$</code>.

When CVC4 outputs a string constant, a non-printable/extended ASCII character is printed in the exadecimal format <code>\x</code>''NN'', except for the character denoted by the escape sequences <code>\a</code>, <code>\b</code>, <code>\e</code>, <code>\f</code>, <code>\n</code>, <code>\r</code>, <code>\t</code>, <code>\v</code>, which are printed using those escape sequences.

'''Note''':
These escape sequences are specific to string constants in the theory of strings. They are 'not' escape sequences in SMT-LIB 2 per se.
SMT-LIB 2.5 has only one escape sequence for string literals: <code>""</code>,
which denotes the double quotes character.
This means that a string literal like <code>"a""c"</code> is read by the solver as the string constant consisting of the characters <code>a</code>, <code>"</code>, and <code>c</code>.
The same constant can be entered as <code>"a\042c"</code> or <code>"a\x22c"</code>.

==Theory Signature==
To define a string variable, i.e., a free string constant:
(declare-fun x () String)
Alternatively:
(declare-const x () String)

String Concatenation:
(str.++ s1 s2 ... sn)
where s1, s2, ..., and sn are string terms. String concatenation takes at least 2 arguments.

String Length:
(str.len s)
where s is a string term.

Character in String:
(str.at s i)
where s is a string term and i is a natural number. (see partial functions)
The index is starting from 0.

Sub-String:
(str.substr s i j )
where s is a string term, i and j are natural numbers. (see partial functions)

==Escape Sequences for Regular Expressions==
Currently, it is for CVC format only. (Coming soon.)

==Symbolic Regular Expression==
Membership Constraint:
(str.in.re s r)
where s is a string term and r is a regular expression.

String to Regular Expression Conversion:
(str.to.re s)
where s is a string term. The statement turns a regular expression that only contains a string s.

Regular Expression Concatenation:
(re.++ r_1 r_2 ... r_n)
where r_1, r_2, ..., r_n are regular expressions.

Regular Expression Alternation:
(re.union r_1 r_2 ... r_n)
where r_1, r_2, ..., r_n are regular expressions. re.or is for releases before March, 2014.

Regular Expression Intersection:
(re.inter r_1 r_2 ... r_n)
where r_1, r_2, ..., r_n are regular expressions. re.itr is for releases before March, 2014.

Regular Expression Kleene-Star:
(re.* r)
where r is a regular expression.

Regular Expression Kleene-Cross:
(re.+ r)
where r is a regular expression.

Regular Expression Option:
(re.opt r)
where r is a regular expression.

Regular Expression Range:
(re.range s t)
where s, t are single characters in double quotes, e.g. "a", "b".
It returns a regular expression that contains any character between s and t.

Regular Expression Loop:
(re.loop r l u)
where r is a regular expression, l is a non-negative constant integer, and u is a non-negative constant integer.
It returns a regular expression that contains at least l repetitions of r and at most u repetitions of r.
If l >= u, it returns exactly l repetitions of r.

Regular Expression Loop-2:
(re.loop r l)
where r is a regular expression, and l is a non-negative constant integer.
It returns a regular expression that contains at least l repetitions of r.

The Empty Regular Expression:
re.nostr

The Regular Expression that contains all characters:
re.allchar

==Experimental Mode==
Following functions are under the --strings-exp option. They are under active refinement. Once they are stable, we will move them to the default mode. Please let us know when you have some suggestions.

String Char-At:
(str.at s i)
where s is a string term and i is an integer term. i is the position. See partial functions section.

String Sub-string:
(str.substr s i j)
where s is a string term and i, j are integer terms. i is the starting position, and j is the offset. See partial functions section.

String Contain:
(str.contains s t)
where s and t are string terms. It returns true if the string s contains the string t.
This function determines whether the string t can be found within the string s, returning true or false as appropriate.

String IndexOf:
(str.indexof s t i)
where s is a string, t is a non-empty string and i is a non-negative integer.
This function returns the position of the first occurrence of the specified value t in the string s after the index i.
It returns -1 if the value to search for never occurs.

String Replacement:
(str.replace s t1 t2)
where s, t1 and t2 are string terms, t1 is non-empty.
This function searches the string s for the specified value t1, and returns a new string where the first occurrence of the specified value t1 is replaced by the string t2.

String PrefixOf:
(str.prefixof s t)
where s and t are string terms. It returns true if the string s is a prefix of the string t.

String SuffixOf:
(str.suffixof s t)
where s and t are string terms. It returns true if the string s is a suffix of the string t.

String To Integer Conversion:
(str.to.int s)
where s is a string term. It returns the corresponding natural number if s is valid; otherwise, it returns -1.

Integer To String Conversion:
(int.to.str i)
where i is an integer term. It returns the corresponding string if i is a natural number; otherwise, it returns an empty string.

=Partial Functions=
By the definition of partial functions in [http://www.smtlib.org/ SMT-Lib Document], the following constraint is satisfiable:
(assert (= (str.substr "a" 2 10) "b"))
However, the following constraints are unsatisfiable:
(assert (= (str.substr "a" 2 1) "b"))
(assert (= (str.substr "a" 2 1) "c"))
To achieve a desirable goal, it requires users to guard proper conditions. For example,
(assert (= (str.at x j) "b"))
(assert (> j 0))
(assert (> (str.len x) j))

=Extensions=
Together with other engine in CVC4, we can extend new functionality in the theory of strings. For example,
(define-fun fun1 ((?x String) (?s String)) Bool
(or (= ?x ?s)
(> (str.len ?x) (str.len ?s))
))
Quantifiers over bounded Integers (with strings in the body) are supported in the experimental mode; however, quantifiers over strings are still under development.

=Limitations=
The decidability of this theory is unknown.
For satisfiable problems (without extensions), our solver is sound, complete and terminating in the FMF mode (although the FMF mode will be slower than the default mode in general). For unsatisfiable problems, termination is not guaranteed; however, users can tune the options for termination.

The current version of the solver supports ASCII characters only. We might move on to UNICODE in future versions.

=Examples=
Find an assignment for x, where x."ab"="ba".x and the length of x equals to 7.
(set-logic QF_S)

(declare-fun x () String)

(assert (= (str.++ x "ab") (str.++ "ba" x)))
(assert (= (str.len x) 7))

(check-sat)

Find assignments for x and y, where x and y are distinct and their lengths are equal.
(set-logic QF_S)

(declare-fun x () String)
(declare-fun y () String)

(assert (not (= x y)))
(assert (= (str.len x) (str.len y)))

(check-sat)

Find assignments for x and y, where x.y != y.x.
(set-logic QF_S)

(declare-fun x () String)
(declare-fun y () String)
(assert (not (= (str.++ x y) (str.++ y x))))

(check-sat)

Find a model for x, y and z, where x."ab".y=y."ba".z and z=x.y and x."a"!="a".x.
(set-logic QF_S)

(declare-fun x () String)
(declare-fun y () String)
(declare-fun z () String)

(assert (= (str.++ x "ab" y) (str.++ y "ba" z)))
(assert (= z (str.++ x y)))
(assert (not (= (str.++ x "a") (str.++ "a" x))))

(check-sat)

Find a model for x and y, where both x and y are in the RegEx (a*b)* and they are different but have the same length.
(set-logic QF_S)
(set-option :strings-fmf true)

(declare-fun x () String)
(declare-fun y () String)

(assert
(str.in.re x
(re.* (re.++ (re.* (str.to.re "a") ) (str.to.re "b") ))))
(assert (str.in.re y
(re.* (re.++ (re.* (str.to.re "a") ) (str.to.re "b") ))))

(assert (not (= x y)))
(assert (= (str.len x) (str.len y)))

(check-sat)

=API=
More details can be found in the [http://cvc4.cs.nyu.edu/wiki/Tutorials Tutorials].

==C++==
The example can be found in [https://github.com/CVC4/CVC4/blob/master/examples/api/strings.cpp examples/api/strings.cpp].

If setting the logic, use "S" to enable theory of strings.
smt.setLogic("S");

To create a string type, call <code>mkSetType</code> in the <code>ExprManager</code>.
Type string = em.stringType();

Make some string literals:
// std::string
std::string std_str_ab("ab");
// CVC4::String
CVC4::String cvc4_str_ab(std_str_ab);
CVC4::String cvc4_str_abc("abc");
// String constants
Expr ab = em.mkConst(cvc4_str_ab);
Expr abc = em.mkConst(CVC4::String("abc"));

Make some string variables:
Expr x = em.mkVar("x", string);
Expr y = em.mkVar("y", string);
Expr z = em.mkVar("z", string);

Make some string constraints:
// String concatenation: x.ab.y
Expr lhs = em.mkExpr(kind::STRING_CONCAT, x, ab, y);
// String concatenation: abc.z
Expr rhs = em.mkExpr(kind::STRING_CONCAT, abc, z);
// x.ab.y = abc.z
Expr formula1 = em.mkExpr(kind::EQUAL, lhs, rhs);
// Length of y: |y|
Expr leny = em.mkExpr(kind::STRING_LENGTH, y);
// |y| >= 0
Expr formula2 = em.mkExpr(kind::GEQ, leny, em.mkConst(Rational(0)));
// Regular expression: (ab[c-e]*f)|g|h
Expr r = em.mkExpr(kind::REGEXP_UNION,
em.mkExpr(kind::REGEXP_CONCAT,
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("ab"))),
em.mkExpr(kind::REGEXP_STAR,
em.mkExpr(kind::REGEXP_RANGE, em.mkConst(String("c")), em.mkConst(String("e")))),
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("f")))),
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("g"))),
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("h"))));
// String variables
Expr s1 = em.mkVar("s1", string);
Expr s2 = em.mkVar("s2", string);
// String concatenation: s1.s2
Expr s = em.mkExpr(kind::STRING_CONCAT, s1, s2);
// s1.s2 in (ab[c-e]*f)|g|h
Expr formula3 = em.mkExpr(kind::STRING_IN_REGEXP, s, r);

Make a query:
Expr q = em.mkExpr(kind::AND,
formula1,
formula2,
formula3);

Check the result:
Result result = smt.checkSat(q);
std::cout << "CVC4 reports: " << q << " is " << result << "." << std::endl;
if(result == Result::SAT) {
std::cout << " x = " << smt.getValue(x) << std::endl;
std::cout << " s1.s2 = " << smt.getValue(s) << std::endl;
}

==Java==
The example can be found in [https://github.com/CVC4/CVC4/blob/master/examples/api/java/Strings.java examples/api/java/Strings.java].

=References=
* Tianyi Liang, Andrew Reynolds, Cesare Tinelli, Clark Barrett and Morgan Deters. [http://link.springer.com/chapter/10.1007%2F978-3-319-08867-9_43 A DPLL(T) Theory Solver for a Theory of Strings and Regular Expressions].In Proceedings of the 26th International Conference on Computer Aided Verification (CAV'14), Vienna, Austria, 2014.
* Tianyi Liang. [http://ir.uiowa.edu/etd/1478/ Automated reasoning over string constraints]. PhD Dissertation, Department of Computer Science, The University of Iowa, Dec 2014.

Strings

2015-06-09T23:26:20Z

Tinelli: /* Limitation */

This page describes support for the theory of strings in CVC4.

=Syntax=
This document focuses on input written in SMT-LIB 2 format.
A frontend for CVC4's native syntax is not available yet.

'''We highly recommend that users use SMT-LIB [http://smt-lib.org/language.shtml Version 2.5],
instead of Version 2.0.'''
The major difference is in the definition of escape sequences for string literals.

'''The syntax below is for CVC4 version > 1.4.''' Version 1.3 has only
''partial'' support for syntax in this document.

Since the string (sub)solver is still relatively new, the current stable version
of CVC4 (1.4) does not provide the latest version of that solver.
Please use our latest Development version instead.

Currently, the string solver supports string constants over a set of characters
limited to the printable ASCII characters. Other characters ''must'' be encoded
with escape sequences.
For arbitry alphabets, we plan to provide later a separate solver
for a theory of parametric sequences.

To use the string solver it is important to declare initially
(using the <code>set-logic</code> command) an SMT-LIB logic that includes strings.
Since the SMT-LIB standard does not have an official theory of strings and
related logics yet, the logic names described below are tentive and
might change later.

The basic logic is <code>QF_S</code> consisting of quanfier-free formulas
over just the theory of strings, e.g.:
(set-logic QF_S)

If the formulas contain sybols from theories, please add them accordingly,
e.g., if the formulas contain symbols from the BitVector theory,
the logic symbol should be <code>QF_SBV</code>.

The logic consisting of the full (quantified) theory strings is
<code>QF_SBV</code>:
(set-logic S)

==Unsat Cores==
The string solver supports the generation of unsatisfiable cores.
As with other subsolvers though, you must enable proofs at configuration time,
and then run CVC with "--dump-unsat-cores" flag.

==Options==
Some functions in the theory are have only experimental support currently and
are disabled by default (even in the <code>ALL_SUPPORTED</code> logic:
To use them:
(set-option :strings-exp true)

The solver can be run in ''finite model finding mode'' which guarantees
termination for satisfiable problems.
This mode is disabled by default. To enable it:
(set-option :strings-fmf true)
Note that in this mode the solver is much '''slower''' than in default mode,
so we recommend it only as a fall back option when the default mode fails
to find a solution with a reasonably large timeout.

To select the strategy of LB rule application: 0-lazy, 1-eager, 2-no (0 by default):
(set-option :strings-lb 1)

To set up string alphabet cardinality (256 by default, expert option):
(set-option :strings-alphabet-card n)
This is a reserved option for the extension of the sequence theory.

==Alphabet==
Currently, the solver's theory is based on an alphabet consisting of the 256
characters from (8-bit) Extended ASCII.
Since there are several versions of Extended ASCII, we allow string constants
to contain only ''printable US ASCII characters'', which are encoded
in the same way in all Extended ASCII versions.

'''Note:''' The alphabet will change to the one prescribed by the SMT-LIB standard
once there is one.

==Printable Characters==
A ''printable'' character is any character with numerical value between 0x20 and 0x7e
in the standard US ASCII encoding.

==Escape Sequences in String Constants==
String constants are denoted by SMT-LIB string literals consisting of sequences of printable characters delimited by double-quotes (<code>"</code>).

We support escape sequences used in most programming languages
to represent non-printable characters.

{| border="1"
|-
| <code>\0</code> … <code>\9</code>
| represents ASCII character 0 … 9, respectively
|-
| <code>\a</code>, <code>\b</code>, <code>\e</code>, <code>\f</code>, <code>\n</code>, <code>\r</code>, <code>\t</code>, <code>\v</code>
| represents its corresponding ASCII character (C++ convention)
|-
| <code>\</code>''ooo''
| encodes a single ASCII character where ''ooo'' consists of exactly three digits in the octal encoding of the character (from 0 to 377). For example, <code>\101</code> represents <code>A</code>. '''Note:''' going beyond value 377 might give unexpected results. For instance, <code>\437</code> will be translated in the two-character string <code>#7</code>.
|-
| <code>\x</code>''NN''
| encodes a single ASCII character, where ''NN'' consists of exactly two digits in the exadecimal encoding of the character.
|}

The backslash character (<code>\</code>) is silently ignored when it is followed by a sequence of characters not recognized as an escape sequence. For example, <code>\$ </code>, say, is parsed as if it was just <code>$</code>.

When CVC4 outputs a string constant, a non-printable/extended ASCII character is printed in the exadecimal format <code>\x</code>''NN'', except for the character denoted by the escape sequences <code>\a</code>, <code>\b</code>, <code>\e</code>, <code>\f</code>, <code>\n</code>, <code>\r</code>, <code>\t</code>, <code>\v</code>, which are printed using those escape sequences.

'''Note''':
These escape sequences are specific to string constants in the theory of strings. They are 'not' escape sequences in SMT-LIB 2 per se.
SMT-LIB 2.5 has only one escape sequence for string literals: <code>""</code>,
which denotes the double quotes character.
This means that a string literal like <code>"a""c"</code> is read by the solver as the string constant consisting of the characters <code>a</code>, <code>"</code>, and <code>c</code>.
The same constant can be entered as <code>"a\042c"</code> or <code>"a\x22c"</code>.

==Theory Signature==
To define a string variable, i.e., a free string constant:
(declare-fun x () String)
Alternatively:
(declare-const x () String)

String Concatenation:
(str.++ s1 s2 ... sn)
where s1, s2, ..., and sn are string terms. String concatenation takes at least 2 arguments.

String Length:
(str.len s)
where s is a string term.

Character in String:
(str.at s i)
where s is a string term and i is a natural number. (see partial functions)
The index is starting from 0.

Sub-String:
(str.substr s i j )
where s is a string term, i and j are natural numbers. (see partial functions)

==Escape Sequences for Regular Expressions==
Currently, it is for CVC format only. (Coming soon.)

==Symbolic Regular Expression==
Membership Constraint:
(str.in.re s r)
where s is a string term and r is a regular expression.

String to Regular Expression Conversion:
(str.to.re s)
where s is a string term. The statement turns a regular expression that only contains a string s.

Regular Expression Concatenation:
(re.++ r_1 r_2 ... r_n)
where r_1, r_2, ..., r_n are regular expressions.

Regular Expression Alternation:
(re.union r_1 r_2 ... r_n)
where r_1, r_2, ..., r_n are regular expressions. re.or is for releases before March, 2014.

Regular Expression Intersection:
(re.inter r_1 r_2 ... r_n)
where r_1, r_2, ..., r_n are regular expressions. re.itr is for releases before March, 2014.

Regular Expression Kleene-Star:
(re.* r)
where r is a regular expression.

Regular Expression Kleene-Cross:
(re.+ r)
where r is a regular expression.

Regular Expression Option:
(re.opt r)
where r is a regular expression.

Regular Expression Range:
(re.range s t)
where s, t are single characters in double quotes, e.g. "a", "b".
It returns a regular expression that contains any character between s and t.

Regular Expression Loop:
(re.loop r l u)
where r is a regular expression, l is a non-negative constant integer, and u is a non-negative constant integer.
It returns a regular expression that contains at least l repetitions of r and at most u repetitions of r.
If l >= u, it returns exactly l repetitions of r.

Regular Expression Loop-2:
(re.loop r l)
where r is a regular expression, and l is a non-negative constant integer.
It returns a regular expression that contains at least l repetitions of r.

The Empty Regular Expression:
re.nostr

The Regular Expression that contains all characters:
re.allchar

==Experimental Mode==
Following functions are under the --strings-exp option. They are under active refinement. Once they are stable, we will move them to the default mode. Please let us know when you have some suggestions.

String Char-At:
(str.at s i)
where s is a string term and i is an integer term. i is the position. See partial functions section.

String Sub-string:
(str.substr s i j)
where s is a string term and i, j are integer terms. i is the starting position, and j is the offset. See partial functions section.

String Contain:
(str.contains s t)
where s and t are string terms. It returns true if the string s contains the string t.
This function determines whether the string t can be found within the string s, returning true or false as appropriate.

String IndexOf:
(str.indexof s t i)
where s is a string, t is a non-empty string and i is a non-negative integer.
This function returns the position of the first occurrence of the specified value t in the string s after the index i.
It returns -1 if the value to search for never occurs.

String Replacement:
(str.replace s t1 t2)
where s, t1 and t2 are string terms, t1 is non-empty.
This function searches the string s for the specified value t1, and returns a new string where the first occurrence of the specified value t1 is replaced by the string t2.

String PrefixOf:
(str.prefixof s t)
where s and t are string terms. It returns true if the string s is a prefix of the string t.

String SuffixOf:
(str.suffixof s t)
where s and t are string terms. It returns true if the string s is a suffix of the string t.

String To Integer Conversion:
(str.to.int s)
where s is a string term. It returns the corresponding natural number if s is valid; otherwise, it returns -1.

Integer To String Conversion:
(int.to.str i)
where i is an integer term. It returns the corresponding string if i is a natural number; otherwise, it returns an empty string.

=Partial Functions=
By the definition of partial functions in [http://www.smtlib.org/ SMT-Lib Document], the following constraint is satisfiable:
(assert (= (str.substr "a" 2 10) "b"))
However, the following constraints are unsatisfiable:
(assert (= (str.substr "a" 2 1) "b"))
(assert (= (str.substr "a" 2 1) "c"))
To achieve a desirable goal, it requires users to guard proper conditions. For example,
(assert (= (str.at x j) "b"))
(assert (> j 0))
(assert (> (str.len x) j))

=Extension=
Together with other engine in CVC4, we can extend new functionality in the theory of strings. For example,
(define-fun fun1 ((?x String) (?s String)) Bool
(or (= ?x ?s)
(> (str.len ?x) (str.len ?s))
))
Quantifiers over bounded Integers (with strings in the body) are supported in the experimental mode; however, quantifiers over strings are still under development.

=Limitations=
The decidability of this theory is unknown.
For satisfiable problems (without extensions), our solver is sound, complete and terminating in the FMF mode (although the FMF mode will be slower than the default mode in general). For unsatisfiable problems, termination is not guaranteed; however, users can tune the options for termination.

The current version of the solver supports ASCII characters only. We might move on to UNICODE in future versions.

=Examples=
Find an assignment for x, where x."ab"="ba".x and the length of x equals to 7.
(set-logic QF_S)

(declare-fun x () String)

(assert (= (str.++ x "ab") (str.++ "ba" x)))
(assert (= (str.len x) 7))

(check-sat)

Find assignments for x and y, where x and y are distinct and their lengths are equal.
(set-logic QF_S)

(declare-fun x () String)
(declare-fun y () String)

(assert (not (= x y)))
(assert (= (str.len x) (str.len y)))

(check-sat)

Find assignments for x and y, where x.y != y.x.
(set-logic QF_S)

(declare-fun x () String)
(declare-fun y () String)
(assert (not (= (str.++ x y) (str.++ y x))))

(check-sat)

Find a model for x, y and z, where x."ab".y=y."ba".z and z=x.y and x."a"!="a".x.
(set-logic QF_S)

(declare-fun x () String)
(declare-fun y () String)
(declare-fun z () String)

(assert (= (str.++ x "ab" y) (str.++ y "ba" z)))
(assert (= z (str.++ x y)))
(assert (not (= (str.++ x "a") (str.++ "a" x))))

(check-sat)

Find a model for x and y, where both x and y are in the RegEx (a*b)* and they are different but have the same length.
(set-logic QF_S)
(set-option :strings-fmf true)

(declare-fun x () String)
(declare-fun y () String)

(assert
(str.in.re x
(re.* (re.++ (re.* (str.to.re "a") ) (str.to.re "b") ))))
(assert (str.in.re y
(re.* (re.++ (re.* (str.to.re "a") ) (str.to.re "b") ))))

(assert (not (= x y)))
(assert (= (str.len x) (str.len y)))

(check-sat)

=API=
More details can be found in the [http://cvc4.cs.nyu.edu/wiki/Tutorials Tutorials].

==C++==
The example can be found in [https://github.com/CVC4/CVC4/blob/master/examples/api/strings.cpp examples/api/strings.cpp].

If setting the logic, use "S" to enable theory of strings.
smt.setLogic("S");

To create a string type, call <code>mkSetType</code> in the <code>ExprManager</code>.
Type string = em.stringType();

Make some string literals:
// std::string
std::string std_str_ab("ab");
// CVC4::String
CVC4::String cvc4_str_ab(std_str_ab);
CVC4::String cvc4_str_abc("abc");
// String constants
Expr ab = em.mkConst(cvc4_str_ab);
Expr abc = em.mkConst(CVC4::String("abc"));

Make some string variables:
Expr x = em.mkVar("x", string);
Expr y = em.mkVar("y", string);
Expr z = em.mkVar("z", string);

Make some string constraints:
// String concatenation: x.ab.y
Expr lhs = em.mkExpr(kind::STRING_CONCAT, x, ab, y);
// String concatenation: abc.z
Expr rhs = em.mkExpr(kind::STRING_CONCAT, abc, z);
// x.ab.y = abc.z
Expr formula1 = em.mkExpr(kind::EQUAL, lhs, rhs);
// Length of y: |y|
Expr leny = em.mkExpr(kind::STRING_LENGTH, y);
// |y| >= 0
Expr formula2 = em.mkExpr(kind::GEQ, leny, em.mkConst(Rational(0)));
// Regular expression: (ab[c-e]*f)|g|h
Expr r = em.mkExpr(kind::REGEXP_UNION,
em.mkExpr(kind::REGEXP_CONCAT,
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("ab"))),
em.mkExpr(kind::REGEXP_STAR,
em.mkExpr(kind::REGEXP_RANGE, em.mkConst(String("c")), em.mkConst(String("e")))),
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("f")))),
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("g"))),
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("h"))));
// String variables
Expr s1 = em.mkVar("s1", string);
Expr s2 = em.mkVar("s2", string);
// String concatenation: s1.s2
Expr s = em.mkExpr(kind::STRING_CONCAT, s1, s2);
// s1.s2 in (ab[c-e]*f)|g|h
Expr formula3 = em.mkExpr(kind::STRING_IN_REGEXP, s, r);

Make a query:
Expr q = em.mkExpr(kind::AND,
formula1,
formula2,
formula3);

Check the result:
Result result = smt.checkSat(q);
std::cout << "CVC4 reports: " << q << " is " << result << "." << std::endl;
if(result == Result::SAT) {
std::cout << " x = " << smt.getValue(x) << std::endl;
std::cout << " s1.s2 = " << smt.getValue(s) << std::endl;
}

==Java==
The example can be found in [https://github.com/CVC4/CVC4/blob/master/examples/api/java/Strings.java examples/api/java/Strings.java].

=References=
* Tianyi Liang, Andrew Reynolds, Cesare Tinelli, Clark Barrett and Morgan Deters. [http://link.springer.com/chapter/10.1007%2F978-3-319-08867-9_43 A DPLL(T) Theory Solver for a Theory of Strings and Regular Expressions].In Proceedings of the 26th International Conference on Computer Aided Verification (CAV'14), Vienna, Austria, 2014.
* Tianyi Liang. [http://ir.uiowa.edu/etd/1478/ Automated reasoning over string constraints]. PhD Dissertation, Department of Computer Science, The University of Iowa, Dec 2014.

Strings

2015-06-09T22:02:00Z

Tinelli: /* Escape Sequences for String Literals */

This page describes support for the theory of strings in CVC4.

=Syntax=
This document focuses on input written in SMT-LIB 2 format.
A frontend for CVC4's native syntax is not available yet.

'''We highly recommend that users use SMT-LIB [http://smt-lib.org/language.shtml Version 2.5],
instead of Version 2.0.'''
The major difference is in the definition of escape sequences for string literals.

'''The syntax below is for CVC4 version > 1.4.''' Version 1.3 has only
''partial'' support for syntax in this document.

Since the string (sub)solver is still relatively new, the current stable version
of CVC4 (1.4) does not provide the latest version of that solver.
Please use our latest Development version instead.

Currently, the string solver supports string constants over a set of characters
limited to the printable ASCII characters. Other characters ''must'' be encoded
with escape sequences.
For arbitry alphabets, we plan to provide later a separate solver
for a theory of parametric sequences.

To use the string solver it is important to declare initially
(using the <code>set-logic</code> command) an SMT-LIB logic that includes strings.
Since the SMT-LIB standard does not have an official theory of strings and
related logics yet, the logic names described below are tentive and
might change later.

The basic logic is <code>QF_S</code> consisting of quanfier-free formulas
over just the theory of strings, e.g.:
(set-logic QF_S)

If the formulas contain sybols from theories, please add them accordingly,
e.g., if the formulas contain symbols from the BitVector theory,
the logic symbol should be <code>QF_SBV</code>.

The logic consisting of the full (quantified) theory strings is
<code>QF_SBV</code>:
(set-logic S)

==Unsat Cores==
The string solver supports the generation of unsatisfiable cores.
As with other subsolvers though, you must enable proofs at configuration time,
and then run CVC with "--dump-unsat-cores" flag.

==Options==
Some functions in the theory are have only experimental support currently and
are disabled by default (even in the <code>ALL_SUPPORTED</code> logic:
To use them:
(set-option :strings-exp true)

The solver can be run in ''finite model finding mode'' which guarantees
termination for satisfiable problems.
This mode is disabled by default. To enable it:
(set-option :strings-fmf true)
Note that in this mode the solver is much '''slower''' than in default mode,
so we recommend it only as a fall back option when the default mode fails
to find a solution with a reasonably large timeout.

To select the strategy of LB rule application: 0-lazy, 1-eager, 2-no (0 by default):
(set-option :strings-lb 1)

To set up string alphabet cardinality (256 by default, expert option):
(set-option :strings-alphabet-card n)
This is a reserved option for the extension of the sequence theory.

==Alphabet==
Currently, the solver's theory is based on an alphabet consisting of the 256
characters from (8-bit) Extended ASCII.
Since there are several versions of Extended ASCII, we allow string constants
to contain only ''printable US ASCII characters'', which are encoded
in the same way in all Extended ASCII versions.

'''Note:''' The alphabet will change to the one prescribed by the SMT-LIB standard
once there is one.

==Printable Characters==
A ''printable'' character is any character with numerical value between 0x20 and 0x7e
in the standard US ASCII encoding.

==Escape Sequences in String Constants==
String constants are denoted by SMT-LIB string literals consisting of sequences of printable characters delimited by double-quotes (<code>"</code>).

We support escape sequences used in most programming languages
to represent non-printable characters.

{| border="1"
|-
| <code>\0</code> … <code>\9</code>
| represents ASCII character 0 … 9, respectively
|-
| <code>\a</code>, <code>\b</code>, <code>\e</code>, <code>\f</code>, <code>\n</code>, <code>\r</code>, <code>\t</code>, <code>\v</code>
| represents its corresponding ASCII character (C++ convention)
|-
| <code>\</code>''ooo''
| encodes a single ASCII character where ''ooo'' consists of exactly three digits in the octal encoding of the character (from 0 to 377). For example, <code>\101</code> represents <code>A</code>. '''Note:''' going beyond value 377 might give unexpected results. For instance, <code>\437</code> will be translated in the two-character string <code>#7</code>.
|-
| <code>\x</code>''NN''
| encodes a single ASCII character, where ''NN'' consists of exactly two digits in the exadecimal encoding of the character.
|}

The backslash character (<code>\</code>) is silently ignored when it is followed by a sequence of characters not recognized as an escape sequence. For example, <code>\$ </code>, say, is parsed as if it was just <code>$</code>.

When CVC4 outputs a string constant, a non-printable/extended ASCII character is printed in the exadecimal format <code>\x</code>''NN'', except for the character denoted by the escape sequences <code>\a</code>, <code>\b</code>, <code>\e</code>, <code>\f</code>, <code>\n</code>, <code>\r</code>, <code>\t</code>, <code>\v</code>, which are printed using those escape sequences.

'''Note''':
These escape sequences are specific to string constants in the theory of strings. They are 'not' escape sequences in SMT-LIB 2 per se.
SMT-LIB 2.5 has only one escape sequence for string literals: <code>""</code>,
which denotes the double quotes character.
This means that a string literal like <code>"a""c"</code> is read by the solver as the string constant consisting of the characters <code>a</code>, <code>"</code>, and <code>c</code>.
The same constant can be entered as <code>"a\042c"</code> or <code>"a\x22c"</code>.

==Theory Signature==
To define a string variable, i.e., a free string constant:
(declare-fun x () String)
Alternatively:
(declare-const x () String)

String Concatenation:
(str.++ s1 s2 ... sn)
where s1, s2, ..., and sn are string terms. String concatenation takes at least 2 arguments.

String Length:
(str.len s)
where s is a string term.

Character in String:
(str.at s i)
where s is a string term and i is a natural number. (see partial functions)
The index is starting from 0.

Sub-String:
(str.substr s i j )
where s is a string term, i and j are natural numbers. (see partial functions)

==Escape Sequences for Regular Expressions==
Currently, it is for CVC format only. (Coming soon.)

==Symbolic Regular Expression==
Membership Constraint:
(str.in.re s r)
where s is a string term and r is a regular expression.

String to Regular Expression Conversion:
(str.to.re s)
where s is a string term. The statement turns a regular expression that only contains a string s.

Regular Expression Concatenation:
(re.++ r_1 r_2 ... r_n)
where r_1, r_2, ..., r_n are regular expressions.

Regular Expression Alternation:
(re.union r_1 r_2 ... r_n)
where r_1, r_2, ..., r_n are regular expressions. re.or is for releases before March, 2014.

Regular Expression Intersection:
(re.inter r_1 r_2 ... r_n)
where r_1, r_2, ..., r_n are regular expressions. re.itr is for releases before March, 2014.

Regular Expression Kleene-Star:
(re.* r)
where r is a regular expression.

Regular Expression Kleene-Cross:
(re.+ r)
where r is a regular expression.

Regular Expression Option:
(re.opt r)
where r is a regular expression.

Regular Expression Range:
(re.range s t)
where s, t are single characters in double quotes, e.g. "a", "b".
It returns a regular expression that contains any character between s and t.

Regular Expression Loop:
(re.loop r l u)
where r is a regular expression, l is a non-negative constant integer, and u is a non-negative constant integer.
It returns a regular expression that contains at least l repetitions of r and at most u repetitions of r.
If l >= u, it returns exactly l repetitions of r.

Regular Expression Loop-2:
(re.loop r l)
where r is a regular expression, and l is a non-negative constant integer.
It returns a regular expression that contains at least l repetitions of r.

The Empty Regular Expression:
re.nostr

The Regular Expression that contains all characters:
re.allchar

==Experimental Mode==
Following functions are under the --strings-exp option. They are under active refinement. Once they are stable, we will move them to the default mode. Please let us know when you have some suggestions.

String Char-At:
(str.at s i)
where s is a string term and i is an integer term. i is the position. See partial functions section.

String Sub-string:
(str.substr s i j)
where s is a string term and i, j are integer terms. i is the starting position, and j is the offset. See partial functions section.

String Contain:
(str.contains s t)
where s and t are string terms. It returns true if the string s contains the string t.
This function determines whether the string t can be found within the string s, returning true or false as appropriate.

String IndexOf:
(str.indexof s t i)
where s is a string, t is a non-empty string and i is a non-negative integer.
This function returns the position of the first occurrence of the specified value t in the string s after the index i.
It returns -1 if the value to search for never occurs.

String Replacement:
(str.replace s t1 t2)
where s, t1 and t2 are string terms, t1 is non-empty.
This function searches the string s for the specified value t1, and returns a new string where the first occurrence of the specified value t1 is replaced by the string t2.

String PrefixOf:
(str.prefixof s t)
where s and t are string terms. It returns true if the string s is a prefix of the string t.

String SuffixOf:
(str.suffixof s t)
where s and t are string terms. It returns true if the string s is a suffix of the string t.

String To Integer Conversion:
(str.to.int s)
where s is a string term. It returns the corresponding natural number if s is valid; otherwise, it returns -1.

Integer To String Conversion:
(int.to.str i)
where i is an integer term. It returns the corresponding string if i is a natural number; otherwise, it returns an empty string.

=Partial Functions=
By the definition of partial functions in [http://www.smtlib.org/ SMT-Lib Document], the following constraint is satisfiable:
(assert (= (str.substr "a" 2 10) "b"))
However, the following constraints are unsatisfiable:
(assert (= (str.substr "a" 2 1) "b"))
(assert (= (str.substr "a" 2 1) "c"))
To achieve a desirable goal, it requires users to guard proper conditions. For example,
(assert (= (str.at x j) "b"))
(assert (> j 0))
(assert (> (str.len x) j))

=Extension=
Together with other engine in CVC4, we can extend new functionality in the theory of strings. For example,
(define-fun fun1 ((?x String) (?s String)) Bool
(or (= ?x ?s)
(> (str.len ?x) (str.len ?s))
))
Quantifiers over bounded Integers (with strings in the body) are supported in the experimental mode; however, quantifiers over strings are still under development.

=Limitation=
The decidability of this theory is unknown.
For satisfiable problems (without extensions), our solver is sound, complete and terminating in the FMF mode (although the FMF mode will be slower than the default mode in general). For unsatisfiable problems, the termination is not guaranteed; however, user can tune the options for termination.

Current version supports ASCII characters only. We will move on to UNICODE in the future version.

=Examples=
Find an assignment for x, where x."ab"="ba".x and the length of x equals to 7.
(set-logic QF_S)

(declare-fun x () String)

(assert (= (str.++ x "ab") (str.++ "ba" x)))
(assert (= (str.len x) 7))

(check-sat)

Find assignments for x and y, where x and y are distinct and their lengths are equal.
(set-logic QF_S)

(declare-fun x () String)
(declare-fun y () String)

(assert (not (= x y)))
(assert (= (str.len x) (str.len y)))

(check-sat)

Find assignments for x and y, where x.y != y.x.
(set-logic QF_S)

(declare-fun x () String)
(declare-fun y () String)
(assert (not (= (str.++ x y) (str.++ y x))))

(check-sat)

Find a model for x, y and z, where x."ab".y=y."ba".z and z=x.y and x."a"!="a".x.
(set-logic QF_S)

(declare-fun x () String)
(declare-fun y () String)
(declare-fun z () String)

(assert (= (str.++ x "ab" y) (str.++ y "ba" z)))
(assert (= z (str.++ x y)))
(assert (not (= (str.++ x "a") (str.++ "a" x))))

(check-sat)

Find a model for x and y, where both x and y are in the RegEx (a*b)* and they are different but have the same length.
(set-logic QF_S)
(set-option :strings-fmf true)

(declare-fun x () String)
(declare-fun y () String)

(assert
(str.in.re x
(re.* (re.++ (re.* (str.to.re "a") ) (str.to.re "b") ))))
(assert (str.in.re y
(re.* (re.++ (re.* (str.to.re "a") ) (str.to.re "b") ))))

(assert (not (= x y)))
(assert (= (str.len x) (str.len y)))

(check-sat)

=API=
More details can be found in the [http://cvc4.cs.nyu.edu/wiki/Tutorials Tutorials].

==C++==
The example can be found in [https://github.com/CVC4/CVC4/blob/master/examples/api/strings.cpp examples/api/strings.cpp].

If setting the logic, use "S" to enable theory of strings.
smt.setLogic("S");

To create a string type, call <code>mkSetType</code> in the <code>ExprManager</code>.
Type string = em.stringType();

Make some string literals:
// std::string
std::string std_str_ab("ab");
// CVC4::String
CVC4::String cvc4_str_ab(std_str_ab);
CVC4::String cvc4_str_abc("abc");
// String constants
Expr ab = em.mkConst(cvc4_str_ab);
Expr abc = em.mkConst(CVC4::String("abc"));

Make some string variables:
Expr x = em.mkVar("x", string);
Expr y = em.mkVar("y", string);
Expr z = em.mkVar("z", string);

Make some string constraints:
// String concatenation: x.ab.y
Expr lhs = em.mkExpr(kind::STRING_CONCAT, x, ab, y);
// String concatenation: abc.z
Expr rhs = em.mkExpr(kind::STRING_CONCAT, abc, z);
// x.ab.y = abc.z
Expr formula1 = em.mkExpr(kind::EQUAL, lhs, rhs);
// Length of y: |y|
Expr leny = em.mkExpr(kind::STRING_LENGTH, y);
// |y| >= 0
Expr formula2 = em.mkExpr(kind::GEQ, leny, em.mkConst(Rational(0)));
// Regular expression: (ab[c-e]*f)|g|h
Expr r = em.mkExpr(kind::REGEXP_UNION,
em.mkExpr(kind::REGEXP_CONCAT,
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("ab"))),
em.mkExpr(kind::REGEXP_STAR,
em.mkExpr(kind::REGEXP_RANGE, em.mkConst(String("c")), em.mkConst(String("e")))),
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("f")))),
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("g"))),
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("h"))));
// String variables
Expr s1 = em.mkVar("s1", string);
Expr s2 = em.mkVar("s2", string);
// String concatenation: s1.s2
Expr s = em.mkExpr(kind::STRING_CONCAT, s1, s2);
// s1.s2 in (ab[c-e]*f)|g|h
Expr formula3 = em.mkExpr(kind::STRING_IN_REGEXP, s, r);

Make a query:
Expr q = em.mkExpr(kind::AND,
formula1,
formula2,
formula3);

Check the result:
Result result = smt.checkSat(q);
std::cout << "CVC4 reports: " << q << " is " << result << "." << std::endl;
if(result == Result::SAT) {
std::cout << " x = " << smt.getValue(x) << std::endl;
std::cout << " s1.s2 = " << smt.getValue(s) << std::endl;
}

==Java==
The example can be found in [https://github.com/CVC4/CVC4/blob/master/examples/api/java/Strings.java examples/api/java/Strings.java].

=References=
* Tianyi Liang, Andrew Reynolds, Cesare Tinelli, Clark Barrett and Morgan Deters. [http://link.springer.com/chapter/10.1007%2F978-3-319-08867-9_43 A DPLL(T) Theory Solver for a Theory of Strings and Regular Expressions].In Proceedings of the 26th International Conference on Computer Aided Verification (CAV'14), Vienna, Austria, 2014.
* Tianyi Liang. [http://ir.uiowa.edu/etd/1478/ Automated reasoning over string constraints]. PhD Dissertation, Department of Computer Science, The University of Iowa, Dec 2014.

Strings

2015-06-09T22:00:34Z

Tinelli: /* Escape Sequences for Regular Expressions */

This page describes support for the theory of strings in CVC4.

=Syntax=
This document focuses on input written in SMT-LIB 2 format.
A frontend for CVC4's native syntax is not available yet.

'''We highly recommend that users use SMT-LIB [http://smt-lib.org/language.shtml Version 2.5],
instead of Version 2.0.'''
The major difference is in the definition of escape sequences for string literals.

'''The syntax below is for CVC4 version > 1.4.''' Version 1.3 has only
''partial'' support for syntax in this document.

Since the string (sub)solver is still relatively new, the current stable version
of CVC4 (1.4) does not provide the latest version of that solver.
Please use our latest Development version instead.

Currently, the string solver supports string constants over a set of characters
limited to the printable ASCII characters. Other characters ''must'' be encoded
with escape sequences.
For arbitry alphabets, we plan to provide later a separate solver
for a theory of parametric sequences.

To use the string solver it is important to declare initially
(using the <code>set-logic</code> command) an SMT-LIB logic that includes strings.
Since the SMT-LIB standard does not have an official theory of strings and
related logics yet, the logic names described below are tentive and
might change later.

The basic logic is <code>QF_S</code> consisting of quanfier-free formulas
over just the theory of strings, e.g.:
(set-logic QF_S)

If the formulas contain sybols from theories, please add them accordingly,
e.g., if the formulas contain symbols from the BitVector theory,
the logic symbol should be <code>QF_SBV</code>.

The logic consisting of the full (quantified) theory strings is
<code>QF_SBV</code>:
(set-logic S)

==Unsat Cores==
The string solver supports the generation of unsatisfiable cores.
As with other subsolvers though, you must enable proofs at configuration time,
and then run CVC with "--dump-unsat-cores" flag.

==Options==
Some functions in the theory are have only experimental support currently and
are disabled by default (even in the <code>ALL_SUPPORTED</code> logic:
To use them:
(set-option :strings-exp true)

The solver can be run in ''finite model finding mode'' which guarantees
termination for satisfiable problems.
This mode is disabled by default. To enable it:
(set-option :strings-fmf true)
Note that in this mode the solver is much '''slower''' than in default mode,
so we recommend it only as a fall back option when the default mode fails
to find a solution with a reasonably large timeout.

To select the strategy of LB rule application: 0-lazy, 1-eager, 2-no (0 by default):
(set-option :strings-lb 1)

To set up string alphabet cardinality (256 by default, expert option):
(set-option :strings-alphabet-card n)
This is a reserved option for the extension of the sequence theory.

==Alphabet==
Currently, the solver's theory is based on an alphabet consisting of the 256
characters from (8-bit) Extended ASCII.
Since there are several versions of Extended ASCII, we allow string constants
to contain only ''printable US ASCII characters'', which are encoded
in the same way in all Extended ASCII versions.

'''Note:''' The alphabet will change to the one prescribed by the SMT-LIB standard
once there is one.

==Printable Characters==
A ''printable'' character is any character with numerical value between 0x20 and 0x7e
in the standard US ASCII encoding.

==Escape Sequences for String Literals==
String constants are denoted by SMT-LIB string literals consisting of sequences of printable characters delimited by double-quotes (<code>"</code>).

We support escape sequences used in most programming languages
to represent non-printable characters.

{| border="1"
|-
| <code>\0</code> … <code>\9</code>
| represents ASCII character 0 … 9, respectively
|-
| <code>\a</code>, <code>\b</code>, <code>\e</code>, <code>\f</code>, <code>\n</code>, <code>\r</code>, <code>\t</code>, <code>\v</code>
| represents its corresponding ASCII character (C++ convention)
|-
| <code>\</code>''ooo''
| encodes a single ASCII character where ''ooo'' consists of exactly three digits in the octal encoding of the character (from 0 to 377). For example, <code>\101</code> represents <code>A</code>. '''Note:''' going beyond value 377 might give unexpected results. For instance, <code>\437</code> will be translated in the two-character string <code>#7</code>.
|-
| <code>\x</code>''NN''
| encodes a single ASCII character, where ''NN'' consists of exactly two digits in the exadecimal encoding of the character.
|}

The backslash character (<code>\</code>) is silently ignored when it is followed by a sequence of characters not recognized as an escape sequence. For example, <code>\$ </code>, say, is parsed as if it was just <code>$</code>.

When CVC4 outputs a string constant, a non-printable/extended ASCII character is printed in the exadecimal format <code>\x</code>''NN'', except for the character denoted by the escape sequences <code>\a</code>, <code>\b</code>, <code>\e</code>, <code>\f</code>, <code>\n</code>, <code>\r</code>, <code>\t</code>, <code>\v</code>, which are printed using those escape sequences.

'''Note''':
These escape sequences are specific to string constants in the theory of strings. They are 'not' escape sequences in SMT-LIB 2 per se.
SMT-LIB 2.5 has only one escape sequence for string literals: <code>""</code>,
which denotes the double quotes character.
This means that a string literal like <code>"a""c"</code> is read by the solver as the string constant consisting of the characters <code>a</code>, <code>"</code>, and <code>c</code>.
The same constant can be entered as <code>"a\042c"</code> or <code>"a\x22c"</code>.

==Theory Signature==
To define a string variable, i.e., a free string constant:
(declare-fun x () String)
Alternatively:
(declare-const x () String)

String Concatenation:
(str.++ s1 s2 ... sn)
where s1, s2, ..., and sn are string terms. String concatenation takes at least 2 arguments.

String Length:
(str.len s)
where s is a string term.

Character in String:
(str.at s i)
where s is a string term and i is a natural number. (see partial functions)
The index is starting from 0.

Sub-String:
(str.substr s i j )
where s is a string term, i and j are natural numbers. (see partial functions)

==Escape Sequences for Regular Expressions==
Currently, it is for CVC format only. (Coming soon.)

==Symbolic Regular Expression==
Membership Constraint:
(str.in.re s r)
where s is a string term and r is a regular expression.

String to Regular Expression Conversion:
(str.to.re s)
where s is a string term. The statement turns a regular expression that only contains a string s.

Regular Expression Concatenation:
(re.++ r_1 r_2 ... r_n)
where r_1, r_2, ..., r_n are regular expressions.

Regular Expression Alternation:
(re.union r_1 r_2 ... r_n)
where r_1, r_2, ..., r_n are regular expressions. re.or is for releases before March, 2014.

Regular Expression Intersection:
(re.inter r_1 r_2 ... r_n)
where r_1, r_2, ..., r_n are regular expressions. re.itr is for releases before March, 2014.

Regular Expression Kleene-Star:
(re.* r)
where r is a regular expression.

Regular Expression Kleene-Cross:
(re.+ r)
where r is a regular expression.

Regular Expression Option:
(re.opt r)
where r is a regular expression.

Regular Expression Range:
(re.range s t)
where s, t are single characters in double quotes, e.g. "a", "b".
It returns a regular expression that contains any character between s and t.

Regular Expression Loop:
(re.loop r l u)
where r is a regular expression, l is a non-negative constant integer, and u is a non-negative constant integer.
It returns a regular expression that contains at least l repetitions of r and at most u repetitions of r.
If l >= u, it returns exactly l repetitions of r.

Regular Expression Loop-2:
(re.loop r l)
where r is a regular expression, and l is a non-negative constant integer.
It returns a regular expression that contains at least l repetitions of r.

The Empty Regular Expression:
re.nostr

The Regular Expression that contains all characters:
re.allchar

==Experimental Mode==
Following functions are under the --strings-exp option. They are under active refinement. Once they are stable, we will move them to the default mode. Please let us know when you have some suggestions.

String Char-At:
(str.at s i)
where s is a string term and i is an integer term. i is the position. See partial functions section.

String Sub-string:
(str.substr s i j)
where s is a string term and i, j are integer terms. i is the starting position, and j is the offset. See partial functions section.

String Contain:
(str.contains s t)
where s and t are string terms. It returns true if the string s contains the string t.
This function determines whether the string t can be found within the string s, returning true or false as appropriate.

String IndexOf:
(str.indexof s t i)
where s is a string, t is a non-empty string and i is a non-negative integer.
This function returns the position of the first occurrence of the specified value t in the string s after the index i.
It returns -1 if the value to search for never occurs.

String Replacement:
(str.replace s t1 t2)
where s, t1 and t2 are string terms, t1 is non-empty.
This function searches the string s for the specified value t1, and returns a new string where the first occurrence of the specified value t1 is replaced by the string t2.

String PrefixOf:
(str.prefixof s t)
where s and t are string terms. It returns true if the string s is a prefix of the string t.

String SuffixOf:
(str.suffixof s t)
where s and t are string terms. It returns true if the string s is a suffix of the string t.

String To Integer Conversion:
(str.to.int s)
where s is a string term. It returns the corresponding natural number if s is valid; otherwise, it returns -1.

Integer To String Conversion:
(int.to.str i)
where i is an integer term. It returns the corresponding string if i is a natural number; otherwise, it returns an empty string.

=Partial Functions=
By the definition of partial functions in [http://www.smtlib.org/ SMT-Lib Document], the following constraint is satisfiable:
(assert (= (str.substr "a" 2 10) "b"))
However, the following constraints are unsatisfiable:
(assert (= (str.substr "a" 2 1) "b"))
(assert (= (str.substr "a" 2 1) "c"))
To achieve a desirable goal, it requires users to guard proper conditions. For example,
(assert (= (str.at x j) "b"))
(assert (> j 0))
(assert (> (str.len x) j))

=Extension=
Together with other engine in CVC4, we can extend new functionality in the theory of strings. For example,
(define-fun fun1 ((?x String) (?s String)) Bool
(or (= ?x ?s)
(> (str.len ?x) (str.len ?s))
))
Quantifiers over bounded Integers (with strings in the body) are supported in the experimental mode; however, quantifiers over strings are still under development.

=Limitation=
The decidability of this theory is unknown.
For satisfiable problems (without extensions), our solver is sound, complete and terminating in the FMF mode (although the FMF mode will be slower than the default mode in general). For unsatisfiable problems, the termination is not guaranteed; however, user can tune the options for termination.

Current version supports ASCII characters only. We will move on to UNICODE in the future version.

=Examples=
Find an assignment for x, where x."ab"="ba".x and the length of x equals to 7.
(set-logic QF_S)

(declare-fun x () String)

(assert (= (str.++ x "ab") (str.++ "ba" x)))
(assert (= (str.len x) 7))

(check-sat)

Find assignments for x and y, where x and y are distinct and their lengths are equal.
(set-logic QF_S)

(declare-fun x () String)
(declare-fun y () String)

(assert (not (= x y)))
(assert (= (str.len x) (str.len y)))

(check-sat)

Find assignments for x and y, where x.y != y.x.
(set-logic QF_S)

(declare-fun x () String)
(declare-fun y () String)
(assert (not (= (str.++ x y) (str.++ y x))))

(check-sat)

Find a model for x, y and z, where x."ab".y=y."ba".z and z=x.y and x."a"!="a".x.
(set-logic QF_S)

(declare-fun x () String)
(declare-fun y () String)
(declare-fun z () String)

(assert (= (str.++ x "ab" y) (str.++ y "ba" z)))
(assert (= z (str.++ x y)))
(assert (not (= (str.++ x "a") (str.++ "a" x))))

(check-sat)

Find a model for x and y, where both x and y are in the RegEx (a*b)* and they are different but have the same length.
(set-logic QF_S)
(set-option :strings-fmf true)

(declare-fun x () String)
(declare-fun y () String)

(assert
(str.in.re x
(re.* (re.++ (re.* (str.to.re "a") ) (str.to.re "b") ))))
(assert (str.in.re y
(re.* (re.++ (re.* (str.to.re "a") ) (str.to.re "b") ))))

(assert (not (= x y)))
(assert (= (str.len x) (str.len y)))

(check-sat)

=API=
More details can be found in the [http://cvc4.cs.nyu.edu/wiki/Tutorials Tutorials].

==C++==
The example can be found in [https://github.com/CVC4/CVC4/blob/master/examples/api/strings.cpp examples/api/strings.cpp].

If setting the logic, use "S" to enable theory of strings.
smt.setLogic("S");

To create a string type, call <code>mkSetType</code> in the <code>ExprManager</code>.
Type string = em.stringType();

Make some string literals:
// std::string
std::string std_str_ab("ab");
// CVC4::String
CVC4::String cvc4_str_ab(std_str_ab);
CVC4::String cvc4_str_abc("abc");
// String constants
Expr ab = em.mkConst(cvc4_str_ab);
Expr abc = em.mkConst(CVC4::String("abc"));

Make some string variables:
Expr x = em.mkVar("x", string);
Expr y = em.mkVar("y", string);
Expr z = em.mkVar("z", string);

Make some string constraints:
// String concatenation: x.ab.y
Expr lhs = em.mkExpr(kind::STRING_CONCAT, x, ab, y);
// String concatenation: abc.z
Expr rhs = em.mkExpr(kind::STRING_CONCAT, abc, z);
// x.ab.y = abc.z
Expr formula1 = em.mkExpr(kind::EQUAL, lhs, rhs);
// Length of y: |y|
Expr leny = em.mkExpr(kind::STRING_LENGTH, y);
// |y| >= 0
Expr formula2 = em.mkExpr(kind::GEQ, leny, em.mkConst(Rational(0)));
// Regular expression: (ab[c-e]*f)|g|h
Expr r = em.mkExpr(kind::REGEXP_UNION,
em.mkExpr(kind::REGEXP_CONCAT,
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("ab"))),
em.mkExpr(kind::REGEXP_STAR,
em.mkExpr(kind::REGEXP_RANGE, em.mkConst(String("c")), em.mkConst(String("e")))),
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("f")))),
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("g"))),
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("h"))));
// String variables
Expr s1 = em.mkVar("s1", string);
Expr s2 = em.mkVar("s2", string);
// String concatenation: s1.s2
Expr s = em.mkExpr(kind::STRING_CONCAT, s1, s2);
// s1.s2 in (ab[c-e]*f)|g|h
Expr formula3 = em.mkExpr(kind::STRING_IN_REGEXP, s, r);

Make a query:
Expr q = em.mkExpr(kind::AND,
formula1,
formula2,
formula3);

Check the result:
Result result = smt.checkSat(q);
std::cout << "CVC4 reports: " << q << " is " << result << "." << std::endl;
if(result == Result::SAT) {
std::cout << " x = " << smt.getValue(x) << std::endl;
std::cout << " s1.s2 = " << smt.getValue(s) << std::endl;
}

==Java==
The example can be found in [https://github.com/CVC4/CVC4/blob/master/examples/api/java/Strings.java examples/api/java/Strings.java].

=References=
* Tianyi Liang, Andrew Reynolds, Cesare Tinelli, Clark Barrett and Morgan Deters. [http://link.springer.com/chapter/10.1007%2F978-3-319-08867-9_43 A DPLL(T) Theory Solver for a Theory of Strings and Regular Expressions].In Proceedings of the 26th International Conference on Computer Aided Verification (CAV'14), Vienna, Austria, 2014.
* Tianyi Liang. [http://ir.uiowa.edu/etd/1478/ Automated reasoning over string constraints]. PhD Dissertation, Department of Computer Science, The University of Iowa, Dec 2014.

Strings

2015-06-09T21:59:30Z

Tinelli: /* Theory Signature */

This page describes support for the theory of strings in CVC4.

=Syntax=
This document focuses on input written in SMT-LIB 2 format.
A frontend for CVC4's native syntax is not available yet.

'''We highly recommend that users use SMT-LIB [http://smt-lib.org/language.shtml Version 2.5],
instead of Version 2.0.'''
The major difference is in the definition of escape sequences for string literals.

'''The syntax below is for CVC4 version > 1.4.''' Version 1.3 has only
''partial'' support for syntax in this document.

Since the string (sub)solver is still relatively new, the current stable version
of CVC4 (1.4) does not provide the latest version of that solver.
Please use our latest Development version instead.

Currently, the string solver supports string constants over a set of characters
limited to the printable ASCII characters. Other characters ''must'' be encoded
with escape sequences.
For arbitry alphabets, we plan to provide later a separate solver
for a theory of parametric sequences.

To use the string solver it is important to declare initially
(using the <code>set-logic</code> command) an SMT-LIB logic that includes strings.
Since the SMT-LIB standard does not have an official theory of strings and
related logics yet, the logic names described below are tentive and
might change later.

The basic logic is <code>QF_S</code> consisting of quanfier-free formulas
over just the theory of strings, e.g.:
(set-logic QF_S)

If the formulas contain sybols from theories, please add them accordingly,
e.g., if the formulas contain symbols from the BitVector theory,
the logic symbol should be <code>QF_SBV</code>.

The logic consisting of the full (quantified) theory strings is
<code>QF_SBV</code>:
(set-logic S)

==Unsat Cores==
The string solver supports the generation of unsatisfiable cores.
As with other subsolvers though, you must enable proofs at configuration time,
and then run CVC with "--dump-unsat-cores" flag.

==Options==
Some functions in the theory are have only experimental support currently and
are disabled by default (even in the <code>ALL_SUPPORTED</code> logic:
To use them:
(set-option :strings-exp true)

The solver can be run in ''finite model finding mode'' which guarantees
termination for satisfiable problems.
This mode is disabled by default. To enable it:
(set-option :strings-fmf true)
Note that in this mode the solver is much '''slower''' than in default mode,
so we recommend it only as a fall back option when the default mode fails
to find a solution with a reasonably large timeout.

To select the strategy of LB rule application: 0-lazy, 1-eager, 2-no (0 by default):
(set-option :strings-lb 1)

To set up string alphabet cardinality (256 by default, expert option):
(set-option :strings-alphabet-card n)
This is a reserved option for the extension of the sequence theory.

==Alphabet==
Currently, the solver's theory is based on an alphabet consisting of the 256
characters from (8-bit) Extended ASCII.
Since there are several versions of Extended ASCII, we allow string constants
to contain only ''printable US ASCII characters'', which are encoded
in the same way in all Extended ASCII versions.

'''Note:''' The alphabet will change to the one prescribed by the SMT-LIB standard
once there is one.

==Printable Characters==
A ''printable'' character is any character with numerical value between 0x20 and 0x7e
in the standard US ASCII encoding.

==Escape Sequences for String Literals==
String constants are denoted by SMT-LIB string literals consisting of sequences of printable characters delimited by double-quotes (<code>"</code>).

We support escape sequences used in most programming languages
to represent non-printable characters.

{| border="1"
|-
| <code>\0</code> … <code>\9</code>
| represents ASCII character 0 … 9, respectively
|-
| <code>\a</code>, <code>\b</code>, <code>\e</code>, <code>\f</code>, <code>\n</code>, <code>\r</code>, <code>\t</code>, <code>\v</code>
| represents its corresponding ASCII character (C++ convention)
|-
| <code>\</code>''ooo''
| encodes a single ASCII character where ''ooo'' consists of exactly three digits in the octal encoding of the character (from 0 to 377). For example, <code>\101</code> represents <code>A</code>. '''Note:''' going beyond value 377 might give unexpected results. For instance, <code>\437</code> will be translated in the two-character string <code>#7</code>.
|-
| <code>\x</code>''NN''
| encodes a single ASCII character, where ''NN'' consists of exactly two digits in the exadecimal encoding of the character.
|}

The backslash character (<code>\</code>) is silently ignored when it is followed by a sequence of characters not recognized as an escape sequence. For example, <code>\$ </code>, say, is parsed as if it was just <code>$</code>.

When CVC4 outputs a string constant, a non-printable/extended ASCII character is printed in the exadecimal format <code>\x</code>''NN'', except for the character denoted by the escape sequences <code>\a</code>, <code>\b</code>, <code>\e</code>, <code>\f</code>, <code>\n</code>, <code>\r</code>, <code>\t</code>, <code>\v</code>, which are printed using those escape sequences.

'''Note''':
These escape sequences are specific to string constants in the theory of strings. They are 'not' escape sequences in SMT-LIB 2 per se.
SMT-LIB 2.5 has only one escape sequence for string literals: <code>""</code>,
which denotes the double quotes character.
This means that a string literal like <code>"a""c"</code> is read by the solver as the string constant consisting of the characters <code>a</code>, <code>"</code>, and <code>c</code>.
The same constant can be entered as <code>"a\042c"</code> or <code>"a\x22c"</code>.

==Theory Signature==
To define a string variable, i.e., a free string constant:
(declare-fun x () String)
Alternatively:
(declare-const x () String)

String Concatenation:
(str.++ s1 s2 ... sn)
where s1, s2, ..., and sn are string terms. String concatenation takes at least 2 arguments.

String Length:
(str.len s)
where s is a string term.

Character in String:
(str.at s i)
where s is a string term and i is a natural number. (see partial functions)
The index is starting from 0.

Sub-String:
(str.substr s i j )
where s is a string term, i and j are natural numbers. (see partial functions)

==Escape Sequences for Regular Expressions==
Currently, it is for CVC format only. (coming soon)

==Symbolic Regular Expression==
Membership Constraint:
(str.in.re s r)
where s is a string term and r is a regular expression.

String to Regular Expression Conversion:
(str.to.re s)
where s is a string term. The statement turns a regular expression that only contains a string s.

Regular Expression Concatenation:
(re.++ r_1 r_2 ... r_n)
where r_1, r_2, ..., r_n are regular expressions.

Regular Expression Alternation:
(re.union r_1 r_2 ... r_n)
where r_1, r_2, ..., r_n are regular expressions. re.or is for releases before March, 2014.

Regular Expression Intersection:
(re.inter r_1 r_2 ... r_n)
where r_1, r_2, ..., r_n are regular expressions. re.itr is for releases before March, 2014.

Regular Expression Kleene-Star:
(re.* r)
where r is a regular expression.

Regular Expression Kleene-Cross:
(re.+ r)
where r is a regular expression.

Regular Expression Option:
(re.opt r)
where r is a regular expression.

Regular Expression Range:
(re.range s t)
where s, t are single characters in double quotes, e.g. "a", "b".
It returns a regular expression that contains any character between s and t.

Regular Expression Loop:
(re.loop r l u)
where r is a regular expression, l is a non-negative constant integer, and u is a non-negative constant integer.
It returns a regular expression that contains at least l repetitions of r and at most u repetitions of r.
If l >= u, it returns exactly l repetitions of r.

Regular Expression Loop-2:
(re.loop r l)
where r is a regular expression, and l is a non-negative constant integer.
It returns a regular expression that contains at least l repetitions of r.

The Empty Regular Expression:
re.nostr

The Regular Expression that contains all characters:
re.allchar

==Experimental Mode==
Following functions are under the --strings-exp option. They are under active refinement. Once they are stable, we will move them to the default mode. Please let us know when you have some suggestions.

String Char-At:
(str.at s i)
where s is a string term and i is an integer term. i is the position. See partial functions section.

String Sub-string:
(str.substr s i j)
where s is a string term and i, j are integer terms. i is the starting position, and j is the offset. See partial functions section.

String Contain:
(str.contains s t)
where s and t are string terms. It returns true if the string s contains the string t.
This function determines whether the string t can be found within the string s, returning true or false as appropriate.

String IndexOf:
(str.indexof s t i)
where s is a string, t is a non-empty string and i is a non-negative integer.
This function returns the position of the first occurrence of the specified value t in the string s after the index i.
It returns -1 if the value to search for never occurs.

String Replacement:
(str.replace s t1 t2)
where s, t1 and t2 are string terms, t1 is non-empty.
This function searches the string s for the specified value t1, and returns a new string where the first occurrence of the specified value t1 is replaced by the string t2.

String PrefixOf:
(str.prefixof s t)
where s and t are string terms. It returns true if the string s is a prefix of the string t.

String SuffixOf:
(str.suffixof s t)
where s and t are string terms. It returns true if the string s is a suffix of the string t.

String To Integer Conversion:
(str.to.int s)
where s is a string term. It returns the corresponding natural number if s is valid; otherwise, it returns -1.

Integer To String Conversion:
(int.to.str i)
where i is an integer term. It returns the corresponding string if i is a natural number; otherwise, it returns an empty string.

=Partial Functions=
By the definition of partial functions in [http://www.smtlib.org/ SMT-Lib Document], the following constraint is satisfiable:
(assert (= (str.substr "a" 2 10) "b"))
However, the following constraints are unsatisfiable:
(assert (= (str.substr "a" 2 1) "b"))
(assert (= (str.substr "a" 2 1) "c"))
To achieve a desirable goal, it requires users to guard proper conditions. For example,
(assert (= (str.at x j) "b"))
(assert (> j 0))
(assert (> (str.len x) j))

=Extension=
Together with other engine in CVC4, we can extend new functionality in the theory of strings. For example,
(define-fun fun1 ((?x String) (?s String)) Bool
(or (= ?x ?s)
(> (str.len ?x) (str.len ?s))
))
Quantifiers over bounded Integers (with strings in the body) are supported in the experimental mode; however, quantifiers over strings are still under development.

=Limitation=
The decidability of this theory is unknown.
For satisfiable problems (without extensions), our solver is sound, complete and terminating in the FMF mode (although the FMF mode will be slower than the default mode in general). For unsatisfiable problems, the termination is not guaranteed; however, user can tune the options for termination.

Current version supports ASCII characters only. We will move on to UNICODE in the future version.

=Examples=
Find an assignment for x, where x."ab"="ba".x and the length of x equals to 7.
(set-logic QF_S)

(declare-fun x () String)

(assert (= (str.++ x "ab") (str.++ "ba" x)))
(assert (= (str.len x) 7))

(check-sat)

Find assignments for x and y, where x and y are distinct and their lengths are equal.
(set-logic QF_S)

(declare-fun x () String)
(declare-fun y () String)

(assert (not (= x y)))
(assert (= (str.len x) (str.len y)))

(check-sat)

Find assignments for x and y, where x.y != y.x.
(set-logic QF_S)

(declare-fun x () String)
(declare-fun y () String)
(assert (not (= (str.++ x y) (str.++ y x))))

(check-sat)

Find a model for x, y and z, where x."ab".y=y."ba".z and z=x.y and x."a"!="a".x.
(set-logic QF_S)

(declare-fun x () String)
(declare-fun y () String)
(declare-fun z () String)

(assert (= (str.++ x "ab" y) (str.++ y "ba" z)))
(assert (= z (str.++ x y)))
(assert (not (= (str.++ x "a") (str.++ "a" x))))

(check-sat)

Find a model for x and y, where both x and y are in the RegEx (a*b)* and they are different but have the same length.
(set-logic QF_S)
(set-option :strings-fmf true)

(declare-fun x () String)
(declare-fun y () String)

(assert
(str.in.re x
(re.* (re.++ (re.* (str.to.re "a") ) (str.to.re "b") ))))
(assert (str.in.re y
(re.* (re.++ (re.* (str.to.re "a") ) (str.to.re "b") ))))

(assert (not (= x y)))
(assert (= (str.len x) (str.len y)))

(check-sat)

=API=
More details can be found in the [http://cvc4.cs.nyu.edu/wiki/Tutorials Tutorials].

==C++==
The example can be found in [https://github.com/CVC4/CVC4/blob/master/examples/api/strings.cpp examples/api/strings.cpp].

If setting the logic, use "S" to enable theory of strings.
smt.setLogic("S");

To create a string type, call <code>mkSetType</code> in the <code>ExprManager</code>.
Type string = em.stringType();

Make some string literals:
// std::string
std::string std_str_ab("ab");
// CVC4::String
CVC4::String cvc4_str_ab(std_str_ab);
CVC4::String cvc4_str_abc("abc");
// String constants
Expr ab = em.mkConst(cvc4_str_ab);
Expr abc = em.mkConst(CVC4::String("abc"));

Make some string variables:
Expr x = em.mkVar("x", string);
Expr y = em.mkVar("y", string);
Expr z = em.mkVar("z", string);

Make some string constraints:
// String concatenation: x.ab.y
Expr lhs = em.mkExpr(kind::STRING_CONCAT, x, ab, y);
// String concatenation: abc.z
Expr rhs = em.mkExpr(kind::STRING_CONCAT, abc, z);
// x.ab.y = abc.z
Expr formula1 = em.mkExpr(kind::EQUAL, lhs, rhs);
// Length of y: |y|
Expr leny = em.mkExpr(kind::STRING_LENGTH, y);
// |y| >= 0
Expr formula2 = em.mkExpr(kind::GEQ, leny, em.mkConst(Rational(0)));
// Regular expression: (ab[c-e]*f)|g|h
Expr r = em.mkExpr(kind::REGEXP_UNION,
em.mkExpr(kind::REGEXP_CONCAT,
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("ab"))),
em.mkExpr(kind::REGEXP_STAR,
em.mkExpr(kind::REGEXP_RANGE, em.mkConst(String("c")), em.mkConst(String("e")))),
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("f")))),
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("g"))),
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("h"))));
// String variables
Expr s1 = em.mkVar("s1", string);
Expr s2 = em.mkVar("s2", string);
// String concatenation: s1.s2
Expr s = em.mkExpr(kind::STRING_CONCAT, s1, s2);
// s1.s2 in (ab[c-e]*f)|g|h
Expr formula3 = em.mkExpr(kind::STRING_IN_REGEXP, s, r);

Make a query:
Expr q = em.mkExpr(kind::AND,
formula1,
formula2,
formula3);

Check the result:
Result result = smt.checkSat(q);
std::cout << "CVC4 reports: " << q << " is " << result << "." << std::endl;
if(result == Result::SAT) {
std::cout << " x = " << smt.getValue(x) << std::endl;
std::cout << " s1.s2 = " << smt.getValue(s) << std::endl;
}

==Java==
The example can be found in [https://github.com/CVC4/CVC4/blob/master/examples/api/java/Strings.java examples/api/java/Strings.java].

=References=
* Tianyi Liang, Andrew Reynolds, Cesare Tinelli, Clark Barrett and Morgan Deters. [http://link.springer.com/chapter/10.1007%2F978-3-319-08867-9_43 A DPLL(T) Theory Solver for a Theory of Strings and Regular Expressions].In Proceedings of the 26th International Conference on Computer Aided Verification (CAV'14), Vienna, Austria, 2014.
* Tianyi Liang. [http://ir.uiowa.edu/etd/1478/ Automated reasoning over string constraints]. PhD Dissertation, Department of Computer Science, The University of Iowa, Dec 2014.

Strings

2015-06-09T21:49:40Z

Tinelli:

This page describes support for the theory of strings in CVC4.

=Syntax=
This document focuses on input written in SMT-LIB 2 format.
A frontend for CVC4's native syntax is not available yet.

'''We highly recommend that users use SMT-LIB [http://smt-lib.org/language.shtml Version 2.5],
instead of Version 2.0.'''
The major difference is in the definition of escape sequences for string literals.

'''The syntax below is for CVC4 version > 1.4.''' Version 1.3 has only
''partial'' support for syntax in this document.

Since the string (sub)solver is still relatively new, the current stable version
of CVC4 (1.4) does not provide the latest version of that solver.
Please use our latest Development version instead.

Currently, the string solver supports string constants over a set of characters
limited to the printable ASCII characters. Other characters ''must'' be encoded
with escape sequences.
For arbitry alphabets, we plan to provide later a separate solver
for a theory of parametric sequences.

To use the string solver it is important to declare initially
(using the <code>set-logic</code> command) an SMT-LIB logic that includes strings.
Since the SMT-LIB standard does not have an official theory of strings and
related logics yet, the logic names described below are tentive and
might change later.

The basic logic is <code>QF_S</code> consisting of quanfier-free formulas
over just the theory of strings, e.g.:
(set-logic QF_S)

If the formulas contain sybols from theories, please add them accordingly,
e.g., if the formulas contain symbols from the BitVector theory,
the logic symbol should be <code>QF_SBV</code>.

The logic consisting of the full (quantified) theory strings is
<code>QF_SBV</code>:
(set-logic S)

==Unsat Cores==
The string solver supports the generation of unsatisfiable cores.
As with other subsolvers though, you must enable proofs at configuration time,
and then run CVC with "--dump-unsat-cores" flag.

==Options==
Some functions in the theory are have only experimental support currently and
are disabled by default (even in the <code>ALL_SUPPORTED</code> logic:
To use them:
(set-option :strings-exp true)

The solver can be run in ''finite model finding mode'' which guarantees
termination for satisfiable problems.
This mode is disabled by default. To enable it:
(set-option :strings-fmf true)
Note that in this mode the solver is much '''slower''' than in default mode,
so we recommend it only as a fall back option when the default mode fails
to find a solution with a reasonably large timeout.

To select the strategy of LB rule application: 0-lazy, 1-eager, 2-no (0 by default):
(set-option :strings-lb 1)

To set up string alphabet cardinality (256 by default, expert option):
(set-option :strings-alphabet-card n)
This is a reserved option for the extension of the sequence theory.

==Alphabet==
Currently, the solver's theory is based on an alphabet consisting of the 256
characters from (8-bit) Extended ASCII.
Since there are several versions of Extended ASCII, we allow string constants
to contain only ''printable US ASCII characters'', which are encoded
in the same way in all Extended ASCII versions.

'''Note:''' The alphabet will change to the one prescribed by the SMT-LIB standard
once there is one.

==Printable Characters==
A ''printable'' character is any character with numerical value between 0x20 and 0x7e
in the standard US ASCII encoding.

==Escape Sequences for String Literals==
String constants are denoted by SMT-LIB string literals consisting of sequences of printable characters delimited by double-quotes (<code>"</code>).

We support escape sequences used in most programming languages
to represent non-printable characters.

{| border="1"
|-
| <code>\0</code> … <code>\9</code>
| represents ASCII character 0 … 9, respectively
|-
| <code>\a</code>, <code>\b</code>, <code>\e</code>, <code>\f</code>, <code>\n</code>, <code>\r</code>, <code>\t</code>, <code>\v</code>
| represents its corresponding ASCII character (C++ convention)
|-
| <code>\</code>''ooo''
| encodes a single ASCII character where ''ooo'' consists of exactly three digits in the octal encoding of the character (from 0 to 377). For example, <code>\101</code> represents <code>A</code>. '''Note:''' going beyond value 377 might give unexpected results. For instance, <code>\437</code> will be translated in the two-character string <code>#7</code>.
|-
| <code>\x</code>''NN''
| encodes a single ASCII character, where ''NN'' consists of exactly two digits in the exadecimal encoding of the character.
|}

The backslash character (<code>\</code>) is silently ignored when it is followed by a sequence of characters not recognized as an escape sequence. For example, <code>\$ </code>, say, is parsed as if it was just <code>$</code>.

When CVC4 outputs a string constant, a non-printable/extended ASCII character is printed in the exadecimal format <code>\x</code>''NN'', except for the character denoted by the escape sequences <code>\a</code>, <code>\b</code>, <code>\e</code>, <code>\f</code>, <code>\n</code>, <code>\r</code>, <code>\t</code>, <code>\v</code>, which are printed using those escape sequences.

'''Note''':
These escape sequences are specific to string constants in the theory of strings. They are 'not' escape sequences in SMT-LIB 2 per se.
SMT-LIB 2.5 has only one escape sequence for string literals: <code>""</code>,
which denotes the double quotes character.
This means that a string literal like <code>"a""c"</code> is read by the solver as the string constant consisting of the characters <code>a</code>, <code>"</code>, and <code>c</code>.
The same constant can be entered as <code>"a\042c"</code> or <code>"a\x22c"</code>.

==Theory Signature==
To define a string variable:
(declare-fun x () String)

String Concatenation:
(str.++ s1 s2 ... sn)
where s1, s2, ..., and sn are string terms. String concatenation takes at least 2 arguments.

String Length:
(str.len s)
where s is a string term.

Character in String:
(str.at s i)
where s is a string term and i is a natural number. (see partial functions)
The index is starting from 0.

Sub-String:
(str.substr s i j )
where s is a string term, i and j are natural numbers. (see partial functions)

==Escape Sequences for Regular Expressions==
Currently, it is for CVC format only. (coming soon)

==Symbolic Regular Expression==
Membership Constraint:
(str.in.re s r)
where s is a string term and r is a regular expression.

String to Regular Expression Conversion:
(str.to.re s)
where s is a string term. The statement turns a regular expression that only contains a string s.

Regular Expression Concatenation:
(re.++ r_1 r_2 ... r_n)
where r_1, r_2, ..., r_n are regular expressions.

Regular Expression Alternation:
(re.union r_1 r_2 ... r_n)
where r_1, r_2, ..., r_n are regular expressions. re.or is for releases before March, 2014.

Regular Expression Intersection:
(re.inter r_1 r_2 ... r_n)
where r_1, r_2, ..., r_n are regular expressions. re.itr is for releases before March, 2014.

Regular Expression Kleene-Star:
(re.* r)
where r is a regular expression.

Regular Expression Kleene-Cross:
(re.+ r)
where r is a regular expression.

Regular Expression Option:
(re.opt r)
where r is a regular expression.

Regular Expression Range:
(re.range s t)
where s, t are single characters in double quotes, e.g. "a", "b".
It returns a regular expression that contains any character between s and t.

Regular Expression Loop:
(re.loop r l u)
where r is a regular expression, l is a non-negative constant integer, and u is a non-negative constant integer.
It returns a regular expression that contains at least l repetitions of r and at most u repetitions of r.
If l >= u, it returns exactly l repetitions of r.

Regular Expression Loop-2:
(re.loop r l)
where r is a regular expression, and l is a non-negative constant integer.
It returns a regular expression that contains at least l repetitions of r.

The Empty Regular Expression:
re.nostr

The Regular Expression that contains all characters:
re.allchar

==Experimental Mode==
Following functions are under the --strings-exp option. They are under active refinement. Once they are stable, we will move them to the default mode. Please let us know when you have some suggestions.

String Char-At:
(str.at s i)
where s is a string term and i is an integer term. i is the position. See partial functions section.

String Sub-string:
(str.substr s i j)
where s is a string term and i, j are integer terms. i is the starting position, and j is the offset. See partial functions section.

String Contain:
(str.contains s t)
where s and t are string terms. It returns true if the string s contains the string t.
This function determines whether the string t can be found within the string s, returning true or false as appropriate.

String IndexOf:
(str.indexof s t i)
where s is a string, t is a non-empty string and i is a non-negative integer.
This function returns the position of the first occurrence of the specified value t in the string s after the index i.
It returns -1 if the value to search for never occurs.

String Replacement:
(str.replace s t1 t2)
where s, t1 and t2 are string terms, t1 is non-empty.
This function searches the string s for the specified value t1, and returns a new string where the first occurrence of the specified value t1 is replaced by the string t2.

String PrefixOf:
(str.prefixof s t)
where s and t are string terms. It returns true if the string s is a prefix of the string t.

String SuffixOf:
(str.suffixof s t)
where s and t are string terms. It returns true if the string s is a suffix of the string t.

String To Integer Conversion:
(str.to.int s)
where s is a string term. It returns the corresponding natural number if s is valid; otherwise, it returns -1.

Integer To String Conversion:
(int.to.str i)
where i is an integer term. It returns the corresponding string if i is a natural number; otherwise, it returns an empty string.

=Partial Functions=
By the definition of partial functions in [http://www.smtlib.org/ SMT-Lib Document], the following constraint is satisfiable:
(assert (= (str.substr "a" 2 10) "b"))
However, the following constraints are unsatisfiable:
(assert (= (str.substr "a" 2 1) "b"))
(assert (= (str.substr "a" 2 1) "c"))
To achieve a desirable goal, it requires users to guard proper conditions. For example,
(assert (= (str.at x j) "b"))
(assert (> j 0))
(assert (> (str.len x) j))

=Extension=
Together with other engine in CVC4, we can extend new functionality in the theory of strings. For example,
(define-fun fun1 ((?x String) (?s String)) Bool
(or (= ?x ?s)
(> (str.len ?x) (str.len ?s))
))
Quantifiers over bounded Integers (with strings in the body) are supported in the experimental mode; however, quantifiers over strings are still under development.

=Limitation=
The decidability of this theory is unknown.
For satisfiable problems (without extensions), our solver is sound, complete and terminating in the FMF mode (although the FMF mode will be slower than the default mode in general). For unsatisfiable problems, the termination is not guaranteed; however, user can tune the options for termination.

Current version supports ASCII characters only. We will move on to UNICODE in the future version.

=Examples=
Find an assignment for x, where x."ab"="ba".x and the length of x equals to 7.
(set-logic QF_S)

(declare-fun x () String)

(assert (= (str.++ x "ab") (str.++ "ba" x)))
(assert (= (str.len x) 7))

(check-sat)

Find assignments for x and y, where x and y are distinct and their lengths are equal.
(set-logic QF_S)

(declare-fun x () String)
(declare-fun y () String)

(assert (not (= x y)))
(assert (= (str.len x) (str.len y)))

(check-sat)

Find assignments for x and y, where x.y != y.x.
(set-logic QF_S)

(declare-fun x () String)
(declare-fun y () String)
(assert (not (= (str.++ x y) (str.++ y x))))

(check-sat)

Find a model for x, y and z, where x."ab".y=y."ba".z and z=x.y and x."a"!="a".x.
(set-logic QF_S)

(declare-fun x () String)
(declare-fun y () String)
(declare-fun z () String)

(assert (= (str.++ x "ab" y) (str.++ y "ba" z)))
(assert (= z (str.++ x y)))
(assert (not (= (str.++ x "a") (str.++ "a" x))))

(check-sat)

Find a model for x and y, where both x and y are in the RegEx (a*b)* and they are different but have the same length.
(set-logic QF_S)
(set-option :strings-fmf true)

(declare-fun x () String)
(declare-fun y () String)

(assert
(str.in.re x
(re.* (re.++ (re.* (str.to.re "a") ) (str.to.re "b") ))))
(assert (str.in.re y
(re.* (re.++ (re.* (str.to.re "a") ) (str.to.re "b") ))))

(assert (not (= x y)))
(assert (= (str.len x) (str.len y)))

(check-sat)

=API=
More details can be found in the [http://cvc4.cs.nyu.edu/wiki/Tutorials Tutorials].

==C++==
The example can be found in [https://github.com/CVC4/CVC4/blob/master/examples/api/strings.cpp examples/api/strings.cpp].

If setting the logic, use "S" to enable theory of strings.
smt.setLogic("S");

To create a string type, call <code>mkSetType</code> in the <code>ExprManager</code>.
Type string = em.stringType();

Make some string literals:
// std::string
std::string std_str_ab("ab");
// CVC4::String
CVC4::String cvc4_str_ab(std_str_ab);
CVC4::String cvc4_str_abc("abc");
// String constants
Expr ab = em.mkConst(cvc4_str_ab);
Expr abc = em.mkConst(CVC4::String("abc"));

Make some string variables:
Expr x = em.mkVar("x", string);
Expr y = em.mkVar("y", string);
Expr z = em.mkVar("z", string);

Make some string constraints:
// String concatenation: x.ab.y
Expr lhs = em.mkExpr(kind::STRING_CONCAT, x, ab, y);
// String concatenation: abc.z
Expr rhs = em.mkExpr(kind::STRING_CONCAT, abc, z);
// x.ab.y = abc.z
Expr formula1 = em.mkExpr(kind::EQUAL, lhs, rhs);
// Length of y: |y|
Expr leny = em.mkExpr(kind::STRING_LENGTH, y);
// |y| >= 0
Expr formula2 = em.mkExpr(kind::GEQ, leny, em.mkConst(Rational(0)));
// Regular expression: (ab[c-e]*f)|g|h
Expr r = em.mkExpr(kind::REGEXP_UNION,
em.mkExpr(kind::REGEXP_CONCAT,
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("ab"))),
em.mkExpr(kind::REGEXP_STAR,
em.mkExpr(kind::REGEXP_RANGE, em.mkConst(String("c")), em.mkConst(String("e")))),
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("f")))),
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("g"))),
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("h"))));
// String variables
Expr s1 = em.mkVar("s1", string);
Expr s2 = em.mkVar("s2", string);
// String concatenation: s1.s2
Expr s = em.mkExpr(kind::STRING_CONCAT, s1, s2);
// s1.s2 in (ab[c-e]*f)|g|h
Expr formula3 = em.mkExpr(kind::STRING_IN_REGEXP, s, r);

Make a query:
Expr q = em.mkExpr(kind::AND,
formula1,
formula2,
formula3);

Check the result:
Result result = smt.checkSat(q);
std::cout << "CVC4 reports: " << q << " is " << result << "." << std::endl;
if(result == Result::SAT) {
std::cout << " x = " << smt.getValue(x) << std::endl;
std::cout << " s1.s2 = " << smt.getValue(s) << std::endl;
}

==Java==
The example can be found in [https://github.com/CVC4/CVC4/blob/master/examples/api/java/Strings.java examples/api/java/Strings.java].

=References=
* Tianyi Liang, Andrew Reynolds, Cesare Tinelli, Clark Barrett and Morgan Deters. [http://link.springer.com/chapter/10.1007%2F978-3-319-08867-9_43 A DPLL(T) Theory Solver for a Theory of Strings and Regular Expressions].In Proceedings of the 26th International Conference on Computer Aided Verification (CAV'14), Vienna, Austria, 2014.
* Tianyi Liang. [http://ir.uiowa.edu/etd/1478/ Automated reasoning over string constraints]. PhD Dissertation, Department of Computer Science, The University of Iowa, Dec 2014.

Strings

2015-06-09T21:42:49Z

Tinelli: Revised section on string constants to be consistent with SMT-LIB 2.5, CVC4 front end might need to be revised accordingly

This page describes support for the theory of strings in CVC4.

=Syntax=
This document focuses on input written in SMT-LIB 2 format.
A frontend for CVC4's native syntax is not available yet.

'''We highly recommend that users use SMT-LIB [http://smt-lib.org/language.shtml Version 2.5],
instead of Version 2.0.'''
The major difference is in the definition of escape sequences for string literals.

'''The syntax below is for CVC4 version > 1.4.''' Version 1.3 has only
''partial'' support for syntax in this document.

Since the string (sub)solver is still relatively new, the current stable version
of CVC4 (1.4) does not provide the latest version of that solver.
Please use our latest Development version instead.

Currently, the string solver supports string constants over a set of characters
limited to the printable ASCII characters. Other characters ''must'' be encoded
with escape sequences.
For arbitry alphabets, we plan to provide later a separate solver
for a theory of parametric sequences.

To use the string solver it is important to declare initially
(using the <code>set-logic</code> command) an SMT-LIB logic that includes strings.
Since the SMT-LIB standard does not have an official theory of strings and
related logics yet, the logic names described below are tentive and
might change later.

The basic logic is <code>QF_S</code> consisting of quanfier-free formulas
over just the theory of strings, e.g.:
(set-logic QF_S)

If the formulas contain sybols from theories, please add them accordingly,
e.g., if the formulas contain symbols from the BitVector theory,
the logic symbol should be <code>QF_SBV</code>.

The logic consisting of the full (quantified) theory strings is
<code>QF_SBV</code>:
(set-logic S)

==Unsat Cores==
The string solver supports the generation of unsatisfiable cores.
As with other subsolvers though, you must enable proofs at configuration time,
and then run CVC with "--dump-unsat-cores" flag.

==Options==
Some functions in the theory are have only experimental support currently and
are disabled by default (even in the <code>ALL_SUPPORTED</code> logic:
To use them:
(set-option :strings-exp true)

The solver can be run in ''finite model finding mode'' which guarantees
termination for satisfiable problems.
This mode is disabled by default. To enable it:
(set-option :strings-fmf true)
Note that in this mode the solver is much '''slower''' than in default mode,
so we recommend it only as a fall back option when the default mode fails
to find a solution with a reasonably large timeout.

To select the strategy of LB rule application: 0-lazy, 1-eager, 2-no (0 by default):
(set-option :strings-lb 1)

To set up string alphabet cardinality (256 by default, expert option):
(set-option :strings-alphabet-card n)
This is a reserved option for the extension of the sequence theory.

==Alphabet==
Currently, the solver's theory is based on an alphabet consisting of the 256
characters from (8-bit) Extended ASCII.
Since there are several versions of Extended ASCII, we allow string constants
to contain only ''printable US ASCII characters'', which are encoded
in the same way in all Extended ASCII versions.

'''Note:''' The alphabet will change to the one prescribed by the SMT-LIB standard
once there is one.

==Printable Characters==
A ''printable'' character is any character with numerical value between 0x20 and 0x7e
in the standard US ASCII encoding.

==Escape Sequences for String Literals==
String constants are denoted by SMT-LIB string literals consisting of sequences of printable characters delimited by double-quotes (<code>"</code>).

We support escape sequences used in most programming languages
to represent non-printable characters.

{| border="1"
|-
| <code>\0</code> … <code>\9</code>
| represents ASCII character 0 … 9, respectively
|-
| <code>\a</code>, <code>\b</code>, <code>\e</code>, <code>\f</code>, <code>\n</code>, <code>\r</code>, <code>\t</code>, <code>\v</code>
| represents its corresponding ASCII character (C++ convention)
|-
| <code>\</code>''ooo''
| encodes a single ASCII character where ''ooo'' consists of exactly three digits in the octal encoding of the character (from 0 to 377). For example, <code>\101<code> represents <code>A<code>. '''Note:''' going beyond the 377 value might give unexpected results. For instance. <code>\437</code> will be translated in the two-character string <code>#7</code>.
|-
| <code>\x<code>''NN''
| encodes a single ASCII character, where ''NN'' consists of exactly two digits in the exadecimal encoding of the character.
|}

When the backslash character (<code>\<code>') is silently ignored when it is followed by a sequence of characters that is not recognized as an escape sequence. For example, <quote>\$ </quote>, say, is parsed as if it was just <quote>$</quote>.

In CVC4 string literal output, a non-printable/extended ASCII character is printed in the exadecimal format <code>\x<code>''NN'', except for the character denoted by the escape sequences <code>\a</code>, <code>\b</code>, <code>\e</code>, <code>\f</code>, <code>\n</code>, <code>\r</code>, <code>\t</code>, <code>\v</code>, which are printed using those escape sequences.

'''Note''':
These escape sequences are specific to string constants in the theory of strings. They are '''not''' escape sequences in SMT-Lib 2 per se.
SMT-LIB 2.5 has only one escape sequence for string literals: <code>""</code>,
which denotes the double quotes.
This means that a string literal like <code>"a""c"</code> is read by the solver as the string constant consisting of the characters <code>a</code>, <code>"</code>, and <code>c</code>.
The same constant can be entered as <code>"a\042c"</code> or <code>"a\x22c"</code>.

==Theory Signature==
To define a string variable:
(declare-fun x () String)

String Concatenation:
(str.++ s1 s2 ... sn)
where s1, s2, ..., and sn are string terms. String concatenation takes at least 2 arguments.

String Length:
(str.len s)
where s is a string term.

Character in String:
(str.at s i)
where s is a string term and i is a natural number. (see partial functions)
The index is starting from 0.

Sub-String:
(str.substr s i j )
where s is a string term, i and j are natural numbers. (see partial functions)

==Escape Sequences for Regular Expressions==
Currently, it is for CVC format only. (coming soon)

==Symbolic Regular Expression==
Membership Constraint:
(str.in.re s r)
where s is a string term and r is a regular expression.

String to Regular Expression Conversion:
(str.to.re s)
where s is a string term. The statement turns a regular expression that only contains a string s.

Regular Expression Concatenation:
(re.++ r_1 r_2 ... r_n)
where r_1, r_2, ..., r_n are regular expressions.

Regular Expression Alternation:
(re.union r_1 r_2 ... r_n)
where r_1, r_2, ..., r_n are regular expressions. re.or is for releases before March, 2014.

Regular Expression Intersection:
(re.inter r_1 r_2 ... r_n)
where r_1, r_2, ..., r_n are regular expressions. re.itr is for releases before March, 2014.

Regular Expression Kleene-Star:
(re.* r)
where r is a regular expression.

Regular Expression Kleene-Cross:
(re.+ r)
where r is a regular expression.

Regular Expression Option:
(re.opt r)
where r is a regular expression.

Regular Expression Range:
(re.range s t)
where s, t are single characters in double quotes, e.g. "a", "b".
It returns a regular expression that contains any character between s and t.

Regular Expression Loop:
(re.loop r l u)
where r is a regular expression, l is a non-negative constant integer, and u is a non-negative constant integer.
It returns a regular expression that contains at least l repetitions of r and at most u repetitions of r.
If l >= u, it returns exactly l repetitions of r.

Regular Expression Loop-2:
(re.loop r l)
where r is a regular expression, and l is a non-negative constant integer.
It returns a regular expression that contains at least l repetitions of r.

The Empty Regular Expression:
re.nostr

The Regular Expression that contains all characters:
re.allchar

==Experimental Mode==
Following functions are under the --strings-exp option. They are under active refinement. Once they are stable, we will move them to the default mode. Please let us know when you have some suggestions.

String Char-At:
(str.at s i)
where s is a string term and i is an integer term. i is the position. See partial functions section.

String Sub-string:
(str.substr s i j)
where s is a string term and i, j are integer terms. i is the starting position, and j is the offset. See partial functions section.

String Contain:
(str.contains s t)
where s and t are string terms. It returns true if the string s contains the string t.
This function determines whether the string t can be found within the string s, returning true or false as appropriate.

String IndexOf:
(str.indexof s t i)
where s is a string, t is a non-empty string and i is a non-negative integer.
This function returns the position of the first occurrence of the specified value t in the string s after the index i.
It returns -1 if the value to search for never occurs.

String Replacement:
(str.replace s t1 t2)
where s, t1 and t2 are string terms, t1 is non-empty.
This function searches the string s for the specified value t1, and returns a new string where the first occurrence of the specified value t1 is replaced by the string t2.

String PrefixOf:
(str.prefixof s t)
where s and t are string terms. It returns true if the string s is a prefix of the string t.

String SuffixOf:
(str.suffixof s t)
where s and t are string terms. It returns true if the string s is a suffix of the string t.

String To Integer Conversion:
(str.to.int s)
where s is a string term. It returns the corresponding natural number if s is valid; otherwise, it returns -1.

Integer To String Conversion:
(int.to.str i)
where i is an integer term. It returns the corresponding string if i is a natural number; otherwise, it returns an empty string.

=Partial Functions=
By the definition of partial functions in [http://www.smtlib.org/ SMT-Lib Document], the following constraint is satisfiable:
(assert (= (str.substr "a" 2 10) "b"))
However, the following constraints are unsatisfiable:
(assert (= (str.substr "a" 2 1) "b"))
(assert (= (str.substr "a" 2 1) "c"))
To achieve a desirable goal, it requires users to guard proper conditions. For example,
(assert (= (str.at x j) "b"))
(assert (> j 0))
(assert (> (str.len x) j))

=Extension=
Together with other engine in CVC4, we can extend new functionality in the theory of strings. For example,
(define-fun fun1 ((?x String) (?s String)) Bool
(or (= ?x ?s)
(> (str.len ?x) (str.len ?s))
))
Quantifiers over bounded Integers (with strings in the body) are supported in the experimental mode; however, quantifiers over strings are still under development.

=Limitation=
The decidability of this theory is unknown.
For satisfiable problems (without extensions), our solver is sound, complete and terminating in the FMF mode (although the FMF mode will be slower than the default mode in general). For unsatisfiable problems, the termination is not guaranteed; however, user can tune the options for termination.

Current version supports ASCII characters only. We will move on to UNICODE in the future version.

=Examples=
Find an assignment for x, where x."ab"="ba".x and the length of x equals to 7.
(set-logic QF_S)

(declare-fun x () String)

(assert (= (str.++ x "ab") (str.++ "ba" x)))
(assert (= (str.len x) 7))

(check-sat)

Find assignments for x and y, where x and y are distinct and their lengths are equal.
(set-logic QF_S)

(declare-fun x () String)
(declare-fun y () String)

(assert (not (= x y)))
(assert (= (str.len x) (str.len y)))

(check-sat)

Find assignments for x and y, where x.y != y.x.
(set-logic QF_S)

(declare-fun x () String)
(declare-fun y () String)
(assert (not (= (str.++ x y) (str.++ y x))))

(check-sat)

Find a model for x, y and z, where x."ab".y=y."ba".z and z=x.y and x."a"!="a".x.
(set-logic QF_S)

(declare-fun x () String)
(declare-fun y () String)
(declare-fun z () String)

(assert (= (str.++ x "ab" y) (str.++ y "ba" z)))
(assert (= z (str.++ x y)))
(assert (not (= (str.++ x "a") (str.++ "a" x))))

(check-sat)

Find a model for x and y, where both x and y are in the RegEx (a*b)* and they are different but have the same length.
(set-logic QF_S)
(set-option :strings-fmf true)

(declare-fun x () String)
(declare-fun y () String)

(assert
(str.in.re x
(re.* (re.++ (re.* (str.to.re "a") ) (str.to.re "b") ))))
(assert (str.in.re y
(re.* (re.++ (re.* (str.to.re "a") ) (str.to.re "b") ))))

(assert (not (= x y)))
(assert (= (str.len x) (str.len y)))

(check-sat)

=API=
More details can be found in the [http://cvc4.cs.nyu.edu/wiki/Tutorials Tutorials].

==C++==
The example can be found in [https://github.com/CVC4/CVC4/blob/master/examples/api/strings.cpp examples/api/strings.cpp].

If setting the logic, use "S" to enable theory of strings.
smt.setLogic("S");

To create a string type, call <code>mkSetType</code> in the <code>ExprManager</code>.
Type string = em.stringType();

Make some string literals:
// std::string
std::string std_str_ab("ab");
// CVC4::String
CVC4::String cvc4_str_ab(std_str_ab);
CVC4::String cvc4_str_abc("abc");
// String constants
Expr ab = em.mkConst(cvc4_str_ab);
Expr abc = em.mkConst(CVC4::String("abc"));

Make some string variables:
Expr x = em.mkVar("x", string);
Expr y = em.mkVar("y", string);
Expr z = em.mkVar("z", string);

Make some string constraints:
// String concatenation: x.ab.y
Expr lhs = em.mkExpr(kind::STRING_CONCAT, x, ab, y);
// String concatenation: abc.z
Expr rhs = em.mkExpr(kind::STRING_CONCAT, abc, z);
// x.ab.y = abc.z
Expr formula1 = em.mkExpr(kind::EQUAL, lhs, rhs);
// Length of y: |y|
Expr leny = em.mkExpr(kind::STRING_LENGTH, y);
// |y| >= 0
Expr formula2 = em.mkExpr(kind::GEQ, leny, em.mkConst(Rational(0)));
// Regular expression: (ab[c-e]*f)|g|h
Expr r = em.mkExpr(kind::REGEXP_UNION,
em.mkExpr(kind::REGEXP_CONCAT,
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("ab"))),
em.mkExpr(kind::REGEXP_STAR,
em.mkExpr(kind::REGEXP_RANGE, em.mkConst(String("c")), em.mkConst(String("e")))),
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("f")))),
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("g"))),
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("h"))));
// String variables
Expr s1 = em.mkVar("s1", string);
Expr s2 = em.mkVar("s2", string);
// String concatenation: s1.s2
Expr s = em.mkExpr(kind::STRING_CONCAT, s1, s2);
// s1.s2 in (ab[c-e]*f)|g|h
Expr formula3 = em.mkExpr(kind::STRING_IN_REGEXP, s, r);

Make a query:
Expr q = em.mkExpr(kind::AND,
formula1,
formula2,
formula3);

Check the result:
Result result = smt.checkSat(q);
std::cout << "CVC4 reports: " << q << " is " << result << "." << std::endl;
if(result == Result::SAT) {
std::cout << " x = " << smt.getValue(x) << std::endl;
std::cout << " s1.s2 = " << smt.getValue(s) << std::endl;
}

==Java==
The example can be found in [https://github.com/CVC4/CVC4/blob/master/examples/api/java/Strings.java examples/api/java/Strings.java].

=References=
* Tianyi Liang, Andrew Reynolds, Cesare Tinelli, Clark Barrett and Morgan Deters. [http://link.springer.com/chapter/10.1007%2F978-3-319-08867-9_43 A DPLL(T) Theory Solver for a Theory of Strings and Regular Expressions].In Proceedings of the 26th International Conference on Computer Aided Verification (CAV'14), Vienna, Austria, 2014.
* Tianyi Liang. [http://ir.uiowa.edu/etd/1478/ Automated reasoning over string constraints]. PhD Dissertation, Department of Computer Science, The University of Iowa, Dec 2014.

Strings

2015-06-09T21:07:13Z

Tinelli: Started polishing text

This page describes support for the theory of strings in CVC4.

=Syntax=
This document focuses on input written in SMT-LIB 2 format. A frontend for CVC4's native syntax is not available yet.

'''We highly recommend that users use SMT-LIB [http://smt-lib.org/language.shtml Version 2.5], instead of Version 2.0.''' The major difference is in the definition of escape sequences for string literals.

'''The syntax below is for CVC4 version > 1.4.''' Version 1.3 has only has ''partial'' support for syntax in this document.

Since the string (sub)solver is still relatively new, the current stable version of CVC4 (1.4) does not provide the latest version of that solver. Please use our latest Development version instead.

Currently, the string solver supports string constants over a set characters limited to printable ASCII characters. Other characters ''must'' be encoded with escape sequences. For arbitry alphabets, we plan to provide later a separate solver for a theory of parametric sequences.

To use the string solver it is important to declare initially (using the <code>set-logic</code> command) an SMT-LIB logic that includes strings. Since the SMT-LIB standard does not have an official theory of strings and related logics yet, the logic names described below are tentive and might change later.

The basic logic is <code>QF_S</code> consisting of quanfier-free formulas over just the theory of strings, e.g., :
(set-logic QF_S)

If the formulas contain sybols from theories, please add them accordingly, e.g., if the formulas contain symbols from the BitVector theory, the logic symbol should be <code>QF_SBV</code>.

The logic consisting of the full (quantified) theory strings is <code>QF_SBV</code>:
(set-logic S)

==Unsat Cores==
The string solver supports the generation of unsatisfiable core. As wilt other subsolvers though you must enable proofs at configuration time, and
then run CVC with "--dump-unsat-cores" flag.

==Options==
Some functions in the theory are have only experimental support currently
and are disabled by default (even in the <code>ALL_SUPPORTED</code> logic:
To use them:
(set-option :strings-exp true)

The solver can be run in ''finite model finding mode'' which guarantees termination for satisfiable problems. This mode is disabled by default. To enable it:
(set-option :strings-fmf true)
Note that in this mode the solver is much '''slower''' than in default mode. So we recommend it only as a fall back option when the default mode fails to find a solution within a reasonably large timeout.

To select the strategy of LB rule application: 0-lazy, 1-eager, 2-no (0 by default):
(set-option :strings-lb 1)

To set up string alphabet cardinality (256 by default, expert option):
(set-option :strings-alphabet-card n)
This is a reserved option for the extension of the sequence theory.

==Alphabet==
Currently, the solver's theory is based on an alphabet consisting of the 256 characters from (8-bit)Extended ASCII. Since there are several versions of Extended ASCII we allow string constants to contain only ''printable US ASCII characters'', which are encoded in the same way in all Extended ASCII versions.

'''Note:''' The alphabet will change to the one prescribed by the SMT-LIB standard once there is one.

==Printable Characters==
A ''printable'' character is any character with numerical value between 0x20 and 0x7e in the standard US ASCII encoding.

==Escape Sequences for String Literals==

We support escape sequences common in most programming languages to represent non-printable characters.

{| border="1"
|-
| <code>\0</code> … <code>\9</code>
| represents ASCII character 0 … 9, respectively
|-
| <code>\a</code>, <code>\b</code>, <code>\e</code>, <code>\f</code>, <code>\n</code>, <code>\r</code>, <code>\t</code>, <code>\v</code>
| represents its corresponding ASCII character (C++ convention)
|-
| \ooo
| matches an ASCII character, where ooo consists of (no more than) three digits that represent the octal character code (from 0 to 377). For example, \101 represents ‘A’, while “\437” represent a string with two characters “#7”( *important* ).
|-
| \xNN
| matches an ASCII character, where NN is a two-digit hexadecimal character code. NN has to be exactly two hex-digits. If not, an exception will be raised.
|}

The backslash character (\) : when followed by a character that is not recognized as an escaped character, matches that character. For example, \" matches a double quote(").

In CVC4 string literal output, a non-printable/extended ASCII character is printed in the format \xNN, where NN matches its ASCII character, except for \a, \b, \e, \f, \n, \r, \t, \v, which are printed directly.

'''Note''': Escaped character literals are for version (> 1.3). They are '''not''' compatible with the string literal standards in SMT-Lib v2.

To be compliant with SMT-Lib, users are required to add another layer of escapes.
For example, in v2.0, both \t and \\t mean the tab character, and both \\\t and \\\\t mean the two characters \ and t.
In v2.5, only \t means the tab character, and \\t means the two characters \ and t.
In v2.5, both \"" and "" means the character ".
Please check the string literals section in SMT-Lib v2.5 standard for more details.

In string literals (for the string engine) that are following the SMT-Lib v2.5 specification, it is mandatory to escape \ (by \\) and " (by "") to prevent parse error.

==Strings==
To define a string variable:
(declare-fun x () String)

String Concatenation:
(str.++ s1 s2 ... sn)
where s1, s2, ..., and sn are string terms. String concatenation takes at least 2 arguments.

String Length:
(str.len s)
where s is a string term.

Character in String:
(str.at s i)
where s is a string term and i is a natural number. (see partial functions)
The index is starting from 0.

Sub-String:
(str.substr s i j )
where s is a string term, i and j are natural numbers. (see partial functions)

==Escape Sequences for Regular Expressions==
Currently, it is for CVC format only. (coming soon)

==Symbolic Regular Expression==
Membership Constraint:
(str.in.re s r)
where s is a string term and r is a regular expression.

String to Regular Expression Conversion:
(str.to.re s)
where s is a string term. The statement turns a regular expression that only contains a string s.

Regular Expression Concatenation:
(re.++ r_1 r_2 ... r_n)
where r_1, r_2, ..., r_n are regular expressions.

Regular Expression Alternation:
(re.union r_1 r_2 ... r_n)
where r_1, r_2, ..., r_n are regular expressions. re.or is for releases before March, 2014.

Regular Expression Intersection:
(re.inter r_1 r_2 ... r_n)
where r_1, r_2, ..., r_n are regular expressions. re.itr is for releases before March, 2014.

Regular Expression Kleene-Star:
(re.* r)
where r is a regular expression.

Regular Expression Kleene-Cross:
(re.+ r)
where r is a regular expression.

Regular Expression Option:
(re.opt r)
where r is a regular expression.

Regular Expression Range:
(re.range s t)
where s, t are single characters in double quotes, e.g. "a", "b".
It returns a regular expression that contains any character between s and t.

Regular Expression Loop:
(re.loop r l u)
where r is a regular expression, l is a non-negative constant integer, and u is a non-negative constant integer.
It returns a regular expression that contains at least l repetitions of r and at most u repetitions of r.
If l >= u, it returns exactly l repetitions of r.

Regular Expression Loop-2:
(re.loop r l)
where r is a regular expression, and l is a non-negative constant integer.
It returns a regular expression that contains at least l repetitions of r.

The Empty Regular Expression:
re.nostr

The Regular Expression that contains all characters:
re.allchar

==Experimental Mode==
Following functions are under the --strings-exp option. They are under active refinement. Once they are stable, we will move them to the default mode. Please let us know when you have some suggestions.

String Char-At:
(str.at s i)
where s is a string term and i is an integer term. i is the position. See partial functions section.

String Sub-string:
(str.substr s i j)
where s is a string term and i, j are integer terms. i is the starting position, and j is the offset. See partial functions section.

String Contain:
(str.contains s t)
where s and t are string terms. It returns true if the string s contains the string t.
This function determines whether the string t can be found within the string s, returning true or false as appropriate.

String IndexOf:
(str.indexof s t i)
where s is a string, t is a non-empty string and i is a non-negative integer.
This function returns the position of the first occurrence of the specified value t in the string s after the index i.
It returns -1 if the value to search for never occurs.

String Replacement:
(str.replace s t1 t2)
where s, t1 and t2 are string terms, t1 is non-empty.
This function searches the string s for the specified value t1, and returns a new string where the first occurrence of the specified value t1 is replaced by the string t2.

String PrefixOf:
(str.prefixof s t)
where s and t are string terms. It returns true if the string s is a prefix of the string t.

String SuffixOf:
(str.suffixof s t)
where s and t are string terms. It returns true if the string s is a suffix of the string t.

String To Integer Conversion:
(str.to.int s)
where s is a string term. It returns the corresponding natural number if s is valid; otherwise, it returns -1.

Integer To String Conversion:
(int.to.str i)
where i is an integer term. It returns the corresponding string if i is a natural number; otherwise, it returns an empty string.

=Partial Functions=
By the definition of partial functions in [http://www.smtlib.org/ SMT-Lib Document], the following constraint is satisfiable:
(assert (= (str.substr "a" 2 10) "b"))
However, the following constraints are unsatisfiable:
(assert (= (str.substr "a" 2 1) "b"))
(assert (= (str.substr "a" 2 1) "c"))
To achieve a desirable goal, it requires users to guard proper conditions. For example,
(assert (= (str.at x j) "b"))
(assert (> j 0))
(assert (> (str.len x) j))

=Extension=
Together with other engine in CVC4, we can extend new functionality in the theory of strings. For example,
(define-fun fun1 ((?x String) (?s String)) Bool
(or (= ?x ?s)
(> (str.len ?x) (str.len ?s))
))
Quantifiers over bounded Integers (with strings in the body) are supported in the experimental mode; however, quantifiers over strings are still under development.

=Limitation=
The decidability of this theory is unknown.
For satisfiable problems (without extensions), our solver is sound, complete and terminating in the FMF mode (although the FMF mode will be slower than the default mode in general). For unsatisfiable problems, the termination is not guaranteed; however, user can tune the options for termination.

Current version supports ASCII characters only. We will move on to UNICODE in the future version.

=Examples=
Find an assignment for x, where x."ab"="ba".x and the length of x equals to 7.
(set-logic QF_S)

(declare-fun x () String)

(assert (= (str.++ x "ab") (str.++ "ba" x)))
(assert (= (str.len x) 7))

(check-sat)

Find assignments for x and y, where x and y are distinct and their lengths are equal.
(set-logic QF_S)

(declare-fun x () String)
(declare-fun y () String)

(assert (not (= x y)))
(assert (= (str.len x) (str.len y)))

(check-sat)

Find assignments for x and y, where x.y != y.x.
(set-logic QF_S)

(declare-fun x () String)
(declare-fun y () String)
(assert (not (= (str.++ x y) (str.++ y x))))

(check-sat)

Find a model for x, y and z, where x."ab".y=y."ba".z and z=x.y and x."a"!="a".x.
(set-logic QF_S)

(declare-fun x () String)
(declare-fun y () String)
(declare-fun z () String)

(assert (= (str.++ x "ab" y) (str.++ y "ba" z)))
(assert (= z (str.++ x y)))
(assert (not (= (str.++ x "a") (str.++ "a" x))))

(check-sat)

Find a model for x and y, where both x and y are in the RegEx (a*b)* and they are different but have the same length.
(set-logic QF_S)
(set-option :strings-fmf true)

(declare-fun x () String)
(declare-fun y () String)

(assert
(str.in.re x
(re.* (re.++ (re.* (str.to.re "a") ) (str.to.re "b") ))))
(assert (str.in.re y
(re.* (re.++ (re.* (str.to.re "a") ) (str.to.re "b") ))))

(assert (not (= x y)))
(assert (= (str.len x) (str.len y)))

(check-sat)

=API=
More details can be found in the [http://cvc4.cs.nyu.edu/wiki/Tutorials Tutorials].

==C++==
The example can be found in [https://github.com/CVC4/CVC4/blob/master/examples/api/strings.cpp examples/api/strings.cpp].

If setting the logic, use "S" to enable theory of strings.
smt.setLogic("S");

To create a string type, call <code>mkSetType</code> in the <code>ExprManager</code>.
Type string = em.stringType();

Make some string literals:
// std::string
std::string std_str_ab("ab");
// CVC4::String
CVC4::String cvc4_str_ab(std_str_ab);
CVC4::String cvc4_str_abc("abc");
// String constants
Expr ab = em.mkConst(cvc4_str_ab);
Expr abc = em.mkConst(CVC4::String("abc"));

Make some string variables:
Expr x = em.mkVar("x", string);
Expr y = em.mkVar("y", string);
Expr z = em.mkVar("z", string);

Make some string constraints:
// String concatenation: x.ab.y
Expr lhs = em.mkExpr(kind::STRING_CONCAT, x, ab, y);
// String concatenation: abc.z
Expr rhs = em.mkExpr(kind::STRING_CONCAT, abc, z);
// x.ab.y = abc.z
Expr formula1 = em.mkExpr(kind::EQUAL, lhs, rhs);
// Length of y: |y|
Expr leny = em.mkExpr(kind::STRING_LENGTH, y);
// |y| >= 0
Expr formula2 = em.mkExpr(kind::GEQ, leny, em.mkConst(Rational(0)));
// Regular expression: (ab[c-e]*f)|g|h
Expr r = em.mkExpr(kind::REGEXP_UNION,
em.mkExpr(kind::REGEXP_CONCAT,
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("ab"))),
em.mkExpr(kind::REGEXP_STAR,
em.mkExpr(kind::REGEXP_RANGE, em.mkConst(String("c")), em.mkConst(String("e")))),
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("f")))),
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("g"))),
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("h"))));
// String variables
Expr s1 = em.mkVar("s1", string);
Expr s2 = em.mkVar("s2", string);
// String concatenation: s1.s2
Expr s = em.mkExpr(kind::STRING_CONCAT, s1, s2);
// s1.s2 in (ab[c-e]*f)|g|h
Expr formula3 = em.mkExpr(kind::STRING_IN_REGEXP, s, r);

Make a query:
Expr q = em.mkExpr(kind::AND,
formula1,
formula2,
formula3);

Check the result:
Result result = smt.checkSat(q);
std::cout << "CVC4 reports: " << q << " is " << result << "." << std::endl;
if(result == Result::SAT) {
std::cout << " x = " << smt.getValue(x) << std::endl;
std::cout << " s1.s2 = " << smt.getValue(s) << std::endl;
}

==Java==
The example can be found in [https://github.com/CVC4/CVC4/blob/master/examples/api/java/Strings.java examples/api/java/Strings.java].

=References=
* Tianyi Liang, Andrew Reynolds, Cesare Tinelli, Clark Barrett and Morgan Deters. [http://link.springer.com/chapter/10.1007%2F978-3-319-08867-9_43 A DPLL(T) Theory Solver for a Theory of Strings and Regular Expressions].In Proceedings of the 26th International Conference on Computer Aided Verification (CAV'14), Vienna, Austria, 2014.
* Tianyi Liang. [http://ir.uiowa.edu/etd/1478/ Automated reasoning over string constraints]. PhD Dissertation, Department of Computer Science, The University of Iowa, Dec 2014.

Strings

2015-06-09T20:05:35Z

Tinelli:

This page describes support for the theory of strings in CVC4.

=Syntax=
This document focuses on input written in SMT-LIB 2 format. A frontend for CVC4's native syntax is not available yet.

'''We highly recommend that users use SMT-LIB [http://smt-lib.org/language.shtml Version 2.5], instead of Version 2.0.''' The major difference is in the definition of escape sequences for string literals.

'''The syntax below is for CVC4 version > 1.4. Version 1.3 has only has ''partial'' support for syntax in this document.'''

Since the string subsolver is still relatively new, the current stable version of CVC4 (1.4) does not provide the latest version of that subsolver. Please use our '''latest Development version instead'''.

This string solver has a full support of '''ASCII''' characters. For arbitrary alphabets, please refer to sequence (parametrized string) theory.

In compliance with SMT-Lib v2, only printable basic ASCII characters are allowed to be appeared natively in string literals. Other ASCII characters '''must''' be encoded as escape sequences.

The Theory of Strings (Quantifier-Free) logic symbol:
(set-logic QF_S)

The logic symbol is '''IMPORTANT''' to the Theory of String, and it has to be set up.

If the constraints contain more theories, please add them accordingly, e.g. if it contains BitVector, the symbol should be QF_SBV.

The Theory of Quantified Strings logic symbol:
(set-logic S)

Since the theory of strings is pretty new in CVC4, we are still working on the standards for syntax.
If you have some comments or suggestions about CVC4 strings, please feel feel to email me: tianyi-liang@uiowa.edu

==Unsat Core==
String engine '''does''' support unsat core. To generate unsat cores, you must enable proofs at configure time, and
then run with "--dump-unsat-cores".

==Options==
To use the experimental functions (disabled by default, even in ALL_SUPPORTED mode):
(set-option :strings-exp true)

To use finite model finding mode (false by default):
(set-option :strings-fmf true)
The string finite model finding mode is much '''slower''' than the default mode. We highly recommend you '''NOT''' using it if it is not necessary.

To select the strategy of LB rule application: 0-lazy, 1-eager, 2-no (0 by default):
(set-option :strings-lb 1)

To set up string alphabet cardinality (256 by default, expert option):
(set-option :strings-alphabet-card n)
This is a reserved option for the extension of the sequence theory.

==Printable Characters==
A ''printable'' character is any character between 0x20 and 0x7e in the standard ASCII table.

==Escape Sequences for String Literals==
{| border="1"
|-
| \0 … \9
| represents ASCII character 0 … 9, respectively
|-
| \a, \b, \e, \f, \n, \r, \t, \v
| represents its corresponding ASCII character (C++ convention)
|-
| \ooo
| matches an ASCII character, where ooo consists of (no more than) three digits that represent the octal character code (from 0 to 377). For example, \101 represents ‘A’, while “\437” represent a string with two characters “#7”( *important* ).
|-
| \xNN
| matches an ASCII character, where NN is a two-digit hexadecimal character code. NN has to be exactly two hex-digits. If not, an exception will be raised.
|}

The backslash character (\) : when followed by a character that is not recognized as an escaped character, matches that character. For example, \" matches a double quote(").

In CVC4 string literal output, a non-printable/extended ASCII character is printed in the format \xNN, where NN matches its ASCII character, except for \a, \b, \e, \f, \n, \r, \t, \v, which are printed directly.

'''Note''': Escaped character literals are for version (> 1.3). They are '''not''' compatible with the string literal standards in SMT-Lib v2.

To be compliant with SMT-Lib, users are required to add another layer of escapes.
For example, in v2.0, both \t and \\t mean the tab character, and both \\\t and \\\\t mean the two characters \ and t.
In v2.5, only \t means the tab character, and \\t means the two characters \ and t.
In v2.5, both \"" and "" means the character ".
Please check the string literals section in SMT-Lib v2.5 standard for more details.

In string literals (for the string engine) that are following the SMT-Lib v2.5 specification, it is mandatory to escape \ (by \\) and " (by "") to prevent parse error.

==Strings==
To define a string variable:
(declare-fun x () String)

String Concatenation:
(str.++ s1 s2 ... sn)
where s1, s2, ..., and sn are string terms. String concatenation takes at least 2 arguments.

String Length:
(str.len s)
where s is a string term.

Character in String:
(str.at s i)
where s is a string term and i is a natural number. (see partial functions)
The index is starting from 0.

Sub-String:
(str.substr s i j )
where s is a string term, i and j are natural numbers. (see partial functions)

==Escape Sequences for Regular Expressions==
Currently, it is for CVC format only. (coming soon)

==Symbolic Regular Expression==
Membership Constraint:
(str.in.re s r)
where s is a string term and r is a regular expression.

String to Regular Expression Conversion:
(str.to.re s)
where s is a string term. The statement turns a regular expression that only contains a string s.

Regular Expression Concatenation:
(re.++ r_1 r_2 ... r_n)
where r_1, r_2, ..., r_n are regular expressions.

Regular Expression Alternation:
(re.union r_1 r_2 ... r_n)
where r_1, r_2, ..., r_n are regular expressions. re.or is for releases before March, 2014.

Regular Expression Intersection:
(re.inter r_1 r_2 ... r_n)
where r_1, r_2, ..., r_n are regular expressions. re.itr is for releases before March, 2014.

Regular Expression Kleene-Star:
(re.* r)
where r is a regular expression.

Regular Expression Kleene-Cross:
(re.+ r)
where r is a regular expression.

Regular Expression Option:
(re.opt r)
where r is a regular expression.

Regular Expression Range:
(re.range s t)
where s, t are single characters in double quotes, e.g. "a", "b".
It returns a regular expression that contains any character between s and t.

Regular Expression Loop:
(re.loop r l u)
where r is a regular expression, l is a non-negative constant integer, and u is a non-negative constant integer.
It returns a regular expression that contains at least l repetitions of r and at most u repetitions of r.
If l >= u, it returns exactly l repetitions of r.

Regular Expression Loop-2:
(re.loop r l)
where r is a regular expression, and l is a non-negative constant integer.
It returns a regular expression that contains at least l repetitions of r.

The Empty Regular Expression:
re.nostr

The Regular Expression that contains all characters:
re.allchar

==Experimental Mode==
Following functions are under the --strings-exp option. They are under active refinement. Once they are stable, we will move them to the default mode. Please let us know when you have some suggestions.

String Char-At:
(str.at s i)
where s is a string term and i is an integer term. i is the position. See partial functions section.

String Sub-string:
(str.substr s i j)
where s is a string term and i, j are integer terms. i is the starting position, and j is the offset. See partial functions section.

String Contain:
(str.contains s t)
where s and t are string terms. It returns true if the string s contains the string t.
This function determines whether the string t can be found within the string s, returning true or false as appropriate.

String IndexOf:
(str.indexof s t i)
where s is a string, t is a non-empty string and i is a non-negative integer.
This function returns the position of the first occurrence of the specified value t in the string s after the index i.
It returns -1 if the value to search for never occurs.

String Replacement:
(str.replace s t1 t2)
where s, t1 and t2 are string terms, t1 is non-empty.
This function searches the string s for the specified value t1, and returns a new string where the first occurrence of the specified value t1 is replaced by the string t2.

String PrefixOf:
(str.prefixof s t)
where s and t are string terms. It returns true if the string s is a prefix of the string t.

String SuffixOf:
(str.suffixof s t)
where s and t are string terms. It returns true if the string s is a suffix of the string t.

String To Integer Conversion:
(str.to.int s)
where s is a string term. It returns the corresponding natural number if s is valid; otherwise, it returns -1.

Integer To String Conversion:
(int.to.str i)
where i is an integer term. It returns the corresponding string if i is a natural number; otherwise, it returns an empty string.

=Partial Functions=
By the definition of partial functions in [http://www.smtlib.org/ SMT-Lib Document], the following constraint is satisfiable:
(assert (= (str.substr "a" 2 10) "b"))
However, the following constraints are unsatisfiable:
(assert (= (str.substr "a" 2 1) "b"))
(assert (= (str.substr "a" 2 1) "c"))
To achieve a desirable goal, it requires users to guard proper conditions. For example,
(assert (= (str.at x j) "b"))
(assert (> j 0))
(assert (> (str.len x) j))

=Extension=
Together with other engine in CVC4, we can extend new functionality in the theory of strings. For example,
(define-fun fun1 ((?x String) (?s String)) Bool
(or (= ?x ?s)
(> (str.len ?x) (str.len ?s))
))
Quantifiers over bounded Integers (with strings in the body) are supported in the experimental mode; however, quantifiers over strings are still under development.

=Limitation=
The decidability of this theory is unknown.
For satisfiable problems (without extensions), our solver is sound, complete and terminating in the FMF mode (although the FMF mode will be slower than the default mode in general). For unsatisfiable problems, the termination is not guaranteed; however, user can tune the options for termination.

Current version supports ASCII characters only. We will move on to UNICODE in the future version.

=Examples=
Find an assignment for x, where x."ab"="ba".x and the length of x equals to 7.
(set-logic QF_S)

(declare-fun x () String)

(assert (= (str.++ x "ab") (str.++ "ba" x)))
(assert (= (str.len x) 7))

(check-sat)

Find assignments for x and y, where x and y are distinct and their lengths are equal.
(set-logic QF_S)

(declare-fun x () String)
(declare-fun y () String)

(assert (not (= x y)))
(assert (= (str.len x) (str.len y)))

(check-sat)

Find assignments for x and y, where x.y != y.x.
(set-logic QF_S)

(declare-fun x () String)
(declare-fun y () String)
(assert (not (= (str.++ x y) (str.++ y x))))

(check-sat)

Find a model for x, y and z, where x."ab".y=y."ba".z and z=x.y and x."a"!="a".x.
(set-logic QF_S)

(declare-fun x () String)
(declare-fun y () String)
(declare-fun z () String)

(assert (= (str.++ x "ab" y) (str.++ y "ba" z)))
(assert (= z (str.++ x y)))
(assert (not (= (str.++ x "a") (str.++ "a" x))))

(check-sat)

Find a model for x and y, where both x and y are in the RegEx (a*b)* and they are different but have the same length.
(set-logic QF_S)
(set-option :strings-fmf true)

(declare-fun x () String)
(declare-fun y () String)

(assert
(str.in.re x
(re.* (re.++ (re.* (str.to.re "a") ) (str.to.re "b") ))))
(assert (str.in.re y
(re.* (re.++ (re.* (str.to.re "a") ) (str.to.re "b") ))))

(assert (not (= x y)))
(assert (= (str.len x) (str.len y)))

(check-sat)

=API=
More details can be found in the [http://cvc4.cs.nyu.edu/wiki/Tutorials Tutorials].

==C++==
The example can be found in [https://github.com/CVC4/CVC4/blob/master/examples/api/strings.cpp examples/api/strings.cpp].

If setting the logic, use "S" to enable theory of strings.
smt.setLogic("S");

To create a string type, call <code>mkSetType</code> in the <code>ExprManager</code>.
Type string = em.stringType();

Make some string literals:
// std::string
std::string std_str_ab("ab");
// CVC4::String
CVC4::String cvc4_str_ab(std_str_ab);
CVC4::String cvc4_str_abc("abc");
// String constants
Expr ab = em.mkConst(cvc4_str_ab);
Expr abc = em.mkConst(CVC4::String("abc"));

Make some string variables:
Expr x = em.mkVar("x", string);
Expr y = em.mkVar("y", string);
Expr z = em.mkVar("z", string);

Make some string constraints:
// String concatenation: x.ab.y
Expr lhs = em.mkExpr(kind::STRING_CONCAT, x, ab, y);
// String concatenation: abc.z
Expr rhs = em.mkExpr(kind::STRING_CONCAT, abc, z);
// x.ab.y = abc.z
Expr formula1 = em.mkExpr(kind::EQUAL, lhs, rhs);
// Length of y: |y|
Expr leny = em.mkExpr(kind::STRING_LENGTH, y);
// |y| >= 0
Expr formula2 = em.mkExpr(kind::GEQ, leny, em.mkConst(Rational(0)));
// Regular expression: (ab[c-e]*f)|g|h
Expr r = em.mkExpr(kind::REGEXP_UNION,
em.mkExpr(kind::REGEXP_CONCAT,
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("ab"))),
em.mkExpr(kind::REGEXP_STAR,
em.mkExpr(kind::REGEXP_RANGE, em.mkConst(String("c")), em.mkConst(String("e")))),
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("f")))),
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("g"))),
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("h"))));
// String variables
Expr s1 = em.mkVar("s1", string);
Expr s2 = em.mkVar("s2", string);
// String concatenation: s1.s2
Expr s = em.mkExpr(kind::STRING_CONCAT, s1, s2);
// s1.s2 in (ab[c-e]*f)|g|h
Expr formula3 = em.mkExpr(kind::STRING_IN_REGEXP, s, r);

Make a query:
Expr q = em.mkExpr(kind::AND,
formula1,
formula2,
formula3);

Check the result:
Result result = smt.checkSat(q);
std::cout << "CVC4 reports: " << q << " is " << result << "." << std::endl;
if(result == Result::SAT) {
std::cout << " x = " << smt.getValue(x) << std::endl;
std::cout << " s1.s2 = " << smt.getValue(s) << std::endl;
}

==Java==
The example can be found in [https://github.com/CVC4/CVC4/blob/master/examples/api/java/Strings.java examples/api/java/Strings.java].

=References=
* Tianyi Liang, Andrew Reynolds, Cesare Tinelli, Clark Barrett and Morgan Deters. [http://link.springer.com/chapter/10.1007%2F978-3-319-08867-9_43 A DPLL(T) Theory Solver for a Theory of Strings and Regular Expressions].In Proceedings of the 26th International Conference on Computer Aided Verification (CAV'14), Vienna, Austria, 2014.
* Tianyi Liang. [http://ir.uiowa.edu/etd/1478/ Automated reasoning over string constraints]. PhD Dissertation, Department of Computer Science, The University of Iowa, Dec 2014.

CVC4's native language

2013-02-13T05:54:12Z

Tinelli: /* Tuple Types */

= CVC4 native input language =

The native input language consists of a sequence of symbol declarations and commands, each followed by a semicolon (<code>;</code>).

Any text after the first occurrence of a percent character and to the end of the current line is a comment:

%%% This is a native language comment

== Type System ==

CVC4's type system includes a set of built-in types which can be expanded with additional user-defined types.

The type system consists of ''first-order'' types, ''subtypes'' of first-order types, and ''higher-order'' types, all of which are interpreted as sets.
For convenience, we will sometimes identify below the interpretation of a type with the type itself.

First-order types consist of basic types and structured types. The basic types are <math>\mathrm{BOOLEAN}</math>, <math>\mathrm{REAL}</math>, <math>\mathrm{BITVECTOR}(n)</math> for all <math>n > 0</math>, as well as user-defined basic types (also called uninterpreted types).
The structured types are array, tuple, record types, and ML-style user-defined (inductive) datatypes.

'''Note:''' Currently, subtypes consist only of the built-in subtype <math>\mathrm{INT}</math> of <math>\mathrm{REAL}</math>.

Support for CVC3-style user-defined subtypes will be added in a later release.

Function types are the only higher-order types.
More precisely, they are just second-order types
since function symbols in CVC4, both built-in and user-defined, can take as argument or return only values of
a first-order type.

=== Basic Types ===

==== The BOOLEAN Type ====

The <math>\mathrm{BOOLEAN}</math> type is interpreted as the two-element set of Boolean values
<math>\{\mathrm{TRUE},\; \mathrm{FALSE}\}</math>.

'''Note:''' CVC4's treatment of this type differs from CVC3's where <math>\mathrm{BOOLEAN}</math> is used only as the type of formulas, but not as value type. CVC3 follows the two-tiered structure of classical first-order logic
which distinguishes between formulas and terms, and allows terms to occur in formulas but not vice versa (with the exception of the IF-THEN-ELSE construct).
CVC4 drops the distinction between terms and formulas and defines the latter just as terms of type <math>\mathrm{BOOLEAN}</math>. As such, formulas can occur as subterms of possibly non-Boolean terms.

Example:

% Boolean constants
a, b: BOOLEAN;

% REAL constants
x,y: REAL;

% Boolean-valued function, can be used as a predicate symbol
p: REAL -> BOOLEAN;
ASSERT a => p(x - y);

% Real-valued function with Boolean argument
f: BOOLEAN -> REAL;

% The argument of f can be a formula ...
ASSERT f(a OR b) > 0.3 OR p(x);

% ... even a quantified one
ASSERT y = f(FORALL (r: REAL): r < r + 1);

==== The REAL Type ====

The <math>\mathrm{REAL}</math> type is interpreted as the set of real numbers.

Note that these are the (infinite precision) mathematical reals,
not the floating point numbers.
Support for floating point types is planned for future versions.

x, y : REAL;
QUERY (( x <= y ) AND ( y <= x )) => ( x = y );

==== The INT Type ====

The <math>\mathrm{INT}</math> type is interpreted as the set of integer numbers
and is considered a subtype of <math>\mathrm{REAL}</math>.
The latter means in particular that it is possible to mix integer and real terms
in expressions without the need of an explicit ''upcasting'' operator.

Note that these are the (infinite precision) mathematical integers,
not the finite precision machine integers used in most programming languages.
The latter are modeled by [[ #Bitvectors | bit vector ]] types.

x, y : INT;
QUERY ((2 * x + 4 * y <= 1) AND ( y >= x)) => (x <= 0);
z : REAL;
QUERY (2 * x + z <= 3.5) AND (z >= 1);

==== Bit Vector Types ====

For every positive integer <math>n</math>, the type <math>\mathrm{BITVECTOR}(n)</math> is interpreted as the set of all bit vectors of size <math>n</math>.
A rich set of bit vector operators is supported.

==== User-defined Basic Types ====

Users can define new basic types
(often referred to as ''uninterpreted'' types in the SMT literature).
Each such type is interpreted as a set of unspecified cardinality
but disjoint from any other type.

User-defined basic types are created by declarations like the following:

% User declarations of basic types:

MyBrandNewType: TYPE;

Apples, Oranges: TYPE;

=== Structured Types ===

CVC4's structured types are divided into the following families.

==== Array Types ====

Array types are created by the mixfix type constructors <math>\mathrm{ARRAY}\ \_\ \mathrm{OF}\ \_</math>
whose arguments can be instantiated by any value type.

I : TYPE;

%% Array types:

% Arrays with indices from I and values from REAL
Array1: TYPE = ARRAY I OF REAL;

% Arrays with integer indices and array values
Array2: TYPE = ARRAY INT OF (ARRAY INT OF REAL);

% Arrays with integer pair indices and integer values
IntMatrix: TYPE = ARRAY [INT, INT] OF INT;

An array type of the form <math>\mathrm{ARRAY}\ T_1\ \mathrm{OF}\ T_2</math> is interpreted
as the set of all total maps from <math>T_1</math> to <math>T_2</math>.
The main difference with the function type <math>T_1 \to T_2</math> is that arrays,
contrary to functions, are first-class objects of the language, that is, values of an array
type can be arguments or results of functions.
Furthermore, array types come equipped with an update operation.

==== Tuple Types ====

Tuple types are created by the mixfix type constructors

<center>
<math>
\begin{array}{l} [\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ \ ,\ \_\ ] \\[1ex] \ldots \end{array}
</math>
</center>

whose arguments can be instantiated by any value type.

IntArray: TYPE = ARRAY INT OF INT;

% Tuple type declarations

RealPair: TYPE = [REAL, REAL];

MyTuple: TYPE = [ REAL, IntArray, [INT, INT] ];

A tuple type of the form <math>[T_1, \ldots, T_n]</math> is interpreted
as the Cartesian product <math>T_1 \times \cdots \times T_n</math>.

Note that while the types <math>(T_1, \ldots, T_n) \to T</math> and
<math>[T_1 \times \cdots \times T_n] \to T</math> are semantically equivalent,
they are operationally different in CVC4.
The first is the type of functions that take <math>n</math> arguments
of respective type <math>T_1</math>, <math>\ldots</math>, <math>T_n</math>,
while the second is the type of functions that take one argument of an <math>n</math>-tuple type.

==== Record Types ====

Similar to, but more general than tuple types, record types are created by type constructors of the form

<center>
<math>
[\#\ l_1: \_\ ,\ \ldots\ ,\ l_n: \_\ \#]
</math>
</center>

where <math>n > 0</math>, <math>l_1,\ldots, l_n</math> are field labels,
and the arguments can be instantiated with any first-order types.

MyType: TYPE;

% Record declaration

RecordType: TYPE = [# id: REAL, age: INT, info: MyType #];

The order of the fields in a record type is meaningful:
permuting the field names gives a different type.

Note that record types are non-recursive.
For instance, it is not possible to declare a record type called <code>Person</code> containing
a field of type <code>Person</code>.
Recursive types are provided in CVC4 by the more general inductive data types.
(As a matter of fact, both record and tuple types are implemented internally as inductive data types.)

==== Inductive Data Types ====

Inductive data types in CVC4 are similar to inductive data types of functional languages.
They can be parametric or not.

===== Non-Parametric Data Types =====

Non-parametric data types are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1 & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2 & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types, including any <math>A_i</math>.
Such declarations define the data types <math>A_1, \ldots, A_n</math>.
For each data type <math>A_i</math> they introduce:

* constructor symbols <math>cons</math> of type <math>(T_1, \ldots, T_k) \to \mathit{type\_name}_i</math>,
* selector symbols <math>\mathit{sel}_j</math> of type <math>\mathit{type\_name}_i \to T_j</math>, and
* tester symbols <math>\mathit{is\_cons}</math> of type <math>\mathit{type\_name}_i \to \mathrm{BOOLEAN}</math>.

Note that permitting more than one data type to be defined in the same declarations allows
the definition of mutually recursive types.

% simple enumeration type

% implicitly defined are the testers: is_red, is_yellow and is_blue
% (similarly for the other data types)

DATATYPE
PrimaryColor = red | yellow | blue
END;

% infinite set of pairwise distinct values ..., v(-1), v(0), v(1), ...

DATATYPE
Id = v (id: INT)
END;

% ML-style integer lists

DATATYPE
IntList = nil | ins (head: INT, tail: IntList)
END;

% AST for lamba calculus

DATATYPE
Term = var (index: INT)
| apply (arg_1: Term, arg_2: Term)
| lambda (arg: INT, body: Term)
END;

% Trees

DATATYPE
Tree = tree (value: REAL, children: TreeList),
TreeList = nil_tl
| ins_tl (first_t1: Tree, rest_t1: TreeList)
END;

Constructor, selector and tester symbols defined for a data type have global scope.
So, for example, it is not possible for two different data types to use
the same name for a constructor.

An inductive data type is interpreted as a term algebra constructed by the constructor symbols
over some sets of generators.
For example, the type <code>IntList</code> defined above is interpreted as the set
of all terms constructed with <code>nil</code> and <code>ins</code> over the integers.

===== Parametric Data Types =====

Parametric data types are infinite families of (non-parametric) data types
with each family parametrized by one or more type variables.
They are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1[X_{1,1}, \ldots, X_{1,p_1}] & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2[X_{2,1}, \ldots, X_{2,p_2}] & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n[X_{n,1}, \ldots, X_{n,p_n}] & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name parametrized by the type variables <math>X_{i,1}, \ldots, X_{i,p_i}</math>
and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types,
possibly parametrized by <math>X_1, \ldots, X_p</math>, including any <math>A_i</math>.

% Parametric pairs
DATATYPE
Pair[X, Y] = pair (first: X, second: Y)
END;

% Parametric lists

DATATYPE
List[X] = nil | cons (head: X, tail: List[X])
END;

% Parametric trees using the list type above

DATATYPE
Tree[X] = node (value: X, children: List[Tree[X]]),
END;

The declarations above define infinitely many types of the form
Pair[S,T], List[T] and Tree[T] where S and T are first-order types.
Note that the identifier <code>List</code> above, for example, by itself does not denote a type.
In contrast, the terms <code>List[Real]</code>, <code>List[List[Real]]</code>, <code>List[Tree[INT]]</code>,
and so on do.

===== Restriction to Inductive Types =====

By adopting a term algebra semantics, CVC4 allows only ''inductive'' data types,
that is, data types whose values are essentially (labeled, ordered) finite trees.
Infinite structures such as streams or even finite but cyclic ones
such as circular lists are then excluded.
For instance, none of the following declarations define inductive data types,
and are rejected by CVC4:

DATATYPE
IntStream = s (first:INT, rest: IntStream)
END;

DATATYPE
RationalTree = node1 (child: RationalTree)
| node2 (left_child: RationalTree, right_child:RationalTree)
END;

DATATYPE
T1 = c1 (s1: T2),
T2 = c2 (s2: T1)
END;

In concrete, a declaration of <math>n \geq 1</math> datatypes <math>T_1, \ldots, T_n</math> will be rejected if for any one of the types <math>T_1, \ldots, T_n</math>, it is impossible to build a finite term of that type using only the constructors of <math>T_1, \ldots, T_n</math> and free constants of type other than <math>T_1, \ldots, T_n</math>.

Inductive data types are the only types where the user also chooses names for the built-in operations to:

* construct a value of the type (with the constructors),
* extract components from a value (with the selectors), or
* check if a value was constructed with a certain constructor or not (with the testers).

For all the other types, CVC4 provides predefined names for the built-in operations on the type.

=== Function Types ===

Function (<math>\to</math>) types are created by the mixfix type constructors
<center>
<math>
\begin{array}{l}
\_ \to \_ \\[1ex] (\ \_\ ,\ \_\ ) \to \_
\\[1ex] (\ \_\ ,\ \_\ ,\ \_\ ) \to \_
\\[1ex] \ldots
\end{array}
</math>
</center>
whose arguments can be instantiated by any first-order type.

% Function type declarations

UnaryFunType: TYPE = INT -> REAL;

BinaryFunType: TYPE = (REAL, REAL) -> ARRAY REAL OF REAL;

TernaryFunType: TYPE = (REAL, BITVECTOR(4), INT) -> BOOLEAN;

A function type of the form <math>(T_1, \ldots, T_n) \to T</math> with <math>n > 0</math> is interpreted as the set of all ''total'' functions from the Cartesian product <math>T_1 \times \cdots \times T_n</math> to <math>T</math>.

The example above also shows how to introduce type names.
A name like <code>UnaryFunType</code> above is just an abbreviation for the type <math>\mathrm{INT} \to \mathrm{REAL}</math> and can be used interchangeably with it.

In general, any type defined by a type expression <code>E</code> can be given a name with the declaration:

name : TYPE = E;

=== Type Checking ===

In CVC4, formulas and terms are statically typed at the level of types
(as opposed to subtypes) according to the usual rules of first-order many-sorted logic,
with the main difference that formulas are just terms of type <math>BOOLEAN</math>:

* each variable has one associated first-order type,
* each constant symbol has one or more associated first-order types,
* each function symbol has one or more associated function types,
* the type of a term consisting just of a variable is the type associated to that variable,
* the type of a term consisting just of a constant symbol is the type associated to that constant symbol,
* the term obtained by applying a function symbol <math>f</math> to the terms <math>t_1, \ldots, t_n</math> is <math>T</math> if <math>f</math> has type <math>(T_1, \ldots, T_n) \to T</math> and each <math>t_i</math> has type <math>T_i</math>.

Attempting to enter an ill-typed term will result in an error.

Another significant difference with standard many-sorted logic is that
some built-in symbols are parametrically polymorphic.
For instance, the function symbol for extracting the element of any array has
type <math>(\mathit{ARRAY}\ T_1\ \mathit{OF}\ T_2,\; T_1) \to T_2</math>
for all first-order types <math>T_1, T_2</math>.

==== Type Ascription ====

By the type inference rules above some terms might have more than one type.
This can happen with terms built with polymorphic data type constructors
that have more than one return type for the same input type.
In that case, a type ascription operator (<code>::</code>) must be applied
to the constructor to specify the intended return type.

DATATYPE [X]
List[X] = nil | cons (head: X, tail: List[X])
END;

ASSERT y = cons(1, nil::List[REAL]);

DATATYPE [X, Y]
Union[X, Y] = left(val_l: X) | right(val_r: Y)
END;

ASSERT y = left::Union[BOOLEAN, REAL](TRUE);

The constant symbol <math>\mathrm{nil}</math> declared above has infinitely many types
(<math>\mathrm{List}[\mathrm{REAL}]</math>, <math>\mathrm{List}[\mathrm{BOOLEAN}]</math>,
<math>\mathrm{List}[[\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{List}[\mathrm{List}[\mathrm{REAL}]]</math>, ...)
CVC4's type checker requires the user to indicate explicitly the type
of each occurrence of <code>nil</code> in a term.
Similarly,
the injection operator <code>left</code> has infinitely many return types
for the same input type, for instance:
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{REAL}]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, [\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{List}[\mathrm{REAL}]]</math>,
and so on.
Applications of <code>left</code> need to specify the intended returned typed, as shown above.

== Terms and Formulas ==

In addition to type expressions, CVC4 has expressions for terms and for formulas
(i.e., terms of type <math>\mathrm{BOOLEAN}</math>).
By and large, these are standard first-order terms built out of typed variables,
predefined theory-specific operators, free (i.e., user-defined) function symbols,
and quantifiers.
Extensions include an if-then-else operator, lambda abstractions, and local symbol
declarations, as illustrated below.
Note that these extensions still keep CVC4's language first-order.
In particular, lambda abstractions are restricted to take and return only terms of
a first-order type.
Similarly, variables can only be of a first-order type.

A number of built-in function symbols (for instance, the arithmetic ones) are used
as infix operators. All user-defined symbols are used as prefix ones.

User-defined, i.e., free, function symbols include ''constant symbols'' and
''predicate symbols'', respectively nullary function symbols and function symbols
with a <math>\mathrm{BOOLEAN}</math> return type.
These symbols are introduced with global declarations of the form
<math> f_1, \ldots, f_m: T;</math>
where <math>m > 0</math>, <math>f_i</math> are the names of the symbols and
<math>T</math> is their type:

% integer constants

a, b, c: INT;

% real constants

x, y, z: REAL;

% unary function

f1: REAL -> REAL;

% binary function

f2: (REAL, INT) -> REAL;

% unary function with a tuple argument

f3: [INT, REAL] -> BOOLEAN;

% binary predicate

p: (INT, REAL) -> BOOLEAN;

% Propositional "variables"

P, Q; BOOLEAN;

Like type declarations, function symbol declarations like the above have global scope
and must be unique.
In other words, it is not possible to declare a function symbol globally more than once
in the same lexical scope.
This entails among other things that globally-defined free symbols cannot be overloaded
with different types and that theory symbols cannot be redeclared globally as free symbols.

=== Global symbol definitions ===

As with types, a function symbol can be defined as the name of another term
of the corresponding type.
With constant symbols, this is done with a declaration of the form <math>f:T = t;</math> :

c: INT;

i: INT = 5 + 3*c; % i is effectively a shorthand for 5 + 3*c

j: REAL = 3/4;

t: [REAL, INT] = (2/3, -4);

r: [# key: INT, value: REAL #] = (# key := 4, value := (c + 1)/2 #);

f: BOOLEAN = FORALL (x:INT): x <= 0 OR x > c ;

A restriction on constants of type <math>\mathit{BOOLEAN}</math> is that their value
can only be a closed formula, that is, a formula with no free variables.

A term and its name can be used interchangeably in later expressions.
Named terms are often useful for shared subterms (terms used several times in different places)
since their use can make the input exponentially more concise.
Named terms are processed very efficiently by CVC4.
It is much more efficient to associate a complex term with a name directly rather than
to declare a constant and later assert that it is equal to the same term.
This point is explained in more detail later in section [[Commands | Commands]].

More generally, in CVC4 one can associate a term to function symbols of any arity.
For non-constant function symbols this is done with a declaration of the form

<center>
<math>f:(T_1, \ldots, T_n) \to T = \mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t\;;</math>
</center>

where <math>t</math> is any term of type <math>T</math> with free variables
in <math>\{x_1, \ldots, x_n\}</math>.
The lambda binder has the usual semantics and conforms to the usual lexical scoping rules:
within the term <math>t</math> the declaration of the symbols <math>x_1, \ldots, x_n</math>
as local variables of respective type <math>T_1, \ldots, T_n</math> hides any previous
declarations of those symbols that are in scope.

As a general shorthand, when <math>k</math> consecutive types
<math>T_i, \ldots, T_{i+k-1}</math> in the lambda expression
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t</math> are identical, the syntax
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x_i,\ldots, x_{i+k-1}:T_i,\ldots, x:T_n): t</math>
can also be used.

% Global declaration of x as a unary function symbol

x: REAL -> REAL;

% Local declarations of x as variable (hiding the global one)

f: REAL -> REAL = LAMBDA (x: REAL): 2*x + 3;

p: (INT, INT) -> BOOLEAN = LAMBDA (x,i: INT): i*x - 1 > 0;

g: (REAL, INT) -> [REAL, INT] = LAMBDA (x: REAL, i:INT): (x + 1, i - 3);

Note that lambda definitions are not recursive:
the symbol being defined cannot occur in the body of the lambda term.
They should be understood as macros.
For instance, any occurrence of the term <math>f(t)</math>
where <math>f</math> is as defined above will be treated
as if it was the term <math>(2*t + 3)</math>.

=== Local symbol definitions ===

Constant and function symbols can also be declared locally anywhere within a term
by means of a let binder.
This is done with a declaration of the form

<center>
<math>
\mathrm{LET}\ f = s \ \mathrm{IN}\ t ;
</math>
</center>

where <math>t</math> is a term with no free variables, possibly a lambda term.
Let binders can be nested arbitrarily and follow the usual lexical scoping rules.
The following general form
<center>
<math>
\mathrm{LET}\ f_1 = t_1, f_2 = t_2, \ldots, f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>
can used as a shorthand for
<center>
<math>
\mathrm{LET}\ f_1 = t_1\ \mathrm{IN}\
\mathrm{LET}\ f_2 = t_2\ \mathrm{IN}\
\ldots \
\mathrm{LET}\ f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>

t: REAL =
LET x1 = 42,
g = LAMBDA(x:INT): x + 1,
x2 = 2*x1 + 7/2
IN
(LET x3 = g(x1) IN x3 + x2) / x1;

Note that the same symbol = is used, unambiguously, in the syntax of global declarations,
let declarations, and as a predicate symbol.

'''Note:'''
A <math>\mathrm{LET}</math> term with a multiple symbols defines them sequentially.
A parallel version of the <math>\mathrm{LET}</math> construct will be introduced in a later version.

== Built-in theories and their symbols ==

In addition to user-defined symbols, CVC4 terms can use a number of predefined symbols:
the logical symbols, such as <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, etc.,
as well as theory symbols, function symbols belonging to one of the built-in theories.
They are described next, with the theory symbols grouped by theory.

=== Logical Symbols ===

The logical symbols in CVC4's language include
the equality and disequality predicate symbols, respectively written as = and /=,
the multiarity disequality symbol <math>\mathrm{DISTINCT}</math>,
together with the logical constants <math>\mathrm{TRUE}</math>, <math>\mathrm{FALSE}</math>,
the connectives <math>\mathrm{NOT}</math>, <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, <math>\mathrm{XOR}</math>, <math>\Rightarrow</math>, <math>\Leftrightarrow</math>, and
the first-order quantifiers <math>\mathrm{EXISTS}</math> and <math>\mathrm{FORALL}</math>,
all with the standard many-sorted logic semantics.

The binary connectives have infix syntax and type
<math>(\mathrm{BOOLEAN},\mathrm{BOOLEAN}) \to \mathrm{BOOLEAN}</math>.
The symbols = and /=, which are also infix, are instead parametrically polymorphic,
having type <math>(T,T) \to \mathrm{BOOLEAN}</math>
for every first-order type <math>T</math>.
They are interpreted respectively as the identity relation and its complement.

The DISTINCT symbol is both overloaded and polymorphic.
It has type <math>(T,...,T) \to \mathrm{BOOLEAN}</math>
for every sequence <math>(T,...,T)</math> of length <math>n > 0</math>
and first-order type <math>T</math>.
For each <math>n > 0</math>, it is interpreted as the relation
that holds exactly for tuples of pairwise distinct elements.

The syntax for quantifiers is similar to that of the lambda binder.

Here is an example of a formula built just of these logical symbols and variables:

A, B: TYPE;

q: BOOLEAN = FORALL (x,y: A, i,j,k: B):
i = j AND i /= k => EXISTS (z: A): x /= z OR z /= y;

Binding and scoping of quantified variables follows the same rules as
in let expressions.
In particular, a quantifier will shadow in its scope any constant and function symbols
with the same name as one of the variables it quantifies:

A: TYPE;
i, j: INT;

% The first occurrence of i and of j in f are constant symbols,
% the others are variables.

f: BOOLEAN = i = j AND FORALL (i,j: A): i = j OR i /= j;

Optionally, it is also possible to specify instantiation patterns
for quantified variables.
The general syntax for a quantified formula <math>\psi</math> with patterns is

<center>
<math>
Q\;(x_1:T_1, \ldots, x_k:T_k):\; p_1: \ldots\; p_n:\; \varphi
</math>
</center>

where <math>n \geq 0</math>, <math>Q</math> is
either <math>\mathrm{FORALL}</math> or <math>\mathrm{EXISTS}</math>,
<math>\varphi</math> is a term of type <math>\mathrm{BOOLEAN}</math>,
and each of the <math>p_i</math>'s,
a pattern for the quantifier <math>Q\;(x_1:T_1, \ldots, x_k:T_k)</math>, has the form

<center>
<math>
\mathrm{PATTERN}\; (t_1, \ldots, t_m)
</math>
</center>

where <math>m > 0</math> and <math>t_1, \ldots, t_m</math> are
arbitrary binder-free terms (no lets, no quantifiers).
Those terms can contain (free) variables, typically, but not exclusively,
drawn from <math>x_1, \ldots, x_k</math>.
(Additional variables can occur if <math>\psi</math> occurs in a bigger formula
binding those variables.)

A: TYPE;
b, c: A;
p, q: A -> BOOLEAN;
r: (A, A) -> BOOLEAN;

ASSERT FORALL (x0, x1, x2: A):
PATTERN (r(x0, x1), r(x1, x2)):
(r(x0, x1) AND r(x1, x2)) => r(x0, x2) ;

ASSERT FORALL (x: A):
PATTERN (r(x, b)):
PATTERN (r(x, c)):
p(x) => q(x) ;

ASSERT EXISTS (y: A):
FORALL (x: A):
PATTERN (r(x, y), p(y)):
r(x, y) => q(x) ;

Patterns have no logical meaning:
adding them to a formula does not change its semantics.
Their purpose is purely operational, as explained in
the [[#Instantiation Patterns | Instantiation Patterns]] section.

In addition to these constructs, CVC4 also has a general mixfix conditional operator
of the form

<center>
<math>
\mathrm{IF}\ b\ \mathrm{THEN}\ t\ \mathrm{ELSIF}\ b_1\ \mathrm{THEN}\ t_1\ \ldots\ \mathrm{ELSIF}\ b_n\ \mathrm{THEN}\ t_n\ \mathrm{ELSE}\ t_{n+1}\ \mathrm{ENDIF}
</math>
</center>

with <math>n \geq 0</math> where
<math>b, b_1, \ldots, b_n</math> are terms of type <math>\mathrm{BOOLEAN}</math> and
<math>t, t_1, \ldots, t_n, t_{n+1}</math> are terms of the same first-order type <math>T</math>:

% Conditional term
x, y, z, w: REAL;

t: REAL =
IF x > 0 THEN y
ELSIF x >= 1 THEN z
ELSIF x > 2 THEN w
ELSE 2/3 ENDIF;

=== User-defined Functions and Types ===

The theory of user-defined functions,also know in the SMT literature as
the theory ''Equality over Uninterpreted Functions'', or ''EUF'', is in effect
a family of theories of equality parametrized by the basic types and the free symbols
a user can define during a run of CVC4.

This theory has no built-in symbols (other than the logical ones).
Its types consist of ''all and only'' the user-defined types.
Its function symbols consist of ''all and only'' the user-defined free symbols.

=== Arithmetic ===

The real arithmetic theory has two types:
<math>\mathrm{REAL}</math> and <math>\mathrm{INTEGER}</math>
with the latter a subtype of the first.
Its built-in symbols for the usual arithmetic constants
and operators over the type <math>\mathrm{REAL}</math>, each with the expected type:
all numerals 0, 1, ..., as well as - (both unary and binary), +, *, /, <, >, <=, >=.
Application of the binary symbols are in infix form.
Note that + is only binary, and so an expression such as +4 is ill-formed.

Rational values can be expressed in decimal or fractional format,
e.g., 0.1, 23.243241, 1/2, 3/4, and so on.
A leading 0 is mandatory for decimal numbers smaller than one
(e.g., the syntax .3 cannot be used as a shorthand for 0.3).
However, a trailing 0 is ''not'' required for decimals that are whole numbers
(e.g., 3. is allowed as a shorthand for 3.0).
The size of the numerals used in the representation of natural and rational numbers
is unbounded; more accurately, bounded only by the amount of available memory.

=== Bit vectors ===

=== Arrays ===

The theory of arrays is a parametric theory of (total) unary maps.
It comes equipped with mixfix polymorphic selection and update operators, respectively
<center>
<math>\_[\_]</math> and <math>\_\ \mathrm{WITH}\ [\_]\ := \_</math> .
</center>
The semantics of these operators is the expected one:
for all first-order types <math>T_1</math> and <math>T_2</math>,
if <math>a</math> is of type <math>\mathrm{ARRAY}\ T_1 \mathrm{OF}\ T_2</math>,
<math>i</math> is of type <math>T_1</math>, and
<math>v</math> is of type <math>T_2</math>,
* <math>a[i]</math> denotes the value that <math>a</math> associates to index <math>i</math>,
* <math>a\ \mathrm{WITH}\ [i]\ := v</math> denotes a map that associates <math>v</math> to index <math>i</math> and is otherwise identical to <math>a</math>.
Sequential updates can be chained with the shorthand syntax
<math>\_\ \mathrm{WITH}\ [\_]\ := \_, \ldots, [\_]\ := \_</math>.

A: TYPE = ARRAY INT OF REAL;
a: A;
i: INT = 4;

% selection:

elem: REAL = a[i];

% update

a1: A = a WITH [10] := 1/2;

% sequential update
% (syntactic sugar for (a WITH [10] := 2/3) WITH [42] := 3/2)

a2: A = a WITH [10] := 2/3, [42] := 3/2;

Since arrays are just maps, equality between them is extensional, that is,
for two arrays of the same type to be different they have to map at least one
index to differ values.

=== Data types ===

The theory of inductive data types is in fact a family of theories parametrized
by a data type declaration specifying constructors and selectors
for one or more user-defined data types.

No built-in operators other than equality and disequality are provided
for this family in the native language.
Each user-provided data type declaration, however, generates constructor, selector and tester operators
as described in the [[#Inductive Data Types | Inductive Data Types]] section.

=== Tuples and Records ===

Semantically both records and tuples can be seen as special instances
of inductive data types.
CVC4 implements them internally indeed as data types.
In essence, a record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math>
is encoded as a data type of the form

<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\ \ \mathrm{Record} = \mathit{rec}(l_0:T_0, \ldots, l_n:T_n) \\
\mathrm{END};
\end{array}
</math>
</center>

Tuples of length <math>n</math> are in turn special cases of records whose field names are
the numerals from <math>0</math> to <math>n-1</math>.

Externally, tuples and records have their own syntax for constructor and selector operators.
* Records of type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> have the associated record constructor <math>(\#\ l_0 := \_,\; \ldots,\; l_n := \_\ \#)</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.
* Tuples of type <math>[\ T_0, \ldots, T_n\ ]</math> have the associated tuple constructor <math>(\ \_,\; \ldots,\; \_\ )</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.

The selector operators on records and tuples follows a dot notation syntax.

% Record construction and field selection
Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);
k: INT = x.key;
v: REAL = x.weight;

% Tuple construction and projection
y: [REAL, INT, REAL] = ( 4/5, 9, 11/9 );
first_elem: REAL = y.0;
third_elem: REAL = y.2;

Differently from data types, records and tuples are also provided with built-in update operators similar in syntax and semantics to the update operator for arrays.
More precisely, for each record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .l_i\ := \_
</math>
</center>

The operator maps a record <math>r</math> of that type and a value <math>v</math>
of type <math>T_i</math> to the record that stores <math>v</math> in field <math>l_i</math>
and is otherwise identical to <math>r</math>.
Analogously, for each tuple type <math>[T_0, \ldots, T_n]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .i\ := \_
</math>
</center>

with similar semantics.

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = x WITH .weight := 48;

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = y WITH .1 := 3;

Updates to a nested component can be combined in a single WITH operator:

Cache: TYPE = ARRAY [0..100] OF [# addr: INT, data: REAL #];
State: TYPE = [# pc: INT, cache: Cache #];

s0: State;
s1: State = s0 WITH .cache[10].data := 2/3;

Note that, differently from updates on arrays, tuple and record updates are
just additional syntactic sugar.
For instance, the record <code>x1</code> and tuple <code>y1</code> defined above
could have been equivalently defined as follows:

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = (# key := x.key, weight := 48 #);

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = ( y.0, 3, y.1 );

== Commands ==

In addition to declarations of types and function symbols,
the CVC4 native language contains the following commands:

* <math>\mathrm{ASSERT}\ F</math> -- Add the formula <math>F</math> to the current logical context <math>\Gamma</math>.
* [[#CHECKSAT|<math>\mathrm{CHECKSAT}\ F</math>]] -- Check if the formula <math>F</math> is satisfiable in the current logical context (<math>\Gamma \not\models_T \mathrm{NOT}\ F</math>).
* <math>\mathrm{CONTINUE}</math> -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, search for a counter-example different from the current one.
* [[#COUNTEREXAMPLE|<math>\mathrm{COUNTEREXAMPLE}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print the context that is a witness for invalidity/satisfiability.
* [[#COUNTERMODEL|<math>\mathrm{COUNTERMODEL}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print a model that makes the formula invalid/satisfiable. The model is provided in terms of concrete values for each free symbol.
* <math>\mathrm{OPTION}\ o\ v</math> -- Set the command-line option flag <math>o</math> to value <math>v</math>. The argument <math>o</math> is provide as a string literal enclosed in double-quotes and <math>v</math> as an integer value.
* <math>\mathrm{POP}</math> -- Equivalent to <math>\mathrm{POPTO}\ 1</math>
* [[#PUSH and POPTO|<math>\mathrm{POPTO}\ n</math>]] -- Restore the system to the state it was in right before the most recent call to <math>\mathrm{PUSH}</math> made from assertion (stack) level <math>n</math>. Note that the current assertion level is printed as part of the output of the <math>\mathrm{WHERE}</math> command.
* [[#PUSH and POPTO|<math>\mathrm{PUSH}</math>]] -- Save (checkpoint) the current state of the system.
* [[#QUERY|<math>\mathrm{QUERY}\ F</math>]] -- Check if the formula <math>F</math> is valid in the current logical context (<math>\Gamma\models_T F</math>).
* [[#RESTART|<math>\mathrm{RESTART}\ F</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, repeat the check but with the additional assumption <math>F</math> in the context.
* <math>\mathrm{PRINT}\ t</math> -- Parse and print back the term <math>t</math>.
* <math>\mathrm{TRANSFORM}\ t</math> -- Simplify the term <math>t</math> and print the result.
* <math>\mathrm{WHERE}</math> -- Print all the formulas in the current logical context <math>\Gamma</math>.

The remaining commands take a single argument, given as a string literal enclosed in double-quotes.

* <math>\mathrm{ECHO}\ s</math> -- Print string <math>s</math>
* <math>\mathrm{INCLUDE}\ f</math> -- Read commands from file <math>f</math>.
* <math>\mathrm{TRACE}\ f</math> -- Turn on tracing for the debug flag <math>f</math>.
* <math>\mathrm{UNTRACE}\ f</math> -- Turn off tracing for the debug flag <math>f</math>.

Here, we explain some of the above commands in more detail.

=== QUERY ===

The command <math>\mathrm{QUERY}\ F</math> invokes the core functionality of CVC4 to check
the validity of the formula <math>F</math> with respect to the assertions made thus far,
which constitute the context <math>\Gamma</math>.
The argument <math>F</math> must be well typed term of type <math>\mathrm{BOOLEAN}</math>,
as described in [[#Terms and Formulas | Terms and Formulas]].

The execution of this command always terminates and produces one of three possible answers:
<code>valid</code>, <code>invalid</code>, and <code>unknown</code>.

* A <code>valid</code> answer indicates that <math>\Gamma \models_T F</math>. After a query returning such an answer, the logical context <math>\Gamma</math> is exactly as it was before the query.
* An <code>invalid</code> answer indicates that <math>\Gamma \not\models_T F</math>, that is, there is a model of the background theory <math>T</math> that satisfies <math>\Gamma \cup \{\mathrm{NOT}\ F\}</math>. When <math>\mathrm{QUERY}\ F</math> returns <code>invalid</code>, the logical context <math>\Gamma</math> is augmented with a set <math>\Delta</math> of ground (i.e., variable-free) literals such that <math>\Gamma\cup\Delta</math> is satisfiable in <math>T</math>, but <math>\Gamma\cup\Delta\models_T \mathrm{NOT}\ F</math>. In fact, in this case <math>\Delta</math> ''propositionally entails'' <math>\mathrm{NOT}\ F</math>, in the sense that, every truth assignment to the literals of <math>\Delta</math> that satisfies <math>\Delta</math> falsifies <math>F</math>. We call the new context <math>\Gamma\cup\Delta</math> a ''counterexample'' for <math>F</math>.
* An <code>unknown</code> answer is similar to an <code>invalid</code> answer in that additional literals are added to the context which propositionally entail <math>\mathrm{NOT}\ F</math>. The difference in this case is that CVC4 cannot guarantee that <math>\Gamma\cup\Delta</math> is actually satisfiable in <math>T</math>.

CVC4 may report <code>unknown</code> when the context or the query contains
non-linear arithmetic terms or quantifiers.
In all other cases, it is expected to be sound and complete,
i.e., to report <code>Valid</code> if <math>\Gamma \models_T F</math>
and <code>Invalid</code> otherwise.

After an <code>invalid</code> (resp. <code>unknown</code>) answer,
counterexamples (resp. possible counterexamples) can be obtained with
a <math>\mathrm{WHERE}</math>, <math>\mathrm{COUNTEREXAMPLE}</math>,
or <math>\mathrm{COUNTERMODEL}</math> command.


Since the <math>\mathrm{QUERY}</math> command may modify
the current context, if one needs to check several formulas in a row
in the same context, it is a good idea to surround every
query by a <math>\mathrm{PUSH}</math> and <math>\mathrm{POP}</math> invocation
in order to preserve the context:

PUSH;
QUERY <formula>;
POP;

=== CHECKSAT ===

The command <math>\mathrm{CHECKSAT}\ F</math> behaves identically
to <math>\mathrm{QUERY}\ \mathrm{NOT}\ F</math>.

=== RESTART ===

The command <math>\mathrm{RESTART}\ F</math> can only be invoked after an invalid query.
For example, in an interactive setting:

QUERY <formula>;

CVC4> invalid

RESTART <formula2>;

Functionally, the behavior of the above command sequence is identical to the following:

PUSH;
QUERY <formula>;
POP;
ASSERT <formula2>;
QUERY <formula>;

The advantage of using the <math>\mathrm{RESTART}</math> command is that
the first command sequence may be executed much more efficiently that the second.
The reason is that with <math>\mathrm{RESTART}</math> CVC4 will re-use
what it has learned while answering the previous query rather than starting
over from scratch.

=== COUNTERMODEL ===

[More]

=== COUNTEREXAMPLE ===

[More]

=== PUSH and POPTO ===

CVC4's context can be understood as being stratified in ''assertion levels''
which are added and removed in a LIFO fashion.
The system starts at assertion level 0 and every execution of the PUSH command creates a new assertion level after the current one.
Each formula added to the context either by the user, via an ASSERT command, or internally by the system
is added to the most recent assertion level.
Executing POPTO n removes from the context the most recent n assertion levels and all the formulas in them.
So, for instance, POP 1 has the effect of retracting all formulas in the current assertion level (and removing that level).
Note that formulas at assertion level 0 cannot be retracted.

Note: Symbol declarations are always added at assertion level zero. So they are not affected by POPTO commands.

== Instantiation Patterns ==

CVC4 processes each universally quantified formula in the current context
by adding instances of the formula obtained by replacing its universal variables
with ground terms.
Patterns restrict the choice of ground terms for the quantified variables,
with the goal of controlling the potential explosion of ground instances.
In essence, adding patterns to a formula is a way for the user to tell CVC4
to focus only on certain instances which, in the user's opinion, will be
most helpful during a proof.

In more detail, patterns have the following effect on formulas that are found
in the logical context or get added to it later while CVC4 is trying to prove
the validity of some formula <math>F</math>.

If a formula in the current context starts with an existential quantifier,
CVC4 ''Skolemizes'' it, that is, replaces it in the context with the formula
obtained by substituting the existentially quantified variables
by fresh constants and dropping the quantifier.
Any patterns for the existential quantifier are simply ignored.

If a formula starts with a universal quantifier
<math>\mathrm{FORALL}\; (x_1:T_1, \ldots, x_n:T_n)</math>,
CVC4 adds to the context a number of instances of the formula,
with the goal of using them to prove the query <math>F</math> valid.
An instance is obtained by replacing each <math>x_i</math> with a ground term
of the same type occurring in one of the formulas in the context,
and dropping the universal quantifier.
If <math>x_i</math> occurs in a pattern
<math>\mathrm{PATTERN}\; (t_1, \ldots, t_m)</math> for the quantifier,
it will be instantiated only with terms obtained by simultaneously matching
all the terms in the pattern against ground terms in the current context
<math>\Gamma</math>.

Specifically, the matching process produces one or more substitutions
<math>\sigma</math> for the variables in <math>(t_1, \ldots, t_m)</math>
which satisfy the following invariant:
for each <math>i = 1, \ldots, m</math>, <math>\sigma(t_i)</math> is
a ground term and there is a ground term <math>s_i</math> in <math>\Gamma</math>
such that <math>\Gamma \models_T \sigma(t_i) = s_i</math>.
The variables of <math>(x_1:T_1, \ldots, x_n:T_n)</math> that occur
in the pattern are instantiated only with those substitutions
(while any remaining variables are instantiated arbitrarily).

The Skolemized version or the added instances of a context formula may themselves
start with a quantifier.
The same instantiation process is applied to them too, recursively.

Note that the matching mechanism is not limited to syntactic matching
but is modulo the equations asserted in the context.
Because of decidability and/or efficiency limitations, the matching process
is not exhaustive.
CVC4 will typically miss some substitutions that satisfy the invariant above.
As a consequence, it might fail to prove the validity of the query formula
<math>F</math>, which makes CVC4 incomplete for contexts containing
quantified formulas.
It should be noted though that exhaustive matching, which can be achieved
simply by not specifying any patterns, does not yield completeness anyway
since the instantiation of universal variables is still restricted
to just the ground terms in the context,
whereas in general additional ground terms might be needed.

CVC4's native language

2013-02-13T05:52:01Z

Tinelli: /* The BOOLEAN Type */

= CVC4 native input language =

The native input language consists of a sequence of symbol declarations and commands, each followed by a semicolon (<code>;</code>).

Any text after the first occurrence of a percent character and to the end of the current line is a comment:

%%% This is a native language comment

== Type System ==

CVC4's type system includes a set of built-in types which can be expanded with additional user-defined types.

The type system consists of ''first-order'' types, ''subtypes'' of first-order types, and ''higher-order'' types, all of which are interpreted as sets.
For convenience, we will sometimes identify below the interpretation of a type with the type itself.

First-order types consist of basic types and structured types. The basic types are <math>\mathrm{BOOLEAN}</math>, <math>\mathrm{REAL}</math>, <math>\mathrm{BITVECTOR}(n)</math> for all <math>n > 0</math>, as well as user-defined basic types (also called uninterpreted types).
The structured types are array, tuple, record types, and ML-style user-defined (inductive) datatypes.

'''Note:''' Currently, subtypes consist only of the built-in subtype <math>\mathrm{INT}</math> of <math>\mathrm{REAL}</math>.

Support for CVC3-style user-defined subtypes will be added in a later release.

Function types are the only higher-order types.
More precisely, they are just second-order types
since function symbols in CVC4, both built-in and user-defined, can take as argument or return only values of
a first-order type.

=== Basic Types ===

==== The BOOLEAN Type ====

The <math>\mathrm{BOOLEAN}</math> type is interpreted as the two-element set of Boolean values
<math>\{\mathrm{TRUE},\; \mathrm{FALSE}\}</math>.

'''Note:''' CVC4's treatment of this type differs from CVC3's where <math>\mathrm{BOOLEAN}</math> is used only as the type of formulas, but not as value type. CVC3 follows the two-tiered structure of classical first-order logic
which distinguishes between formulas and terms, and allows terms to occur in formulas but not vice versa (with the exception of the IF-THEN-ELSE construct).
CVC4 drops the distinction between terms and formulas and defines the latter just as terms of type <math>\mathrm{BOOLEAN}</math>. As such, formulas can occur as subterms of possibly non-Boolean terms.

Example:

% Boolean constants
a, b: BOOLEAN;

% REAL constants
x,y: REAL;

% Boolean-valued function, can be used as a predicate symbol
p: REAL -> BOOLEAN;
ASSERT a => p(x - y);

% Real-valued function with Boolean argument
f: BOOLEAN -> REAL;

% The argument of f can be a formula ...
ASSERT f(a OR b) > 0.3 OR p(x);

% ... even a quantified one
ASSERT y = f(FORALL (r: REAL): r < r + 1);

==== The REAL Type ====

The <math>\mathrm{REAL}</math> type is interpreted as the set of real numbers.

Note that these are the (infinite precision) mathematical reals,
not the floating point numbers.
Support for floating point types is planned for future versions.

x, y : REAL;
QUERY (( x <= y ) AND ( y <= x )) => ( x = y );

==== The INT Type ====

The <math>\mathrm{INT}</math> type is interpreted as the set of integer numbers
and is considered a subtype of <math>\mathrm{REAL}</math>.
The latter means in particular that it is possible to mix integer and real terms
in expressions without the need of an explicit ''upcasting'' operator.

Note that these are the (infinite precision) mathematical integers,
not the finite precision machine integers used in most programming languages.
The latter are modeled by [[ #Bitvectors | bit vector ]] types.

x, y : INT;
QUERY ((2 * x + 4 * y <= 1) AND ( y >= x)) => (x <= 0);
z : REAL;
QUERY (2 * x + z <= 3.5) AND (z >= 1);

==== Bit Vector Types ====

For every positive integer <math>n</math>, the type <math>\mathrm{BITVECTOR}(n)</math> is interpreted as the set of all bit vectors of size <math>n</math>.
A rich set of bit vector operators is supported.

==== User-defined Basic Types ====

Users can define new basic types
(often referred to as ''uninterpreted'' types in the SMT literature).
Each such type is interpreted as a set of unspecified cardinality
but disjoint from any other type.

User-defined basic types are created by declarations like the following:

% User declarations of basic types:

MyBrandNewType: TYPE;

Apples, Oranges: TYPE;

=== Structured Types ===

CVC4's structured types are divided into the following families.

==== Array Types ====

Array types are created by the mixfix type constructors <math>\mathrm{ARRAY}\ \_\ \mathrm{OF}\ \_</math>
whose arguments can be instantiated by any value type.

I : TYPE;

%% Array types:

% Arrays with indices from I and values from REAL
Array1: TYPE = ARRAY I OF REAL;

% Arrays with integer indices and array values
Array2: TYPE = ARRAY INT OF (ARRAY INT OF REAL);

% Arrays with integer pair indices and integer values
IntMatrix: TYPE = ARRAY [INT, INT] OF INT;

An array type of the form <math>\mathrm{ARRAY}\ T_1\ \mathrm{OF}\ T_2</math> is interpreted
as the set of all total maps from <math>T_1</math> to <math>T_2</math>.
The main difference with the function type <math>T_1 \to T_2</math> is that arrays,
contrary to functions, are first-class objects of the language, that is, values of an array
type can be arguments or results of functions.
Furthermore, array types come equipped with an update operation.

==== Tuple Types ====

Tuple types are created by the mixfix type constructors

<center>
<math>
\begin{array}{l} [\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ \ ,\ \_\ ] \\[1ex] \ldots \end{array}
</math>
</center>

whose arguments can be instantiated by any value type.

IntArray: TYPE = ARRAY INT OF INT;

% Tuple type declarations

RealPair: TYPE = [REAL, REAL]

MyTuple: TYPE = [ REAL, IntArray, [INT, INT] ];

A tuple type of the form <math>[T_1, \ldots, T_n]</math> is interpreted
as the Cartesian product <math>T_1 \times \cdots \times T_n</math>.

Note that while the types <math>(T_1, \ldots, T_n) \to T</math> and
<math>[T_1 \times \cdots \times T_n] \to T</math> are semantically equivalent,
they are operationally different in CVC4.
The first is the type of functions that take <math>n</math> arguments
of respective type <math>T_1</math>, <math>\ldots</math>, <math>T_n</math>,
while the second is the type of functions that take one argument of an <math>n</math>-tuple type.

==== Record Types ====

Similar to, but more general than tuple types, record types are created by type constructors of the form

<center>
<math>
[\#\ l_1: \_\ ,\ \ldots\ ,\ l_n: \_\ \#]
</math>
</center>

where <math>n > 0</math>, <math>l_1,\ldots, l_n</math> are field labels,
and the arguments can be instantiated with any first-order types.

MyType: TYPE;

% Record declaration

RecordType: TYPE = [# id: REAL, age: INT, info: MyType #];

The order of the fields in a record type is meaningful:
permuting the field names gives a different type.

Note that record types are non-recursive.
For instance, it is not possible to declare a record type called <code>Person</code> containing
a field of type <code>Person</code>.
Recursive types are provided in CVC4 by the more general inductive data types.
(As a matter of fact, both record and tuple types are implemented internally as inductive data types.)

==== Inductive Data Types ====

Inductive data types in CVC4 are similar to inductive data types of functional languages.
They can be parametric or not.

===== Non-Parametric Data Types =====

Non-parametric data types are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1 & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2 & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types, including any <math>A_i</math>.
Such declarations define the data types <math>A_1, \ldots, A_n</math>.
For each data type <math>A_i</math> they introduce:

* constructor symbols <math>cons</math> of type <math>(T_1, \ldots, T_k) \to \mathit{type\_name}_i</math>,
* selector symbols <math>\mathit{sel}_j</math> of type <math>\mathit{type\_name}_i \to T_j</math>, and
* tester symbols <math>\mathit{is\_cons}</math> of type <math>\mathit{type\_name}_i \to \mathrm{BOOLEAN}</math>.

Note that permitting more than one data type to be defined in the same declarations allows
the definition of mutually recursive types.

% simple enumeration type

% implicitly defined are the testers: is_red, is_yellow and is_blue
% (similarly for the other data types)

DATATYPE
PrimaryColor = red | yellow | blue
END;

% infinite set of pairwise distinct values ..., v(-1), v(0), v(1), ...

DATATYPE
Id = v (id: INT)
END;

% ML-style integer lists

DATATYPE
IntList = nil | ins (head: INT, tail: IntList)
END;

% AST for lamba calculus

DATATYPE
Term = var (index: INT)
| apply (arg_1: Term, arg_2: Term)
| lambda (arg: INT, body: Term)
END;

% Trees

DATATYPE
Tree = tree (value: REAL, children: TreeList),
TreeList = nil_tl
| ins_tl (first_t1: Tree, rest_t1: TreeList)
END;

Constructor, selector and tester symbols defined for a data type have global scope.
So, for example, it is not possible for two different data types to use
the same name for a constructor.

An inductive data type is interpreted as a term algebra constructed by the constructor symbols
over some sets of generators.
For example, the type <code>IntList</code> defined above is interpreted as the set
of all terms constructed with <code>nil</code> and <code>ins</code> over the integers.

===== Parametric Data Types =====

Parametric data types are infinite families of (non-parametric) data types
with each family parametrized by one or more type variables.
They are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1[X_{1,1}, \ldots, X_{1,p_1}] & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2[X_{2,1}, \ldots, X_{2,p_2}] & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n[X_{n,1}, \ldots, X_{n,p_n}] & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name parametrized by the type variables <math>X_{i,1}, \ldots, X_{i,p_i}</math>
and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types,
possibly parametrized by <math>X_1, \ldots, X_p</math>, including any <math>A_i</math>.

% Parametric pairs
DATATYPE
Pair[X, Y] = pair (first: X, second: Y)
END;

% Parametric lists

DATATYPE
List[X] = nil | cons (head: X, tail: List[X])
END;

% Parametric trees using the list type above

DATATYPE
Tree[X] = node (value: X, children: List[Tree[X]]),
END;

The declarations above define infinitely many types of the form
Pair[S,T], List[T] and Tree[T] where S and T are first-order types.
Note that the identifier <code>List</code> above, for example, by itself does not denote a type.
In contrast, the terms <code>List[Real]</code>, <code>List[List[Real]]</code>, <code>List[Tree[INT]]</code>,
and so on do.

===== Restriction to Inductive Types =====

By adopting a term algebra semantics, CVC4 allows only ''inductive'' data types,
that is, data types whose values are essentially (labeled, ordered) finite trees.
Infinite structures such as streams or even finite but cyclic ones
such as circular lists are then excluded.
For instance, none of the following declarations define inductive data types,
and are rejected by CVC4:

DATATYPE
IntStream = s (first:INT, rest: IntStream)
END;

DATATYPE
RationalTree = node1 (child: RationalTree)
| node2 (left_child: RationalTree, right_child:RationalTree)
END;

DATATYPE
T1 = c1 (s1: T2),
T2 = c2 (s2: T1)
END;

In concrete, a declaration of <math>n \geq 1</math> datatypes <math>T_1, \ldots, T_n</math> will be rejected if for any one of the types <math>T_1, \ldots, T_n</math>, it is impossible to build a finite term of that type using only the constructors of <math>T_1, \ldots, T_n</math> and free constants of type other than <math>T_1, \ldots, T_n</math>.

Inductive data types are the only types where the user also chooses names for the built-in operations to:

* construct a value of the type (with the constructors),
* extract components from a value (with the selectors), or
* check if a value was constructed with a certain constructor or not (with the testers).

For all the other types, CVC4 provides predefined names for the built-in operations on the type.

=== Function Types ===

Function (<math>\to</math>) types are created by the mixfix type constructors
<center>
<math>
\begin{array}{l}
\_ \to \_ \\[1ex] (\ \_\ ,\ \_\ ) \to \_
\\[1ex] (\ \_\ ,\ \_\ ,\ \_\ ) \to \_
\\[1ex] \ldots
\end{array}
</math>
</center>
whose arguments can be instantiated by any first-order type.

% Function type declarations

UnaryFunType: TYPE = INT -> REAL;

BinaryFunType: TYPE = (REAL, REAL) -> ARRAY REAL OF REAL;

TernaryFunType: TYPE = (REAL, BITVECTOR(4), INT) -> BOOLEAN;

A function type of the form <math>(T_1, \ldots, T_n) \to T</math> with <math>n > 0</math> is interpreted as the set of all ''total'' functions from the Cartesian product <math>T_1 \times \cdots \times T_n</math> to <math>T</math>.

The example above also shows how to introduce type names.
A name like <code>UnaryFunType</code> above is just an abbreviation for the type <math>\mathrm{INT} \to \mathrm{REAL}</math> and can be used interchangeably with it.

In general, any type defined by a type expression <code>E</code> can be given a name with the declaration:

name : TYPE = E;

=== Type Checking ===

In CVC4, formulas and terms are statically typed at the level of types
(as opposed to subtypes) according to the usual rules of first-order many-sorted logic,
with the main difference that formulas are just terms of type <math>BOOLEAN</math>:

* each variable has one associated first-order type,
* each constant symbol has one or more associated first-order types,
* each function symbol has one or more associated function types,
* the type of a term consisting just of a variable is the type associated to that variable,
* the type of a term consisting just of a constant symbol is the type associated to that constant symbol,
* the term obtained by applying a function symbol <math>f</math> to the terms <math>t_1, \ldots, t_n</math> is <math>T</math> if <math>f</math> has type <math>(T_1, \ldots, T_n) \to T</math> and each <math>t_i</math> has type <math>T_i</math>.

Attempting to enter an ill-typed term will result in an error.

Another significant difference with standard many-sorted logic is that
some built-in symbols are parametrically polymorphic.
For instance, the function symbol for extracting the element of any array has
type <math>(\mathit{ARRAY}\ T_1\ \mathit{OF}\ T_2,\; T_1) \to T_2</math>
for all first-order types <math>T_1, T_2</math>.

==== Type Ascription ====

By the type inference rules above some terms might have more than one type.
This can happen with terms built with polymorphic data type constructors
that have more than one return type for the same input type.
In that case, a type ascription operator (<code>::</code>) must be applied
to the constructor to specify the intended return type.

DATATYPE [X]
List[X] = nil | cons (head: X, tail: List[X])
END;

ASSERT y = cons(1, nil::List[REAL]);

DATATYPE [X, Y]
Union[X, Y] = left(val_l: X) | right(val_r: Y)
END;

ASSERT y = left::Union[BOOLEAN, REAL](TRUE);

The constant symbol <math>\mathrm{nil}</math> declared above has infinitely many types
(<math>\mathrm{List}[\mathrm{REAL}]</math>, <math>\mathrm{List}[\mathrm{BOOLEAN}]</math>,
<math>\mathrm{List}[[\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{List}[\mathrm{List}[\mathrm{REAL}]]</math>, ...)
CVC4's type checker requires the user to indicate explicitly the type
of each occurrence of <code>nil</code> in a term.
Similarly,
the injection operator <code>left</code> has infinitely many return types
for the same input type, for instance:
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{REAL}]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, [\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{List}[\mathrm{REAL}]]</math>,
and so on.
Applications of <code>left</code> need to specify the intended returned typed, as shown above.

== Terms and Formulas ==

In addition to type expressions, CVC4 has expressions for terms and for formulas
(i.e., terms of type <math>\mathrm{BOOLEAN}</math>).
By and large, these are standard first-order terms built out of typed variables,
predefined theory-specific operators, free (i.e., user-defined) function symbols,
and quantifiers.
Extensions include an if-then-else operator, lambda abstractions, and local symbol
declarations, as illustrated below.
Note that these extensions still keep CVC4's language first-order.
In particular, lambda abstractions are restricted to take and return only terms of
a first-order type.
Similarly, variables can only be of a first-order type.

A number of built-in function symbols (for instance, the arithmetic ones) are used
as infix operators. All user-defined symbols are used as prefix ones.

User-defined, i.e., free, function symbols include ''constant symbols'' and
''predicate symbols'', respectively nullary function symbols and function symbols
with a <math>\mathrm{BOOLEAN}</math> return type.
These symbols are introduced with global declarations of the form
<math> f_1, \ldots, f_m: T;</math>
where <math>m > 0</math>, <math>f_i</math> are the names of the symbols and
<math>T</math> is their type:

% integer constants

a, b, c: INT;

% real constants

x, y, z: REAL;

% unary function

f1: REAL -> REAL;

% binary function

f2: (REAL, INT) -> REAL;

% unary function with a tuple argument

f3: [INT, REAL] -> BOOLEAN;

% binary predicate

p: (INT, REAL) -> BOOLEAN;

% Propositional "variables"

P, Q; BOOLEAN;

Like type declarations, function symbol declarations like the above have global scope
and must be unique.
In other words, it is not possible to declare a function symbol globally more than once
in the same lexical scope.
This entails among other things that globally-defined free symbols cannot be overloaded
with different types and that theory symbols cannot be redeclared globally as free symbols.

=== Global symbol definitions ===

As with types, a function symbol can be defined as the name of another term
of the corresponding type.
With constant symbols, this is done with a declaration of the form <math>f:T = t;</math> :

c: INT;

i: INT = 5 + 3*c; % i is effectively a shorthand for 5 + 3*c

j: REAL = 3/4;

t: [REAL, INT] = (2/3, -4);

r: [# key: INT, value: REAL #] = (# key := 4, value := (c + 1)/2 #);

f: BOOLEAN = FORALL (x:INT): x <= 0 OR x > c ;

A restriction on constants of type <math>\mathit{BOOLEAN}</math> is that their value
can only be a closed formula, that is, a formula with no free variables.

A term and its name can be used interchangeably in later expressions.
Named terms are often useful for shared subterms (terms used several times in different places)
since their use can make the input exponentially more concise.
Named terms are processed very efficiently by CVC4.
It is much more efficient to associate a complex term with a name directly rather than
to declare a constant and later assert that it is equal to the same term.
This point is explained in more detail later in section [[Commands | Commands]].

More generally, in CVC4 one can associate a term to function symbols of any arity.
For non-constant function symbols this is done with a declaration of the form

<center>
<math>f:(T_1, \ldots, T_n) \to T = \mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t\;;</math>
</center>

where <math>t</math> is any term of type <math>T</math> with free variables
in <math>\{x_1, \ldots, x_n\}</math>.
The lambda binder has the usual semantics and conforms to the usual lexical scoping rules:
within the term <math>t</math> the declaration of the symbols <math>x_1, \ldots, x_n</math>
as local variables of respective type <math>T_1, \ldots, T_n</math> hides any previous
declarations of those symbols that are in scope.

As a general shorthand, when <math>k</math> consecutive types
<math>T_i, \ldots, T_{i+k-1}</math> in the lambda expression
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t</math> are identical, the syntax
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x_i,\ldots, x_{i+k-1}:T_i,\ldots, x:T_n): t</math>
can also be used.

% Global declaration of x as a unary function symbol

x: REAL -> REAL;

% Local declarations of x as variable (hiding the global one)

f: REAL -> REAL = LAMBDA (x: REAL): 2*x + 3;

p: (INT, INT) -> BOOLEAN = LAMBDA (x,i: INT): i*x - 1 > 0;

g: (REAL, INT) -> [REAL, INT] = LAMBDA (x: REAL, i:INT): (x + 1, i - 3);

Note that lambda definitions are not recursive:
the symbol being defined cannot occur in the body of the lambda term.
They should be understood as macros.
For instance, any occurrence of the term <math>f(t)</math>
where <math>f</math> is as defined above will be treated
as if it was the term <math>(2*t + 3)</math>.

=== Local symbol definitions ===

Constant and function symbols can also be declared locally anywhere within a term
by means of a let binder.
This is done with a declaration of the form

<center>
<math>
\mathrm{LET}\ f = s \ \mathrm{IN}\ t ;
</math>
</center>

where <math>t</math> is a term with no free variables, possibly a lambda term.
Let binders can be nested arbitrarily and follow the usual lexical scoping rules.
The following general form
<center>
<math>
\mathrm{LET}\ f_1 = t_1, f_2 = t_2, \ldots, f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>
can used as a shorthand for
<center>
<math>
\mathrm{LET}\ f_1 = t_1\ \mathrm{IN}\
\mathrm{LET}\ f_2 = t_2\ \mathrm{IN}\
\ldots \
\mathrm{LET}\ f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>

t: REAL =
LET x1 = 42,
g = LAMBDA(x:INT): x + 1,
x2 = 2*x1 + 7/2
IN
(LET x3 = g(x1) IN x3 + x2) / x1;

Note that the same symbol = is used, unambiguously, in the syntax of global declarations,
let declarations, and as a predicate symbol.

'''Note:'''
A <math>\mathrm{LET}</math> term with a multiple symbols defines them sequentially.
A parallel version of the <math>\mathrm{LET}</math> construct will be introduced in a later version.

== Built-in theories and their symbols ==

In addition to user-defined symbols, CVC4 terms can use a number of predefined symbols:
the logical symbols, such as <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, etc.,
as well as theory symbols, function symbols belonging to one of the built-in theories.
They are described next, with the theory symbols grouped by theory.

=== Logical Symbols ===

The logical symbols in CVC4's language include
the equality and disequality predicate symbols, respectively written as = and /=,
the multiarity disequality symbol <math>\mathrm{DISTINCT}</math>,
together with the logical constants <math>\mathrm{TRUE}</math>, <math>\mathrm{FALSE}</math>,
the connectives <math>\mathrm{NOT}</math>, <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, <math>\mathrm{XOR}</math>, <math>\Rightarrow</math>, <math>\Leftrightarrow</math>, and
the first-order quantifiers <math>\mathrm{EXISTS}</math> and <math>\mathrm{FORALL}</math>,
all with the standard many-sorted logic semantics.

The binary connectives have infix syntax and type
<math>(\mathrm{BOOLEAN},\mathrm{BOOLEAN}) \to \mathrm{BOOLEAN}</math>.
The symbols = and /=, which are also infix, are instead parametrically polymorphic,
having type <math>(T,T) \to \mathrm{BOOLEAN}</math>
for every first-order type <math>T</math>.
They are interpreted respectively as the identity relation and its complement.

The DISTINCT symbol is both overloaded and polymorphic.
It has type <math>(T,...,T) \to \mathrm{BOOLEAN}</math>
for every sequence <math>(T,...,T)</math> of length <math>n > 0</math>
and first-order type <math>T</math>.
For each <math>n > 0</math>, it is interpreted as the relation
that holds exactly for tuples of pairwise distinct elements.

The syntax for quantifiers is similar to that of the lambda binder.

Here is an example of a formula built just of these logical symbols and variables:

A, B: TYPE;

q: BOOLEAN = FORALL (x,y: A, i,j,k: B):
i = j AND i /= k => EXISTS (z: A): x /= z OR z /= y;

Binding and scoping of quantified variables follows the same rules as
in let expressions.
In particular, a quantifier will shadow in its scope any constant and function symbols
with the same name as one of the variables it quantifies:

A: TYPE;
i, j: INT;

% The first occurrence of i and of j in f are constant symbols,
% the others are variables.

f: BOOLEAN = i = j AND FORALL (i,j: A): i = j OR i /= j;

Optionally, it is also possible to specify instantiation patterns
for quantified variables.
The general syntax for a quantified formula <math>\psi</math> with patterns is

<center>
<math>
Q\;(x_1:T_1, \ldots, x_k:T_k):\; p_1: \ldots\; p_n:\; \varphi
</math>
</center>

where <math>n \geq 0</math>, <math>Q</math> is
either <math>\mathrm{FORALL}</math> or <math>\mathrm{EXISTS}</math>,
<math>\varphi</math> is a term of type <math>\mathrm{BOOLEAN}</math>,
and each of the <math>p_i</math>'s,
a pattern for the quantifier <math>Q\;(x_1:T_1, \ldots, x_k:T_k)</math>, has the form

<center>
<math>
\mathrm{PATTERN}\; (t_1, \ldots, t_m)
</math>
</center>

where <math>m > 0</math> and <math>t_1, \ldots, t_m</math> are
arbitrary binder-free terms (no lets, no quantifiers).
Those terms can contain (free) variables, typically, but not exclusively,
drawn from <math>x_1, \ldots, x_k</math>.
(Additional variables can occur if <math>\psi</math> occurs in a bigger formula
binding those variables.)

A: TYPE;
b, c: A;
p, q: A -> BOOLEAN;
r: (A, A) -> BOOLEAN;

ASSERT FORALL (x0, x1, x2: A):
PATTERN (r(x0, x1), r(x1, x2)):
(r(x0, x1) AND r(x1, x2)) => r(x0, x2) ;

ASSERT FORALL (x: A):
PATTERN (r(x, b)):
PATTERN (r(x, c)):
p(x) => q(x) ;

ASSERT EXISTS (y: A):
FORALL (x: A):
PATTERN (r(x, y), p(y)):
r(x, y) => q(x) ;

Patterns have no logical meaning:
adding them to a formula does not change its semantics.
Their purpose is purely operational, as explained in
the [[#Instantiation Patterns | Instantiation Patterns]] section.

In addition to these constructs, CVC4 also has a general mixfix conditional operator
of the form

<center>
<math>
\mathrm{IF}\ b\ \mathrm{THEN}\ t\ \mathrm{ELSIF}\ b_1\ \mathrm{THEN}\ t_1\ \ldots\ \mathrm{ELSIF}\ b_n\ \mathrm{THEN}\ t_n\ \mathrm{ELSE}\ t_{n+1}\ \mathrm{ENDIF}
</math>
</center>

with <math>n \geq 0</math> where
<math>b, b_1, \ldots, b_n</math> are terms of type <math>\mathrm{BOOLEAN}</math> and
<math>t, t_1, \ldots, t_n, t_{n+1}</math> are terms of the same first-order type <math>T</math>:

% Conditional term
x, y, z, w: REAL;

t: REAL =
IF x > 0 THEN y
ELSIF x >= 1 THEN z
ELSIF x > 2 THEN w
ELSE 2/3 ENDIF;

=== User-defined Functions and Types ===

The theory of user-defined functions,also know in the SMT literature as
the theory ''Equality over Uninterpreted Functions'', or ''EUF'', is in effect
a family of theories of equality parametrized by the basic types and the free symbols
a user can define during a run of CVC4.

This theory has no built-in symbols (other than the logical ones).
Its types consist of ''all and only'' the user-defined types.
Its function symbols consist of ''all and only'' the user-defined free symbols.

=== Arithmetic ===

The real arithmetic theory has two types:
<math>\mathrm{REAL}</math> and <math>\mathrm{INTEGER}</math>
with the latter a subtype of the first.
Its built-in symbols for the usual arithmetic constants
and operators over the type <math>\mathrm{REAL}</math>, each with the expected type:
all numerals 0, 1, ..., as well as - (both unary and binary), +, *, /, <, >, <=, >=.
Application of the binary symbols are in infix form.
Note that + is only binary, and so an expression such as +4 is ill-formed.

Rational values can be expressed in decimal or fractional format,
e.g., 0.1, 23.243241, 1/2, 3/4, and so on.
A leading 0 is mandatory for decimal numbers smaller than one
(e.g., the syntax .3 cannot be used as a shorthand for 0.3).
However, a trailing 0 is ''not'' required for decimals that are whole numbers
(e.g., 3. is allowed as a shorthand for 3.0).
The size of the numerals used in the representation of natural and rational numbers
is unbounded; more accurately, bounded only by the amount of available memory.

=== Bit vectors ===

=== Arrays ===

The theory of arrays is a parametric theory of (total) unary maps.
It comes equipped with mixfix polymorphic selection and update operators, respectively
<center>
<math>\_[\_]</math> and <math>\_\ \mathrm{WITH}\ [\_]\ := \_</math> .
</center>
The semantics of these operators is the expected one:
for all first-order types <math>T_1</math> and <math>T_2</math>,
if <math>a</math> is of type <math>\mathrm{ARRAY}\ T_1 \mathrm{OF}\ T_2</math>,
<math>i</math> is of type <math>T_1</math>, and
<math>v</math> is of type <math>T_2</math>,
* <math>a[i]</math> denotes the value that <math>a</math> associates to index <math>i</math>,
* <math>a\ \mathrm{WITH}\ [i]\ := v</math> denotes a map that associates <math>v</math> to index <math>i</math> and is otherwise identical to <math>a</math>.
Sequential updates can be chained with the shorthand syntax
<math>\_\ \mathrm{WITH}\ [\_]\ := \_, \ldots, [\_]\ := \_</math>.

A: TYPE = ARRAY INT OF REAL;
a: A;
i: INT = 4;

% selection:

elem: REAL = a[i];

% update

a1: A = a WITH [10] := 1/2;

% sequential update
% (syntactic sugar for (a WITH [10] := 2/3) WITH [42] := 3/2)

a2: A = a WITH [10] := 2/3, [42] := 3/2;

Since arrays are just maps, equality between them is extensional, that is,
for two arrays of the same type to be different they have to map at least one
index to differ values.

=== Data types ===

The theory of inductive data types is in fact a family of theories parametrized
by a data type declaration specifying constructors and selectors
for one or more user-defined data types.

No built-in operators other than equality and disequality are provided
for this family in the native language.
Each user-provided data type declaration, however, generates constructor, selector and tester operators
as described in the [[#Inductive Data Types | Inductive Data Types]] section.

=== Tuples and Records ===

Semantically both records and tuples can be seen as special instances
of inductive data types.
CVC4 implements them internally indeed as data types.
In essence, a record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math>
is encoded as a data type of the form

<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\ \ \mathrm{Record} = \mathit{rec}(l_0:T_0, \ldots, l_n:T_n) \\
\mathrm{END};
\end{array}
</math>
</center>

Tuples of length <math>n</math> are in turn special cases of records whose field names are
the numerals from <math>0</math> to <math>n-1</math>.

Externally, tuples and records have their own syntax for constructor and selector operators.
* Records of type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> have the associated record constructor <math>(\#\ l_0 := \_,\; \ldots,\; l_n := \_\ \#)</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.
* Tuples of type <math>[\ T_0, \ldots, T_n\ ]</math> have the associated tuple constructor <math>(\ \_,\; \ldots,\; \_\ )</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.

The selector operators on records and tuples follows a dot notation syntax.

% Record construction and field selection
Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);
k: INT = x.key;
v: REAL = x.weight;

% Tuple construction and projection
y: [REAL, INT, REAL] = ( 4/5, 9, 11/9 );
first_elem: REAL = y.0;
third_elem: REAL = y.2;

Differently from data types, records and tuples are also provided with built-in update operators similar in syntax and semantics to the update operator for arrays.
More precisely, for each record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .l_i\ := \_
</math>
</center>

The operator maps a record <math>r</math> of that type and a value <math>v</math>
of type <math>T_i</math> to the record that stores <math>v</math> in field <math>l_i</math>
and is otherwise identical to <math>r</math>.
Analogously, for each tuple type <math>[T_0, \ldots, T_n]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .i\ := \_
</math>
</center>

with similar semantics.

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = x WITH .weight := 48;

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = y WITH .1 := 3;

Updates to a nested component can be combined in a single WITH operator:

Cache: TYPE = ARRAY [0..100] OF [# addr: INT, data: REAL #];
State: TYPE = [# pc: INT, cache: Cache #];

s0: State;
s1: State = s0 WITH .cache[10].data := 2/3;

Note that, differently from updates on arrays, tuple and record updates are
just additional syntactic sugar.
For instance, the record <code>x1</code> and tuple <code>y1</code> defined above
could have been equivalently defined as follows:

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = (# key := x.key, weight := 48 #);

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = ( y.0, 3, y.1 );

== Commands ==

In addition to declarations of types and function symbols,
the CVC4 native language contains the following commands:

* <math>\mathrm{ASSERT}\ F</math> -- Add the formula <math>F</math> to the current logical context <math>\Gamma</math>.
* [[#CHECKSAT|<math>\mathrm{CHECKSAT}\ F</math>]] -- Check if the formula <math>F</math> is satisfiable in the current logical context (<math>\Gamma \not\models_T \mathrm{NOT}\ F</math>).
* <math>\mathrm{CONTINUE}</math> -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, search for a counter-example different from the current one.
* [[#COUNTEREXAMPLE|<math>\mathrm{COUNTEREXAMPLE}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print the context that is a witness for invalidity/satisfiability.
* [[#COUNTERMODEL|<math>\mathrm{COUNTERMODEL}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print a model that makes the formula invalid/satisfiable. The model is provided in terms of concrete values for each free symbol.
* <math>\mathrm{OPTION}\ o\ v</math> -- Set the command-line option flag <math>o</math> to value <math>v</math>. The argument <math>o</math> is provide as a string literal enclosed in double-quotes and <math>v</math> as an integer value.
* <math>\mathrm{POP}</math> -- Equivalent to <math>\mathrm{POPTO}\ 1</math>
* [[#PUSH and POPTO|<math>\mathrm{POPTO}\ n</math>]] -- Restore the system to the state it was in right before the most recent call to <math>\mathrm{PUSH}</math> made from assertion (stack) level <math>n</math>. Note that the current assertion level is printed as part of the output of the <math>\mathrm{WHERE}</math> command.
* [[#PUSH and POPTO|<math>\mathrm{PUSH}</math>]] -- Save (checkpoint) the current state of the system.
* [[#QUERY|<math>\mathrm{QUERY}\ F</math>]] -- Check if the formula <math>F</math> is valid in the current logical context (<math>\Gamma\models_T F</math>).
* [[#RESTART|<math>\mathrm{RESTART}\ F</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, repeat the check but with the additional assumption <math>F</math> in the context.
* <math>\mathrm{PRINT}\ t</math> -- Parse and print back the term <math>t</math>.
* <math>\mathrm{TRANSFORM}\ t</math> -- Simplify the term <math>t</math> and print the result.
* <math>\mathrm{WHERE}</math> -- Print all the formulas in the current logical context <math>\Gamma</math>.

The remaining commands take a single argument, given as a string literal enclosed in double-quotes.

* <math>\mathrm{ECHO}\ s</math> -- Print string <math>s</math>
* <math>\mathrm{INCLUDE}\ f</math> -- Read commands from file <math>f</math>.
* <math>\mathrm{TRACE}\ f</math> -- Turn on tracing for the debug flag <math>f</math>.
* <math>\mathrm{UNTRACE}\ f</math> -- Turn off tracing for the debug flag <math>f</math>.

Here, we explain some of the above commands in more detail.

=== QUERY ===

The command <math>\mathrm{QUERY}\ F</math> invokes the core functionality of CVC4 to check
the validity of the formula <math>F</math> with respect to the assertions made thus far,
which constitute the context <math>\Gamma</math>.
The argument <math>F</math> must be well typed term of type <math>\mathrm{BOOLEAN}</math>,
as described in [[#Terms and Formulas | Terms and Formulas]].

The execution of this command always terminates and produces one of three possible answers:
<code>valid</code>, <code>invalid</code>, and <code>unknown</code>.

* A <code>valid</code> answer indicates that <math>\Gamma \models_T F</math>. After a query returning such an answer, the logical context <math>\Gamma</math> is exactly as it was before the query.
* An <code>invalid</code> answer indicates that <math>\Gamma \not\models_T F</math>, that is, there is a model of the background theory <math>T</math> that satisfies <math>\Gamma \cup \{\mathrm{NOT}\ F\}</math>. When <math>\mathrm{QUERY}\ F</math> returns <code>invalid</code>, the logical context <math>\Gamma</math> is augmented with a set <math>\Delta</math> of ground (i.e., variable-free) literals such that <math>\Gamma\cup\Delta</math> is satisfiable in <math>T</math>, but <math>\Gamma\cup\Delta\models_T \mathrm{NOT}\ F</math>. In fact, in this case <math>\Delta</math> ''propositionally entails'' <math>\mathrm{NOT}\ F</math>, in the sense that, every truth assignment to the literals of <math>\Delta</math> that satisfies <math>\Delta</math> falsifies <math>F</math>. We call the new context <math>\Gamma\cup\Delta</math> a ''counterexample'' for <math>F</math>.
* An <code>unknown</code> answer is similar to an <code>invalid</code> answer in that additional literals are added to the context which propositionally entail <math>\mathrm{NOT}\ F</math>. The difference in this case is that CVC4 cannot guarantee that <math>\Gamma\cup\Delta</math> is actually satisfiable in <math>T</math>.

CVC4 may report <code>unknown</code> when the context or the query contains
non-linear arithmetic terms or quantifiers.
In all other cases, it is expected to be sound and complete,
i.e., to report <code>Valid</code> if <math>\Gamma \models_T F</math>
and <code>Invalid</code> otherwise.

After an <code>invalid</code> (resp. <code>unknown</code>) answer,
counterexamples (resp. possible counterexamples) can be obtained with
a <math>\mathrm{WHERE}</math>, <math>\mathrm{COUNTEREXAMPLE}</math>,
or <math>\mathrm{COUNTERMODEL}</math> command.


Since the <math>\mathrm{QUERY}</math> command may modify
the current context, if one needs to check several formulas in a row
in the same context, it is a good idea to surround every
query by a <math>\mathrm{PUSH}</math> and <math>\mathrm{POP}</math> invocation
in order to preserve the context:

PUSH;
QUERY <formula>;
POP;

=== CHECKSAT ===

The command <math>\mathrm{CHECKSAT}\ F</math> behaves identically
to <math>\mathrm{QUERY}\ \mathrm{NOT}\ F</math>.

=== RESTART ===

The command <math>\mathrm{RESTART}\ F</math> can only be invoked after an invalid query.
For example, in an interactive setting:

QUERY <formula>;

CVC4> invalid

RESTART <formula2>;

Functionally, the behavior of the above command sequence is identical to the following:

PUSH;
QUERY <formula>;
POP;
ASSERT <formula2>;
QUERY <formula>;

The advantage of using the <math>\mathrm{RESTART}</math> command is that
the first command sequence may be executed much more efficiently that the second.
The reason is that with <math>\mathrm{RESTART}</math> CVC4 will re-use
what it has learned while answering the previous query rather than starting
over from scratch.

=== COUNTERMODEL ===

[More]

=== COUNTEREXAMPLE ===

[More]

=== PUSH and POPTO ===

CVC4's context can be understood as being stratified in ''assertion levels''
which are added and removed in a LIFO fashion.
The system starts at assertion level 0 and every execution of the PUSH command creates a new assertion level after the current one.
Each formula added to the context either by the user, via an ASSERT command, or internally by the system
is added to the most recent assertion level.
Executing POPTO n removes from the context the most recent n assertion levels and all the formulas in them.
So, for instance, POP 1 has the effect of retracting all formulas in the current assertion level (and removing that level).
Note that formulas at assertion level 0 cannot be retracted.

Note: Symbol declarations are always added at assertion level zero. So they are not affected by POPTO commands.

== Instantiation Patterns ==

CVC4 processes each universally quantified formula in the current context
by adding instances of the formula obtained by replacing its universal variables
with ground terms.
Patterns restrict the choice of ground terms for the quantified variables,
with the goal of controlling the potential explosion of ground instances.
In essence, adding patterns to a formula is a way for the user to tell CVC4
to focus only on certain instances which, in the user's opinion, will be
most helpful during a proof.

In more detail, patterns have the following effect on formulas that are found
in the logical context or get added to it later while CVC4 is trying to prove
the validity of some formula <math>F</math>.

If a formula in the current context starts with an existential quantifier,
CVC4 ''Skolemizes'' it, that is, replaces it in the context with the formula
obtained by substituting the existentially quantified variables
by fresh constants and dropping the quantifier.
Any patterns for the existential quantifier are simply ignored.

If a formula starts with a universal quantifier
<math>\mathrm{FORALL}\; (x_1:T_1, \ldots, x_n:T_n)</math>,
CVC4 adds to the context a number of instances of the formula,
with the goal of using them to prove the query <math>F</math> valid.
An instance is obtained by replacing each <math>x_i</math> with a ground term
of the same type occurring in one of the formulas in the context,
and dropping the universal quantifier.
If <math>x_i</math> occurs in a pattern
<math>\mathrm{PATTERN}\; (t_1, \ldots, t_m)</math> for the quantifier,
it will be instantiated only with terms obtained by simultaneously matching
all the terms in the pattern against ground terms in the current context
<math>\Gamma</math>.

Specifically, the matching process produces one or more substitutions
<math>\sigma</math> for the variables in <math>(t_1, \ldots, t_m)</math>
which satisfy the following invariant:
for each <math>i = 1, \ldots, m</math>, <math>\sigma(t_i)</math> is
a ground term and there is a ground term <math>s_i</math> in <math>\Gamma</math>
such that <math>\Gamma \models_T \sigma(t_i) = s_i</math>.
The variables of <math>(x_1:T_1, \ldots, x_n:T_n)</math> that occur
in the pattern are instantiated only with those substitutions
(while any remaining variables are instantiated arbitrarily).

The Skolemized version or the added instances of a context formula may themselves
start with a quantifier.
The same instantiation process is applied to them too, recursively.

Note that the matching mechanism is not limited to syntactic matching
but is modulo the equations asserted in the context.
Because of decidability and/or efficiency limitations, the matching process
is not exhaustive.
CVC4 will typically miss some substitutions that satisfy the invariant above.
As a consequence, it might fail to prove the validity of the query formula
<math>F</math>, which makes CVC4 incomplete for contexts containing
quantified formulas.
It should be noted though that exhaustive matching, which can be achieved
simply by not specifying any patterns, does not yield completeness anyway
since the instantiation of universal variables is still restricted
to just the ground terms in the context,
whereas in general additional ground terms might be needed.

CVC4's native language

2012-12-03T22:28:11Z

Tinelli: /* Commands */

= CVC4 native input language =

The native input language consists of a sequence of symbol declarations and commands, each followed by a semicolon (<code>;</code>).

Any text after the first occurrence of a percent character and to the end of the current line is a comment:

%%% This is a native language comment

== Type System ==

CVC4's type system includes a set of built-in types which can be expanded with additional user-defined types.

The type system consists of ''first-order'' types, ''subtypes'' of first-order types, and ''higher-order'' types, all of which are interpreted as sets.
For convenience, we will sometimes identify below the interpretation of a type with the type itself.

First-order types consist of basic types and structured types. The basic types are <math>\mathrm{BOOLEAN}</math>, <math>\mathrm{REAL}</math>, <math>\mathrm{BITVECTOR}(n)</math> for all <math>n > 0</math>, as well as user-defined basic types (also called uninterpreted types).
The structured types are array, tuple, record types, and ML-style user-defined (inductive) datatypes.

'''Note:''' Currently, subtypes consist only of the built-in subtype <math>\mathrm{INT}</math> of <math>\mathrm{REAL}</math>.

Support for CVC3-style user-defined subtypes will be added in a later release.

Function types are the only higher-order types.
More precisely, they are just second-order types
since function symbols in CVC4, both built-in and user-defined, can take as argument or return only values of
a first-order type.

=== Basic Types ===

==== The BOOLEAN Type ====

The <math>\mathrm{BOOLEAN}</math> type is interpreted as the two-element set of Boolean values
<math>\{\mathrm{TRUE},\; \mathrm{FALSE}\}</math>.

'''Note:''' CVC4's treatment of this type differs from CVC3's where <math>\mathrm{BOOLEAN}</math> is used only as the type of formulas, but not as value type. CVC3 follows the two-tiered structure of classical first-order logic
which distinguishes between formulas and terms, and allows terms to occur in formulas but not vice versa (with the exception of the IF-THEN-ELSE construct).
CVC4 drops the distinction between terms and formulas and defines the latter just as terms of type <math>\mathrm{BOOLEAN}</math>. As such, formulas can occur as subterms of possibly non-Boolean terms.

Example:

% Boolean constants
a, b: BOOLEAN;

% REAL constants
x,y: REAL

% Boolean-valued function, can be used as a predicate symbol
p: REAL -> BOOLEAN;
ASSERT a => p(x - y)

% Real-valued function with Boolean argument
f: BOOLEAN -> REAL;

% The argument of f can be a formula ...
ASSERT f(a OR b) > 0.3 OR p(x);

% ... even a quantified one
ASSERT y = f(FORALL (r: REAL): r < r + 1);

==== The REAL Type ====

The <math>\mathrm{REAL}</math> type is interpreted as the set of real numbers.

Note that these are the (infinite precision) mathematical reals,
not the floating point numbers.
Support for floating point types is planned for future versions.

x, y : REAL;
QUERY (( x <= y ) AND ( y <= x )) => ( x = y );

==== The INT Type ====

The <math>\mathrm{INT}</math> type is interpreted as the set of integer numbers
and is considered a subtype of <math>\mathrm{REAL}</math>.
The latter means in particular that it is possible to mix integer and real terms
in expressions without the need of an explicit ''upcasting'' operator.

Note that these are the (infinite precision) mathematical integers,
not the finite precision machine integers used in most programming languages.
The latter are modeled by [[ #Bitvectors | bit vector ]] types.

x, y : INT;
QUERY ((2 * x + 4 * y <= 1) AND ( y >= x)) => (x <= 0);
z : REAL;
QUERY (2 * x + z <= 3.5) AND (z >= 1);

==== Bit Vector Types ====

For every positive integer <math>n</math>, the type <math>\mathrm{BITVECTOR}(n)</math> is interpreted as the set of all bit vectors of size <math>n</math>.
A rich set of bit vector operators is supported.

==== User-defined Basic Types ====

Users can define new basic types
(often referred to as ''uninterpreted'' types in the SMT literature).
Each such type is interpreted as a set of unspecified cardinality
but disjoint from any other type.

User-defined basic types are created by declarations like the following:

% User declarations of basic types:

MyBrandNewType: TYPE;

Apples, Oranges: TYPE;

=== Structured Types ===

CVC4's structured types are divided into the following families.

==== Array Types ====

Array types are created by the mixfix type constructors <math>\mathrm{ARRAY}\ \_\ \mathrm{OF}\ \_</math>
whose arguments can be instantiated by any value type.

I : TYPE;

%% Array types:

% Arrays with indices from I and values from REAL
Array1: TYPE = ARRAY I OF REAL;

% Arrays with integer indices and array values
Array2: TYPE = ARRAY INT OF (ARRAY INT OF REAL);

% Arrays with integer pair indices and integer values
IntMatrix: TYPE = ARRAY [INT, INT] OF INT;

An array type of the form <math>\mathrm{ARRAY}\ T_1\ \mathrm{OF}\ T_2</math> is interpreted
as the set of all total maps from <math>T_1</math> to <math>T_2</math>.
The main difference with the function type <math>T_1 \to T_2</math> is that arrays,
contrary to functions, are first-class objects of the language, that is, values of an array
type can be arguments or results of functions.
Furthermore, array types come equipped with an update operation.

==== Tuple Types ====

Tuple types are created by the mixfix type constructors

<center>
<math>
\begin{array}{l} [\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ \ ,\ \_\ ] \\[1ex] \ldots \end{array}
</math>
</center>

whose arguments can be instantiated by any value type.

IntArray: TYPE = ARRAY INT OF INT;

% Tuple type declarations

RealPair: TYPE = [REAL, REAL]

MyTuple: TYPE = [ REAL, IntArray, [INT, INT] ];

A tuple type of the form <math>[T_1, \ldots, T_n]</math> is interpreted
as the Cartesian product <math>T_1 \times \cdots \times T_n</math>.

Note that while the types <math>(T_1, \ldots, T_n) \to T</math> and
<math>[T_1 \times \cdots \times T_n] \to T</math> are semantically equivalent,
they are operationally different in CVC4.
The first is the type of functions that take <math>n</math> arguments
of respective type <math>T_1</math>, <math>\ldots</math>, <math>T_n</math>,
while the second is the type of functions that take one argument of an <math>n</math>-tuple type.

==== Record Types ====

Similar to, but more general than tuple types, record types are created by type constructors of the form

<center>
<math>
[\#\ l_1: \_\ ,\ \ldots\ ,\ l_n: \_\ \#]
</math>
</center>

where <math>n > 0</math>, <math>l_1,\ldots, l_n</math> are field labels,
and the arguments can be instantiated with any first-order types.

MyType: TYPE;

% Record declaration

RecordType: TYPE = [# id: REAL, age: INT, info: MyType #];

The order of the fields in a record type is meaningful:
permuting the field names gives a different type.

Note that record types are non-recursive.
For instance, it is not possible to declare a record type called <code>Person</code> containing
a field of type <code>Person</code>.
Recursive types are provided in CVC4 by the more general inductive data types.
(As a matter of fact, both record and tuple types are implemented internally as inductive data types.)

==== Inductive Data Types ====

Inductive data types in CVC4 are similar to inductive data types of functional languages.
They can be parametric or not.

===== Non-Parametric Data Types =====

Non-parametric data types are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1 & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2 & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types, including any <math>A_i</math>.
Such declarations define the data types <math>A_1, \ldots, A_n</math>.
For each data type <math>A_i</math> they introduce:

* constructor symbols <math>cons</math> of type <math>(T_1, \ldots, T_k) \to \mathit{type\_name}_i</math>,
* selector symbols <math>\mathit{sel}_j</math> of type <math>\mathit{type\_name}_i \to T_j</math>, and
* tester symbols <math>\mathit{is\_cons}</math> of type <math>\mathit{type\_name}_i \to \mathrm{BOOLEAN}</math>.

Note that permitting more than one data type to be defined in the same declarations allows
the definition of mutually recursive types.

% simple enumeration type

% implicitly defined are the testers: is_red, is_yellow and is_blue
% (similarly for the other data types)

DATATYPE
PrimaryColor = red | yellow | blue
END;

% infinite set of pairwise distinct values ..., v(-1), v(0), v(1), ...

DATATYPE
Id = v (id: INT)
END;

% ML-style integer lists

DATATYPE
IntList = nil | ins (head: INT, tail: IntList)
END;

% AST for lamba calculus

DATATYPE
Term = var (index: INT)
| apply (arg_1: Term, arg_2: Term)
| lambda (arg: INT, body: Term)
END;

% Trees

DATATYPE
Tree = tree (value: REAL, children: TreeList),
TreeList = nil_tl
| ins_tl (first_t1: Tree, rest_t1: TreeList)
END;

Constructor, selector and tester symbols defined for a data type have global scope.
So, for example, it is not possible for two different data types to use
the same name for a constructor.

An inductive data type is interpreted as a term algebra constructed by the constructor symbols
over some sets of generators.
For example, the type <code>IntList</code> defined above is interpreted as the set
of all terms constructed with <code>nil</code> and <code>ins</code> over the integers.

===== Parametric Data Types =====

Parametric data types are infinite families of (non-parametric) data types
with each family parametrized by one or more type variables.
They are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1[X_{1,1}, \ldots, X_{1,p_1}] & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2[X_{2,1}, \ldots, X_{2,p_2}] & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n[X_{n,1}, \ldots, X_{n,p_n}] & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name parametrized by the type variables <math>X_{i,1}, \ldots, X_{i,p_i}</math>
and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types,
possibly parametrized by <math>X_1, \ldots, X_p</math>, including any <math>A_i</math>.

% Parametric pairs
DATATYPE
Pair[X, Y] = pair (first: X, second: Y)
END;

% Parametric lists

DATATYPE
List[X] = nil | cons (head: X, tail: List[X])
END;

% Parametric trees using the list type above

DATATYPE
Tree[X] = node (value: X, children: List[Tree[X]]),
END;

The declarations above define infinitely many types of the form
Pair[S,T], List[T] and Tree[T] where S and T are first-order types.
Note that the identifier <code>List</code> above, for example, by itself does not denote a type.
In contrast, the terms <code>List[Real]</code>, <code>List[List[Real]]</code>, <code>List[Tree[INT]]</code>,
and so on do.

===== Restriction to Inductive Types =====

By adopting a term algebra semantics, CVC4 allows only ''inductive'' data types,
that is, data types whose values are essentially (labeled, ordered) finite trees.
Infinite structures such as streams or even finite but cyclic ones
such as circular lists are then excluded.
For instance, none of the following declarations define inductive data types,
and are rejected by CVC4:

DATATYPE
IntStream = s (first:INT, rest: IntStream)
END;

DATATYPE
RationalTree = node1 (child: RationalTree)
| node2 (left_child: RationalTree, right_child:RationalTree)
END;

DATATYPE
T1 = c1 (s1: T2),
T2 = c2 (s2: T1)
END;

In concrete, a declaration of <math>n \geq 1</math> datatypes <math>T_1, \ldots, T_n</math> will be rejected if for any one of the types <math>T_1, \ldots, T_n</math>, it is impossible to build a finite term of that type using only the constructors of <math>T_1, \ldots, T_n</math> and free constants of type other than <math>T_1, \ldots, T_n</math>.

Inductive data types are the only types where the user also chooses names for the built-in operations to:

* construct a value of the type (with the constructors),
* extract components from a value (with the selectors), or
* check if a value was constructed with a certain constructor or not (with the testers).

For all the other types, CVC4 provides predefined names for the built-in operations on the type.

=== Function Types ===

Function (<math>\to</math>) types are created by the mixfix type constructors
<center>
<math>
\begin{array}{l}
\_ \to \_ \\[1ex] (\ \_\ ,\ \_\ ) \to \_
\\[1ex] (\ \_\ ,\ \_\ ,\ \_\ ) \to \_
\\[1ex] \ldots
\end{array}
</math>
</center>
whose arguments can be instantiated by any first-order type.

% Function type declarations

UnaryFunType: TYPE = INT -> REAL;

BinaryFunType: TYPE = (REAL, REAL) -> ARRAY REAL OF REAL;

TernaryFunType: TYPE = (REAL, BITVECTOR(4), INT) -> BOOLEAN;

A function type of the form <math>(T_1, \ldots, T_n) \to T</math> with <math>n > 0</math> is interpreted as the set of all ''total'' functions from the Cartesian product <math>T_1 \times \cdots \times T_n</math> to <math>T</math>.

The example above also shows how to introduce type names.
A name like <code>UnaryFunType</code> above is just an abbreviation for the type <math>\mathrm{INT} \to \mathrm{REAL}</math> and can be used interchangeably with it.

In general, any type defined by a type expression <code>E</code> can be given a name with the declaration:

name : TYPE = E;

=== Type Checking ===

In CVC4, formulas and terms are statically typed at the level of types
(as opposed to subtypes) according to the usual rules of first-order many-sorted logic,
with the main difference that formulas are just terms of type <math>BOOLEAN</math>:

* each variable has one associated first-order type,
* each constant symbol has one or more associated first-order types,
* each function symbol has one or more associated function types,
* the type of a term consisting just of a variable is the type associated to that variable,
* the type of a term consisting just of a constant symbol is the type associated to that constant symbol,
* the term obtained by applying a function symbol <math>f</math> to the terms <math>t_1, \ldots, t_n</math> is <math>T</math> if <math>f</math> has type <math>(T_1, \ldots, T_n) \to T</math> and each <math>t_i</math> has type <math>T_i</math>.

Attempting to enter an ill-typed term will result in an error.

Another significant difference with standard many-sorted logic is that
some built-in symbols are parametrically polymorphic.
For instance, the function symbol for extracting the element of any array has
type <math>(\mathit{ARRAY}\ T_1\ \mathit{OF}\ T_2,\; T_1) \to T_2</math>
for all first-order types <math>T_1, T_2</math>.

==== Type Ascription ====

By the type inference rules above some terms might have more than one type.
This can happen with terms built with polymorphic data type constructors
that have more than one return type for the same input type.
In that case, a type ascription operator (<code>::</code>) must be applied
to the constructor to specify the intended return type.

DATATYPE [X]
List[X] = nil | cons (head: X, tail: List[X])
END;

ASSERT y = cons(1, nil::List[REAL]);

DATATYPE [X, Y]
Union[X, Y] = left(val_l: X) | right(val_r: Y)
END;

ASSERT y = left::Union[BOOLEAN, REAL](TRUE);

The constant symbol <math>\mathrm{nil}</math> declared above has infinitely many types
(<math>\mathrm{List}[\mathrm{REAL}]</math>, <math>\mathrm{List}[\mathrm{BOOLEAN}]</math>,
<math>\mathrm{List}[[\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{List}[\mathrm{List}[\mathrm{REAL}]]</math>, ...)
CVC4's type checker requires the user to indicate explicitly the type
of each occurrence of <code>nil</code> in a term.
Similarly,
the injection operator <code>left</code> has infinitely many return types
for the same input type, for instance:
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{REAL}]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, [\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{List}[\mathrm{REAL}]]</math>,
and so on.
Applications of <code>left</code> need to specify the intended returned typed, as shown above.

== Terms and Formulas ==

In addition to type expressions, CVC4 has expressions for terms and for formulas
(i.e., terms of type <math>\mathrm{BOOLEAN}</math>).
By and large, these are standard first-order terms built out of typed variables,
predefined theory-specific operators, free (i.e., user-defined) function symbols,
and quantifiers.
Extensions include an if-then-else operator, lambda abstractions, and local symbol
declarations, as illustrated below.
Note that these extensions still keep CVC4's language first-order.
In particular, lambda abstractions are restricted to take and return only terms of
a first-order type.
Similarly, variables can only be of a first-order type.

A number of built-in function symbols (for instance, the arithmetic ones) are used
as infix operators. All user-defined symbols are used as prefix ones.

User-defined, i.e., free, function symbols include ''constant symbols'' and
''predicate symbols'', respectively nullary function symbols and function symbols
with a <math>\mathrm{BOOLEAN}</math> return type.
These symbols are introduced with global declarations of the form
<math> f_1, \ldots, f_m: T;</math>
where <math>m > 0</math>, <math>f_i</math> are the names of the symbols and
<math>T</math> is their type:

% integer constants

a, b, c: INT;

% real constants

x, y, z: REAL;

% unary function

f1: REAL -> REAL;

% binary function

f2: (REAL, INT) -> REAL;

% unary function with a tuple argument

f3: [INT, REAL] -> BOOLEAN;

% binary predicate

p: (INT, REAL) -> BOOLEAN;

% Propositional "variables"

P, Q; BOOLEAN;

Like type declarations, function symbol declarations like the above have global scope
and must be unique.
In other words, it is not possible to declare a function symbol globally more than once
in the same lexical scope.
This entails among other things that globally-defined free symbols cannot be overloaded
with different types and that theory symbols cannot be redeclared globally as free symbols.

=== Global symbol definitions ===

As with types, a function symbol can be defined as the name of another term
of the corresponding type.
With constant symbols, this is done with a declaration of the form <math>f:T = t;</math> :

c: INT;

i: INT = 5 + 3*c; % i is effectively a shorthand for 5 + 3*c

j: REAL = 3/4;

t: [REAL, INT] = (2/3, -4);

r: [# key: INT, value: REAL #] = (# key := 4, value := (c + 1)/2 #);

f: BOOLEAN = FORALL (x:INT): x <= 0 OR x > c ;

A restriction on constants of type <math>\mathit{BOOLEAN}</math> is that their value
can only be a closed formula, that is, a formula with no free variables.

A term and its name can be used interchangeably in later expressions.
Named terms are often useful for shared subterms (terms used several times in different places)
since their use can make the input exponentially more concise.
Named terms are processed very efficiently by CVC4.
It is much more efficient to associate a complex term with a name directly rather than
to declare a constant and later assert that it is equal to the same term.
This point is explained in more detail later in section [[Commands | Commands]].

More generally, in CVC4 one can associate a term to function symbols of any arity.
For non-constant function symbols this is done with a declaration of the form

<center>
<math>f:(T_1, \ldots, T_n) \to T = \mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t\;;</math>
</center>

where <math>t</math> is any term of type <math>T</math> with free variables
in <math>\{x_1, \ldots, x_n\}</math>.
The lambda binder has the usual semantics and conforms to the usual lexical scoping rules:
within the term <math>t</math> the declaration of the symbols <math>x_1, \ldots, x_n</math>
as local variables of respective type <math>T_1, \ldots, T_n</math> hides any previous
declarations of those symbols that are in scope.

As a general shorthand, when <math>k</math> consecutive types
<math>T_i, \ldots, T_{i+k-1}</math> in the lambda expression
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t</math> are identical, the syntax
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x_i,\ldots, x_{i+k-1}:T_i,\ldots, x:T_n): t</math>
can also be used.

% Global declaration of x as a unary function symbol

x: REAL -> REAL;

% Local declarations of x as variable (hiding the global one)

f: REAL -> REAL = LAMBDA (x: REAL): 2*x + 3;

p: (INT, INT) -> BOOLEAN = LAMBDA (x,i: INT): i*x - 1 > 0;

g: (REAL, INT) -> [REAL, INT] = LAMBDA (x: REAL, i:INT): (x + 1, i - 3);

Note that lambda definitions are not recursive:
the symbol being defined cannot occur in the body of the lambda term.
They should be understood as macros.
For instance, any occurrence of the term <math>f(t)</math>
where <math>f</math> is as defined above will be treated
as if it was the term <math>(2*t + 3)</math>.

=== Local symbol definitions ===

Constant and function symbols can also be declared locally anywhere within a term
by means of a let binder.
This is done with a declaration of the form

<center>
<math>
\mathrm{LET}\ f = s \ \mathrm{IN}\ t ;
</math>
</center>

where <math>t</math> is a term with no free variables, possibly a lambda term.
Let binders can be nested arbitrarily and follow the usual lexical scoping rules.
The following general form
<center>
<math>
\mathrm{LET}\ f_1 = t_1, f_2 = t_2, \ldots, f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>
can used as a shorthand for
<center>
<math>
\mathrm{LET}\ f_1 = t_1\ \mathrm{IN}\
\mathrm{LET}\ f_2 = t_2\ \mathrm{IN}\
\ldots \
\mathrm{LET}\ f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>

t: REAL =
LET x1 = 42,
g = LAMBDA(x:INT): x + 1,
x2 = 2*x1 + 7/2
IN
(LET x3 = g(x1) IN x3 + x2) / x1;

Note that the same symbol = is used, unambiguously, in the syntax of global declarations,
let declarations, and as a predicate symbol.

'''Note:'''
A <math>\mathrm{LET}</math> term with a multiple symbols defines them sequentially.
A parallel version of the <math>\mathrm{LET}</math> construct will be introduced in a later version.

== Built-in theories and their symbols ==

In addition to user-defined symbols, CVC4 terms can use a number of predefined symbols:
the logical symbols, such as <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, etc.,
as well as theory symbols, function symbols belonging to one of the built-in theories.
They are described next, with the theory symbols grouped by theory.

=== Logical Symbols ===

The logical symbols in CVC4's language include
the equality and disequality predicate symbols, respectively written as = and /=,
the multiarity disequality symbol <math>\mathrm{DISTINCT}</math>,
together with the logical constants <math>\mathrm{TRUE}</math>, <math>\mathrm{FALSE}</math>,
the connectives <math>\mathrm{NOT}</math>, <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, <math>\mathrm{XOR}</math>, <math>\Rightarrow</math>, <math>\Leftrightarrow</math>, and
the first-order quantifiers <math>\mathrm{EXISTS}</math> and <math>\mathrm{FORALL}</math>,
all with the standard many-sorted logic semantics.

The binary connectives have infix syntax and type
<math>(\mathrm{BOOLEAN},\mathrm{BOOLEAN}) \to \mathrm{BOOLEAN}</math>.
The symbols = and /=, which are also infix, are instead parametrically polymorphic,
having type <math>(T,T) \to \mathrm{BOOLEAN}</math>
for every first-order type <math>T</math>.
They are interpreted respectively as the identity relation and its complement.

The DISTINCT symbol is both overloaded and polymorphic.
It has type <math>(T,...,T) \to \mathrm{BOOLEAN}</math>
for every sequence <math>(T,...,T)</math> of length <math>n > 0</math>
and first-order type <math>T</math>.
For each <math>n > 0</math>, it is interpreted as the relation
that holds exactly for tuples of pairwise distinct elements.

The syntax for quantifiers is similar to that of the lambda binder.

Here is an example of a formula built just of these logical symbols and variables:

A, B: TYPE;

q: BOOLEAN = FORALL (x,y: A, i,j,k: B):
i = j AND i /= k => EXISTS (z: A): x /= z OR z /= y;

Binding and scoping of quantified variables follows the same rules as
in let expressions.
In particular, a quantifier will shadow in its scope any constant and function symbols
with the same name as one of the variables it quantifies:

A: TYPE;
i, j: INT;

% The first occurrence of i and of j in f are constant symbols,
% the others are variables.

f: BOOLEAN = i = j AND FORALL (i,j: A): i = j OR i /= j;

Optionally, it is also possible to specify instantiation patterns
for quantified variables.
The general syntax for a quantified formula <math>\psi</math> with patterns is

<center>
<math>
Q\;(x_1:T_1, \ldots, x_k:T_k):\; p_1: \ldots\; p_n:\; \varphi
</math>
</center>

where <math>n \geq 0</math>, <math>Q</math> is
either <math>\mathrm{FORALL}</math> or <math>\mathrm{EXISTS}</math>,
<math>\varphi</math> is a term of type <math>\mathrm{BOOLEAN}</math>,
and each of the <math>p_i</math>'s,
a pattern for the quantifier <math>Q\;(x_1:T_1, \ldots, x_k:T_k)</math>, has the form

<center>
<math>
\mathrm{PATTERN}\; (t_1, \ldots, t_m)
</math>
</center>

where <math>m > 0</math> and <math>t_1, \ldots, t_m</math> are
arbitrary binder-free terms (no lets, no quantifiers).
Those terms can contain (free) variables, typically, but not exclusively,
drawn from <math>x_1, \ldots, x_k</math>.
(Additional variables can occur if <math>\psi</math> occurs in a bigger formula
binding those variables.)

A: TYPE;
b, c: A;
p, q: A -> BOOLEAN;
r: (A, A) -> BOOLEAN;

ASSERT FORALL (x0, x1, x2: A):
PATTERN (r(x0, x1), r(x1, x2)):
(r(x0, x1) AND r(x1, x2)) => r(x0, x2) ;

ASSERT FORALL (x: A):
PATTERN (r(x, b)):
PATTERN (r(x, c)):
p(x) => q(x) ;

ASSERT EXISTS (y: A):
FORALL (x: A):
PATTERN (r(x, y), p(y)):
r(x, y) => q(x) ;

Patterns have no logical meaning:
adding them to a formula does not change its semantics.
Their purpose is purely operational, as explained in
the [[#Instantiation Patterns | Instantiation Patterns]] section.

In addition to these constructs, CVC4 also has a general mixfix conditional operator
of the form

<center>
<math>
\mathrm{IF}\ b\ \mathrm{THEN}\ t\ \mathrm{ELSIF}\ b_1\ \mathrm{THEN}\ t_1\ \ldots\ \mathrm{ELSIF}\ b_n\ \mathrm{THEN}\ t_n\ \mathrm{ELSE}\ t_{n+1}\ \mathrm{ENDIF}
</math>
</center>

with <math>n \geq 0</math> where
<math>b, b_1, \ldots, b_n</math> are terms of type <math>\mathrm{BOOLEAN}</math> and
<math>t, t_1, \ldots, t_n, t_{n+1}</math> are terms of the same first-order type <math>T</math>:

% Conditional term
x, y, z, w: REAL;

t: REAL =
IF x > 0 THEN y
ELSIF x >= 1 THEN z
ELSIF x > 2 THEN w
ELSE 2/3 ENDIF;

=== User-defined Functions and Types ===

The theory of user-defined functions,also know in the SMT literature as
the theory ''Equality over Uninterpreted Functions'', or ''EUF'', is in effect
a family of theories of equality parametrized by the basic types and the free symbols
a user can define during a run of CVC4.

This theory has no built-in symbols (other than the logical ones).
Its types consist of ''all and only'' the user-defined types.
Its function symbols consist of ''all and only'' the user-defined free symbols.

=== Arithmetic ===

The real arithmetic theory has two types:
<math>\mathrm{REAL}</math> and <math>\mathrm{INTEGER}</math>
with the latter a subtype of the first.
Its built-in symbols for the usual arithmetic constants
and operators over the type <math>\mathrm{REAL}</math>, each with the expected type:
all numerals 0, 1, ..., as well as - (both unary and binary), +, *, /, <, >, <=, >=.
Application of the binary symbols are in infix form.
Note that + is only binary, and so an expression such as +4 is ill-formed.

Rational values can be expressed in decimal or fractional format,
e.g., 0.1, 23.243241, 1/2, 3/4, and so on.
A leading 0 is mandatory for decimal numbers smaller than one
(e.g., the syntax .3 cannot be used as a shorthand for 0.3).
However, a trailing 0 is ''not'' required for decimals that are whole numbers
(e.g., 3. is allowed as a shorthand for 3.0).
The size of the numerals used in the representation of natural and rational numbers
is unbounded; more accurately, bounded only by the amount of available memory.

=== Bit vectors ===

=== Arrays ===

The theory of arrays is a parametric theory of (total) unary maps.
It comes equipped with mixfix polymorphic selection and update operators, respectively
<center>
<math>\_[\_]</math> and <math>\_\ \mathrm{WITH}\ [\_]\ := \_</math> .
</center>
The semantics of these operators is the expected one:
for all first-order types <math>T_1</math> and <math>T_2</math>,
if <math>a</math> is of type <math>\mathrm{ARRAY}\ T_1 \mathrm{OF}\ T_2</math>,
<math>i</math> is of type <math>T_1</math>, and
<math>v</math> is of type <math>T_2</math>,
* <math>a[i]</math> denotes the value that <math>a</math> associates to index <math>i</math>,
* <math>a\ \mathrm{WITH}\ [i]\ := v</math> denotes a map that associates <math>v</math> to index <math>i</math> and is otherwise identical to <math>a</math>.
Sequential updates can be chained with the shorthand syntax
<math>\_\ \mathrm{WITH}\ [\_]\ := \_, \ldots, [\_]\ := \_</math>.

A: TYPE = ARRAY INT OF REAL;
a: A;
i: INT = 4;

% selection:

elem: REAL = a[i];

% update

a1: A = a WITH [10] := 1/2;

% sequential update
% (syntactic sugar for (a WITH [10] := 2/3) WITH [42] := 3/2)

a2: A = a WITH [10] := 2/3, [42] := 3/2;

Since arrays are just maps, equality between them is extensional, that is,
for two arrays of the same type to be different they have to map at least one
index to differ values.

=== Data types ===

The theory of inductive data types is in fact a family of theories parametrized
by a data type declaration specifying constructors and selectors
for one or more user-defined data types.

No built-in operators other than equality and disequality are provided
for this family in the native language.
Each user-provided data type declaration, however, generates constructor, selector and tester operators
as described in the [[#Inductive Data Types | Inductive Data Types]] section.

=== Tuples and Records ===

Semantically both records and tuples can be seen as special instances
of inductive data types.
CVC4 implements them internally indeed as data types.
In essence, a record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math>
is encoded as a data type of the form

<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\ \ \mathrm{Record} = \mathit{rec}(l_0:T_0, \ldots, l_n:T_n) \\
\mathrm{END};
\end{array}
</math>
</center>

Tuples of length <math>n</math> are in turn special cases of records whose field names are
the numerals from <math>0</math> to <math>n-1</math>.

Externally, tuples and records have their own syntax for constructor and selector operators.
* Records of type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> have the associated record constructor <math>(\#\ l_0 := \_,\; \ldots,\; l_n := \_\ \#)</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.
* Tuples of type <math>[\ T_0, \ldots, T_n\ ]</math> have the associated tuple constructor <math>(\ \_,\; \ldots,\; \_\ )</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.

The selector operators on records and tuples follows a dot notation syntax.

% Record construction and field selection
Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);
k: INT = x.key;
v: REAL = x.weight;

% Tuple construction and projection
y: [REAL, INT, REAL] = ( 4/5, 9, 11/9 );
first_elem: REAL = y.0;
third_elem: REAL = y.2;

Differently from data types, records and tuples are also provided with built-in update operators similar in syntax and semantics to the update operator for arrays.
More precisely, for each record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .l_i\ := \_
</math>
</center>

The operator maps a record <math>r</math> of that type and a value <math>v</math>
of type <math>T_i</math> to the record that stores <math>v</math> in field <math>l_i</math>
and is otherwise identical to <math>r</math>.
Analogously, for each tuple type <math>[T_0, \ldots, T_n]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .i\ := \_
</math>
</center>

with similar semantics.

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = x WITH .weight := 48;

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = y WITH .1 := 3;

Updates to a nested component can be combined in a single WITH operator:

Cache: TYPE = ARRAY [0..100] OF [# addr: INT, data: REAL #];
State: TYPE = [# pc: INT, cache: Cache #];

s0: State;
s1: State = s0 WITH .cache[10].data := 2/3;

Note that, differently from updates on arrays, tuple and record updates are
just additional syntactic sugar.
For instance, the record <code>x1</code> and tuple <code>y1</code> defined above
could have been equivalently defined as follows:

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = (# key := x.key, weight := 48 #);

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = ( y.0, 3, y.1 );

== Commands ==

In addition to declarations of types and function symbols,
the CVC4 native language contains the following commands:

* <math>\mathrm{ASSERT}\ F</math> -- Add the formula <math>F</math> to the current logical context <math>\Gamma</math>.
* [[#CHECKSAT|<math>\mathrm{CHECKSAT}\ F</math>]] -- Check if the formula <math>F</math> is satisfiable in the current logical context (<math>\Gamma \not\models_T \mathrm{NOT}\ F</math>).
* <math>\mathrm{CONTINUE}</math> -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, search for a counter-example different from the current one.
* [[#COUNTEREXAMPLE|<math>\mathrm{COUNTEREXAMPLE}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print the context that is a witness for invalidity/satisfiability.
* [[#COUNTERMODEL|<math>\mathrm{COUNTERMODEL}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print a model that makes the formula invalid/satisfiable. The model is provided in terms of concrete values for each free symbol.
* <math>\mathrm{OPTION}\ o\ v</math> -- Set the command-line option flag <math>o</math> to value <math>v</math>. The argument <math>o</math> is provide as a string literal enclosed in double-quotes and <math>v</math> as an integer value.
* <math>\mathrm{POP}</math> -- Equivalent to <math>\mathrm{POPTO}\ 1</math>
* [[#PUSH and POPTO|<math>\mathrm{POPTO}\ n</math>]] -- Restore the system to the state it was in right before the most recent call to <math>\mathrm{PUSH}</math> made from assertion (stack) level <math>n</math>. Note that the current assertion level is printed as part of the output of the <math>\mathrm{WHERE}</math> command.
* [[#PUSH and POPTO|<math>\mathrm{PUSH}</math>]] -- Save (checkpoint) the current state of the system.
* [[#QUERY|<math>\mathrm{QUERY}\ F</math>]] -- Check if the formula <math>F</math> is valid in the current logical context (<math>\Gamma\models_T F</math>).
* [[#RESTART|<math>\mathrm{RESTART}\ F</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, repeat the check but with the additional assumption <math>F</math> in the context.
* <math>\mathrm{PRINT}\ t</math> -- Parse and print back the term <math>t</math>.
* <math>\mathrm{TRANSFORM}\ t</math> -- Simplify the term <math>t</math> and print the result.
* <math>\mathrm{WHERE}</math> -- Print all the formulas in the current logical context <math>\Gamma</math>.

The remaining commands take a single argument, given as a string literal enclosed in double-quotes.

* <math>\mathrm{ECHO}\ s</math> -- Print string <math>s</math>
* <math>\mathrm{INCLUDE}\ f</math> -- Read commands from file <math>f</math>.
* <math>\mathrm{TRACE}\ f</math> -- Turn on tracing for the debug flag <math>f</math>.
* <math>\mathrm{UNTRACE}\ f</math> -- Turn off tracing for the debug flag <math>f</math>.

Here, we explain some of the above commands in more detail.

=== QUERY ===

The command <math>\mathrm{QUERY}\ F</math> invokes the core functionality of CVC4 to check
the validity of the formula <math>F</math> with respect to the assertions made thus far,
which constitute the context <math>\Gamma</math>.
The argument <math>F</math> must be well typed term of type <math>\mathrm{BOOLEAN}</math>,
as described in [[#Terms and Formulas | Terms and Formulas]].

The execution of this command always terminates and produces one of three possible answers:
<code>valid</code>, <code>invalid</code>, and <code>unknown</code>.

* A <code>valid</code> answer indicates that <math>\Gamma \models_T F</math>. After a query returning such an answer, the logical context <math>\Gamma</math> is exactly as it was before the query.
* An <code>invalid</code> answer indicates that <math>\Gamma \not\models_T F</math>, that is, there is a model of the background theory <math>T</math> that satisfies <math>\Gamma \cup \{\mathrm{NOT}\ F\}</math>. When <math>\mathrm{QUERY}\ F</math> returns <code>invalid</code>, the logical context <math>\Gamma</math> is augmented with a set <math>\Delta</math> of ground (i.e., variable-free) literals such that <math>\Gamma\cup\Delta</math> is satisfiable in <math>T</math>, but <math>\Gamma\cup\Delta\models_T \mathrm{NOT}\ F</math>. In fact, in this case <math>\Delta</math> ''propositionally entails'' <math>\mathrm{NOT}\ F</math>, in the sense that, every truth assignment to the literals of <math>\Delta</math> that satisfies <math>\Delta</math> falsifies <math>F</math>. We call the new context <math>\Gamma\cup\Delta</math> a ''counterexample'' for <math>F</math>.
* An <code>unknown</code> answer is similar to an <code>invalid</code> answer in that additional literals are added to the context which propositionally entail <math>\mathrm{NOT}\ F</math>. The difference in this case is that CVC4 cannot guarantee that <math>\Gamma\cup\Delta</math> is actually satisfiable in <math>T</math>.

CVC4 may report <code>unknown</code> when the context or the query contains
non-linear arithmetic terms or quantifiers.
In all other cases, it is expected to be sound and complete,
i.e., to report <code>Valid</code> if <math>\Gamma \models_T F</math>
and <code>Invalid</code> otherwise.

After an <code>invalid</code> (resp. <code>unknown</code>) answer,
counterexamples (resp. possible counterexamples) can be obtained with
a <math>\mathrm{WHERE}</math>, <math>\mathrm{COUNTEREXAMPLE}</math>,
or <math>\mathrm{COUNTERMODEL}</math> command.


Since the <math>\mathrm{QUERY}</math> command may modify
the current context, if one needs to check several formulas in a row
in the same context, it is a good idea to surround every
query by a <math>\mathrm{PUSH}</math> and <math>\mathrm{POP}</math> invocation
in order to preserve the context:

PUSH;
QUERY <formula>;
POP;

=== CHECKSAT ===

The command <math>\mathrm{CHECKSAT}\ F</math> behaves identically
to <math>\mathrm{QUERY}\ \mathrm{NOT}\ F</math>.

=== RESTART ===

The command <math>\mathrm{RESTART}\ F</math> can only be invoked after an invalid query.
For example, in an interactive setting:

QUERY <formula>;

CVC4> invalid

RESTART <formula2>;

Functionally, the behavior of the above command sequence is identical to the following:

PUSH;
QUERY <formula>;
POP;
ASSERT <formula2>;
QUERY <formula>;

The advantage of using the <math>\mathrm{RESTART}</math> command is that
the first command sequence may be executed much more efficiently that the second.
The reason is that with <math>\mathrm{RESTART}</math> CVC4 will re-use
what it has learned while answering the previous query rather than starting
over from scratch.

=== COUNTERMODEL ===

[More]

=== COUNTEREXAMPLE ===

[More]

=== PUSH and POPTO ===

CVC4's context can be understood as being stratified in ''assertion levels''
which are added and removed in a LIFO fashion.
The system starts at assertion level 0 and every execution of the PUSH command creates a new assertion level after the current one.
Each formula added to the context either by the user, via an ASSERT command, or internally by the system
is added to the most recent assertion level.
Executing POPTO n removes from the context the most recent n assertion levels and all the formulas in them.
So, for instance, POP 1 has the effect of retracting all formulas in the current assertion level (and removing that level).
Note that formulas at assertion level 0 cannot be retracted.

Note: Symbol declarations are always added at assertion level zero. So they are not affected by POPTO commands.

== Instantiation Patterns ==

CVC4 processes each universally quantified formula in the current context
by adding instances of the formula obtained by replacing its universal variables
with ground terms.
Patterns restrict the choice of ground terms for the quantified variables,
with the goal of controlling the potential explosion of ground instances.
In essence, adding patterns to a formula is a way for the user to tell CVC4
to focus only on certain instances which, in the user's opinion, will be
most helpful during a proof.

In more detail, patterns have the following effect on formulas that are found
in the logical context or get added to it later while CVC4 is trying to prove
the validity of some formula <math>F</math>.

If a formula in the current context starts with an existential quantifier,
CVC4 ''Skolemizes'' it, that is, replaces it in the context with the formula
obtained by substituting the existentially quantified variables
by fresh constants and dropping the quantifier.
Any patterns for the existential quantifier are simply ignored.

If a formula starts with a universal quantifier
<math>\mathrm{FORALL}\; (x_1:T_1, \ldots, x_n:T_n)</math>,
CVC4 adds to the context a number of instances of the formula,
with the goal of using them to prove the query <math>F</math> valid.
An instance is obtained by replacing each <math>x_i</math> with a ground term
of the same type occurring in one of the formulas in the context,
and dropping the universal quantifier.
If <math>x_i</math> occurs in a pattern
<math>\mathrm{PATTERN}\; (t_1, \ldots, t_m)</math> for the quantifier,
it will be instantiated only with terms obtained by simultaneously matching
all the terms in the pattern against ground terms in the current context
<math>\Gamma</math>.

Specifically, the matching process produces one or more substitutions
<math>\sigma</math> for the variables in <math>(t_1, \ldots, t_m)</math>
which satisfy the following invariant:
for each <math>i = 1, \ldots, m</math>, <math>\sigma(t_i)</math> is
a ground term and there is a ground term <math>s_i</math> in <math>\Gamma</math>
such that <math>\Gamma \models_T \sigma(t_i) = s_i</math>.
The variables of <math>(x_1:T_1, \ldots, x_n:T_n)</math> that occur
in the pattern are instantiated only with those substitutions
(while any remaining variables are instantiated arbitrarily).

The Skolemized version or the added instances of a context formula may themselves
start with a quantifier.
The same instantiation process is applied to them too, recursively.

Note that the matching mechanism is not limited to syntactic matching
but is modulo the equations asserted in the context.
Because of decidability and/or efficiency limitations, the matching process
is not exhaustive.
CVC4 will typically miss some substitutions that satisfy the invariant above.
As a consequence, it might fail to prove the validity of the query formula
<math>F</math>, which makes CVC4 incomplete for contexts containing
quantified formulas.
It should be noted though that exhaustive matching, which can be achieved
simply by not specifying any patterns, does not yield completeness anyway
since the instantiation of universal variables is still restricted
to just the ground terms in the context,
whereas in general additional ground terms might be needed.

CVC4's native language

2012-12-03T22:27:14Z

Tinelli: /* Commands */

= CVC4 native input language =

The native input language consists of a sequence of symbol declarations and commands, each followed by a semicolon (<code>;</code>).

Any text after the first occurrence of a percent character and to the end of the current line is a comment:

%%% This is a native language comment

== Type System ==

CVC4's type system includes a set of built-in types which can be expanded with additional user-defined types.

The type system consists of ''first-order'' types, ''subtypes'' of first-order types, and ''higher-order'' types, all of which are interpreted as sets.
For convenience, we will sometimes identify below the interpretation of a type with the type itself.

First-order types consist of basic types and structured types. The basic types are <math>\mathrm{BOOLEAN}</math>, <math>\mathrm{REAL}</math>, <math>\mathrm{BITVECTOR}(n)</math> for all <math>n > 0</math>, as well as user-defined basic types (also called uninterpreted types).
The structured types are array, tuple, record types, and ML-style user-defined (inductive) datatypes.

'''Note:''' Currently, subtypes consist only of the built-in subtype <math>\mathrm{INT}</math> of <math>\mathrm{REAL}</math>.

Support for CVC3-style user-defined subtypes will be added in a later release.

Function types are the only higher-order types.
More precisely, they are just second-order types
since function symbols in CVC4, both built-in and user-defined, can take as argument or return only values of
a first-order type.

=== Basic Types ===

==== The BOOLEAN Type ====

The <math>\mathrm{BOOLEAN}</math> type is interpreted as the two-element set of Boolean values
<math>\{\mathrm{TRUE},\; \mathrm{FALSE}\}</math>.

'''Note:''' CVC4's treatment of this type differs from CVC3's where <math>\mathrm{BOOLEAN}</math> is used only as the type of formulas, but not as value type. CVC3 follows the two-tiered structure of classical first-order logic
which distinguishes between formulas and terms, and allows terms to occur in formulas but not vice versa (with the exception of the IF-THEN-ELSE construct).
CVC4 drops the distinction between terms and formulas and defines the latter just as terms of type <math>\mathrm{BOOLEAN}</math>. As such, formulas can occur as subterms of possibly non-Boolean terms.

Example:

% Boolean constants
a, b: BOOLEAN;

% REAL constants
x,y: REAL

% Boolean-valued function, can be used as a predicate symbol
p: REAL -> BOOLEAN;
ASSERT a => p(x - y)

% Real-valued function with Boolean argument
f: BOOLEAN -> REAL;

% The argument of f can be a formula ...
ASSERT f(a OR b) > 0.3 OR p(x);

% ... even a quantified one
ASSERT y = f(FORALL (r: REAL): r < r + 1);

==== The REAL Type ====

The <math>\mathrm{REAL}</math> type is interpreted as the set of real numbers.

Note that these are the (infinite precision) mathematical reals,
not the floating point numbers.
Support for floating point types is planned for future versions.

x, y : REAL;
QUERY (( x <= y ) AND ( y <= x )) => ( x = y );

==== The INT Type ====

The <math>\mathrm{INT}</math> type is interpreted as the set of integer numbers
and is considered a subtype of <math>\mathrm{REAL}</math>.
The latter means in particular that it is possible to mix integer and real terms
in expressions without the need of an explicit ''upcasting'' operator.

Note that these are the (infinite precision) mathematical integers,
not the finite precision machine integers used in most programming languages.
The latter are modeled by [[ #Bitvectors | bit vector ]] types.

x, y : INT;
QUERY ((2 * x + 4 * y <= 1) AND ( y >= x)) => (x <= 0);
z : REAL;
QUERY (2 * x + z <= 3.5) AND (z >= 1);

==== Bit Vector Types ====

For every positive integer <math>n</math>, the type <math>\mathrm{BITVECTOR}(n)</math> is interpreted as the set of all bit vectors of size <math>n</math>.
A rich set of bit vector operators is supported.

==== User-defined Basic Types ====

Users can define new basic types
(often referred to as ''uninterpreted'' types in the SMT literature).
Each such type is interpreted as a set of unspecified cardinality
but disjoint from any other type.

User-defined basic types are created by declarations like the following:

% User declarations of basic types:

MyBrandNewType: TYPE;

Apples, Oranges: TYPE;

=== Structured Types ===

CVC4's structured types are divided into the following families.

==== Array Types ====

Array types are created by the mixfix type constructors <math>\mathrm{ARRAY}\ \_\ \mathrm{OF}\ \_</math>
whose arguments can be instantiated by any value type.

I : TYPE;

%% Array types:

% Arrays with indices from I and values from REAL
Array1: TYPE = ARRAY I OF REAL;

% Arrays with integer indices and array values
Array2: TYPE = ARRAY INT OF (ARRAY INT OF REAL);

% Arrays with integer pair indices and integer values
IntMatrix: TYPE = ARRAY [INT, INT] OF INT;

An array type of the form <math>\mathrm{ARRAY}\ T_1\ \mathrm{OF}\ T_2</math> is interpreted
as the set of all total maps from <math>T_1</math> to <math>T_2</math>.
The main difference with the function type <math>T_1 \to T_2</math> is that arrays,
contrary to functions, are first-class objects of the language, that is, values of an array
type can be arguments or results of functions.
Furthermore, array types come equipped with an update operation.

==== Tuple Types ====

Tuple types are created by the mixfix type constructors

<center>
<math>
\begin{array}{l} [\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ \ ,\ \_\ ] \\[1ex] \ldots \end{array}
</math>
</center>

whose arguments can be instantiated by any value type.

IntArray: TYPE = ARRAY INT OF INT;

% Tuple type declarations

RealPair: TYPE = [REAL, REAL]

MyTuple: TYPE = [ REAL, IntArray, [INT, INT] ];

A tuple type of the form <math>[T_1, \ldots, T_n]</math> is interpreted
as the Cartesian product <math>T_1 \times \cdots \times T_n</math>.

Note that while the types <math>(T_1, \ldots, T_n) \to T</math> and
<math>[T_1 \times \cdots \times T_n] \to T</math> are semantically equivalent,
they are operationally different in CVC4.
The first is the type of functions that take <math>n</math> arguments
of respective type <math>T_1</math>, <math>\ldots</math>, <math>T_n</math>,
while the second is the type of functions that take one argument of an <math>n</math>-tuple type.

==== Record Types ====

Similar to, but more general than tuple types, record types are created by type constructors of the form

<center>
<math>
[\#\ l_1: \_\ ,\ \ldots\ ,\ l_n: \_\ \#]
</math>
</center>

where <math>n > 0</math>, <math>l_1,\ldots, l_n</math> are field labels,
and the arguments can be instantiated with any first-order types.

MyType: TYPE;

% Record declaration

RecordType: TYPE = [# id: REAL, age: INT, info: MyType #];

The order of the fields in a record type is meaningful:
permuting the field names gives a different type.

Note that record types are non-recursive.
For instance, it is not possible to declare a record type called <code>Person</code> containing
a field of type <code>Person</code>.
Recursive types are provided in CVC4 by the more general inductive data types.
(As a matter of fact, both record and tuple types are implemented internally as inductive data types.)

==== Inductive Data Types ====

Inductive data types in CVC4 are similar to inductive data types of functional languages.
They can be parametric or not.

===== Non-Parametric Data Types =====

Non-parametric data types are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1 & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2 & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types, including any <math>A_i</math>.
Such declarations define the data types <math>A_1, \ldots, A_n</math>.
For each data type <math>A_i</math> they introduce:

* constructor symbols <math>cons</math> of type <math>(T_1, \ldots, T_k) \to \mathit{type\_name}_i</math>,
* selector symbols <math>\mathit{sel}_j</math> of type <math>\mathit{type\_name}_i \to T_j</math>, and
* tester symbols <math>\mathit{is\_cons}</math> of type <math>\mathit{type\_name}_i \to \mathrm{BOOLEAN}</math>.

Note that permitting more than one data type to be defined in the same declarations allows
the definition of mutually recursive types.

% simple enumeration type

% implicitly defined are the testers: is_red, is_yellow and is_blue
% (similarly for the other data types)

DATATYPE
PrimaryColor = red | yellow | blue
END;

% infinite set of pairwise distinct values ..., v(-1), v(0), v(1), ...

DATATYPE
Id = v (id: INT)
END;

% ML-style integer lists

DATATYPE
IntList = nil | ins (head: INT, tail: IntList)
END;

% AST for lamba calculus

DATATYPE
Term = var (index: INT)
| apply (arg_1: Term, arg_2: Term)
| lambda (arg: INT, body: Term)
END;

% Trees

DATATYPE
Tree = tree (value: REAL, children: TreeList),
TreeList = nil_tl
| ins_tl (first_t1: Tree, rest_t1: TreeList)
END;

Constructor, selector and tester symbols defined for a data type have global scope.
So, for example, it is not possible for two different data types to use
the same name for a constructor.

An inductive data type is interpreted as a term algebra constructed by the constructor symbols
over some sets of generators.
For example, the type <code>IntList</code> defined above is interpreted as the set
of all terms constructed with <code>nil</code> and <code>ins</code> over the integers.

===== Parametric Data Types =====

Parametric data types are infinite families of (non-parametric) data types
with each family parametrized by one or more type variables.
They are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1[X_{1,1}, \ldots, X_{1,p_1}] & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2[X_{2,1}, \ldots, X_{2,p_2}] & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n[X_{n,1}, \ldots, X_{n,p_n}] & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name parametrized by the type variables <math>X_{i,1}, \ldots, X_{i,p_i}</math>
and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types,
possibly parametrized by <math>X_1, \ldots, X_p</math>, including any <math>A_i</math>.

% Parametric pairs
DATATYPE
Pair[X, Y] = pair (first: X, second: Y)
END;

% Parametric lists

DATATYPE
List[X] = nil | cons (head: X, tail: List[X])
END;

% Parametric trees using the list type above

DATATYPE
Tree[X] = node (value: X, children: List[Tree[X]]),
END;

The declarations above define infinitely many types of the form
Pair[S,T], List[T] and Tree[T] where S and T are first-order types.
Note that the identifier <code>List</code> above, for example, by itself does not denote a type.
In contrast, the terms <code>List[Real]</code>, <code>List[List[Real]]</code>, <code>List[Tree[INT]]</code>,
and so on do.

===== Restriction to Inductive Types =====

By adopting a term algebra semantics, CVC4 allows only ''inductive'' data types,
that is, data types whose values are essentially (labeled, ordered) finite trees.
Infinite structures such as streams or even finite but cyclic ones
such as circular lists are then excluded.
For instance, none of the following declarations define inductive data types,
and are rejected by CVC4:

DATATYPE
IntStream = s (first:INT, rest: IntStream)
END;

DATATYPE
RationalTree = node1 (child: RationalTree)
| node2 (left_child: RationalTree, right_child:RationalTree)
END;

DATATYPE
T1 = c1 (s1: T2),
T2 = c2 (s2: T1)
END;

In concrete, a declaration of <math>n \geq 1</math> datatypes <math>T_1, \ldots, T_n</math> will be rejected if for any one of the types <math>T_1, \ldots, T_n</math>, it is impossible to build a finite term of that type using only the constructors of <math>T_1, \ldots, T_n</math> and free constants of type other than <math>T_1, \ldots, T_n</math>.

Inductive data types are the only types where the user also chooses names for the built-in operations to:

* construct a value of the type (with the constructors),
* extract components from a value (with the selectors), or
* check if a value was constructed with a certain constructor or not (with the testers).

For all the other types, CVC4 provides predefined names for the built-in operations on the type.

=== Function Types ===

Function (<math>\to</math>) types are created by the mixfix type constructors
<center>
<math>
\begin{array}{l}
\_ \to \_ \\[1ex] (\ \_\ ,\ \_\ ) \to \_
\\[1ex] (\ \_\ ,\ \_\ ,\ \_\ ) \to \_
\\[1ex] \ldots
\end{array}
</math>
</center>
whose arguments can be instantiated by any first-order type.

% Function type declarations

UnaryFunType: TYPE = INT -> REAL;

BinaryFunType: TYPE = (REAL, REAL) -> ARRAY REAL OF REAL;

TernaryFunType: TYPE = (REAL, BITVECTOR(4), INT) -> BOOLEAN;

A function type of the form <math>(T_1, \ldots, T_n) \to T</math> with <math>n > 0</math> is interpreted as the set of all ''total'' functions from the Cartesian product <math>T_1 \times \cdots \times T_n</math> to <math>T</math>.

The example above also shows how to introduce type names.
A name like <code>UnaryFunType</code> above is just an abbreviation for the type <math>\mathrm{INT} \to \mathrm{REAL}</math> and can be used interchangeably with it.

In general, any type defined by a type expression <code>E</code> can be given a name with the declaration:

name : TYPE = E;

=== Type Checking ===

In CVC4, formulas and terms are statically typed at the level of types
(as opposed to subtypes) according to the usual rules of first-order many-sorted logic,
with the main difference that formulas are just terms of type <math>BOOLEAN</math>:

* each variable has one associated first-order type,
* each constant symbol has one or more associated first-order types,
* each function symbol has one or more associated function types,
* the type of a term consisting just of a variable is the type associated to that variable,
* the type of a term consisting just of a constant symbol is the type associated to that constant symbol,
* the term obtained by applying a function symbol <math>f</math> to the terms <math>t_1, \ldots, t_n</math> is <math>T</math> if <math>f</math> has type <math>(T_1, \ldots, T_n) \to T</math> and each <math>t_i</math> has type <math>T_i</math>.

Attempting to enter an ill-typed term will result in an error.

Another significant difference with standard many-sorted logic is that
some built-in symbols are parametrically polymorphic.
For instance, the function symbol for extracting the element of any array has
type <math>(\mathit{ARRAY}\ T_1\ \mathit{OF}\ T_2,\; T_1) \to T_2</math>
for all first-order types <math>T_1, T_2</math>.

==== Type Ascription ====

By the type inference rules above some terms might have more than one type.
This can happen with terms built with polymorphic data type constructors
that have more than one return type for the same input type.
In that case, a type ascription operator (<code>::</code>) must be applied
to the constructor to specify the intended return type.

DATATYPE [X]
List[X] = nil | cons (head: X, tail: List[X])
END;

ASSERT y = cons(1, nil::List[REAL]);

DATATYPE [X, Y]
Union[X, Y] = left(val_l: X) | right(val_r: Y)
END;

ASSERT y = left::Union[BOOLEAN, REAL](TRUE);

The constant symbol <math>\mathrm{nil}</math> declared above has infinitely many types
(<math>\mathrm{List}[\mathrm{REAL}]</math>, <math>\mathrm{List}[\mathrm{BOOLEAN}]</math>,
<math>\mathrm{List}[[\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{List}[\mathrm{List}[\mathrm{REAL}]]</math>, ...)
CVC4's type checker requires the user to indicate explicitly the type
of each occurrence of <code>nil</code> in a term.
Similarly,
the injection operator <code>left</code> has infinitely many return types
for the same input type, for instance:
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{REAL}]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, [\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{List}[\mathrm{REAL}]]</math>,
and so on.
Applications of <code>left</code> need to specify the intended returned typed, as shown above.

== Terms and Formulas ==

In addition to type expressions, CVC4 has expressions for terms and for formulas
(i.e., terms of type <math>\mathrm{BOOLEAN}</math>).
By and large, these are standard first-order terms built out of typed variables,
predefined theory-specific operators, free (i.e., user-defined) function symbols,
and quantifiers.
Extensions include an if-then-else operator, lambda abstractions, and local symbol
declarations, as illustrated below.
Note that these extensions still keep CVC4's language first-order.
In particular, lambda abstractions are restricted to take and return only terms of
a first-order type.
Similarly, variables can only be of a first-order type.

A number of built-in function symbols (for instance, the arithmetic ones) are used
as infix operators. All user-defined symbols are used as prefix ones.

User-defined, i.e., free, function symbols include ''constant symbols'' and
''predicate symbols'', respectively nullary function symbols and function symbols
with a <math>\mathrm{BOOLEAN}</math> return type.
These symbols are introduced with global declarations of the form
<math> f_1, \ldots, f_m: T;</math>
where <math>m > 0</math>, <math>f_i</math> are the names of the symbols and
<math>T</math> is their type:

% integer constants

a, b, c: INT;

% real constants

x, y, z: REAL;

% unary function

f1: REAL -> REAL;

% binary function

f2: (REAL, INT) -> REAL;

% unary function with a tuple argument

f3: [INT, REAL] -> BOOLEAN;

% binary predicate

p: (INT, REAL) -> BOOLEAN;

% Propositional "variables"

P, Q; BOOLEAN;

Like type declarations, function symbol declarations like the above have global scope
and must be unique.
In other words, it is not possible to declare a function symbol globally more than once
in the same lexical scope.
This entails among other things that globally-defined free symbols cannot be overloaded
with different types and that theory symbols cannot be redeclared globally as free symbols.

=== Global symbol definitions ===

As with types, a function symbol can be defined as the name of another term
of the corresponding type.
With constant symbols, this is done with a declaration of the form <math>f:T = t;</math> :

c: INT;

i: INT = 5 + 3*c; % i is effectively a shorthand for 5 + 3*c

j: REAL = 3/4;

t: [REAL, INT] = (2/3, -4);

r: [# key: INT, value: REAL #] = (# key := 4, value := (c + 1)/2 #);

f: BOOLEAN = FORALL (x:INT): x <= 0 OR x > c ;

A restriction on constants of type <math>\mathit{BOOLEAN}</math> is that their value
can only be a closed formula, that is, a formula with no free variables.

A term and its name can be used interchangeably in later expressions.
Named terms are often useful for shared subterms (terms used several times in different places)
since their use can make the input exponentially more concise.
Named terms are processed very efficiently by CVC4.
It is much more efficient to associate a complex term with a name directly rather than
to declare a constant and later assert that it is equal to the same term.
This point is explained in more detail later in section [[Commands | Commands]].

More generally, in CVC4 one can associate a term to function symbols of any arity.
For non-constant function symbols this is done with a declaration of the form

<center>
<math>f:(T_1, \ldots, T_n) \to T = \mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t\;;</math>
</center>

where <math>t</math> is any term of type <math>T</math> with free variables
in <math>\{x_1, \ldots, x_n\}</math>.
The lambda binder has the usual semantics and conforms to the usual lexical scoping rules:
within the term <math>t</math> the declaration of the symbols <math>x_1, \ldots, x_n</math>
as local variables of respective type <math>T_1, \ldots, T_n</math> hides any previous
declarations of those symbols that are in scope.

As a general shorthand, when <math>k</math> consecutive types
<math>T_i, \ldots, T_{i+k-1}</math> in the lambda expression
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t</math> are identical, the syntax
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x_i,\ldots, x_{i+k-1}:T_i,\ldots, x:T_n): t</math>
can also be used.

% Global declaration of x as a unary function symbol

x: REAL -> REAL;

% Local declarations of x as variable (hiding the global one)

f: REAL -> REAL = LAMBDA (x: REAL): 2*x + 3;

p: (INT, INT) -> BOOLEAN = LAMBDA (x,i: INT): i*x - 1 > 0;

g: (REAL, INT) -> [REAL, INT] = LAMBDA (x: REAL, i:INT): (x + 1, i - 3);

Note that lambda definitions are not recursive:
the symbol being defined cannot occur in the body of the lambda term.
They should be understood as macros.
For instance, any occurrence of the term <math>f(t)</math>
where <math>f</math> is as defined above will be treated
as if it was the term <math>(2*t + 3)</math>.

=== Local symbol definitions ===

Constant and function symbols can also be declared locally anywhere within a term
by means of a let binder.
This is done with a declaration of the form

<center>
<math>
\mathrm{LET}\ f = s \ \mathrm{IN}\ t ;
</math>
</center>

where <math>t</math> is a term with no free variables, possibly a lambda term.
Let binders can be nested arbitrarily and follow the usual lexical scoping rules.
The following general form
<center>
<math>
\mathrm{LET}\ f_1 = t_1, f_2 = t_2, \ldots, f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>
can used as a shorthand for
<center>
<math>
\mathrm{LET}\ f_1 = t_1\ \mathrm{IN}\
\mathrm{LET}\ f_2 = t_2\ \mathrm{IN}\
\ldots \
\mathrm{LET}\ f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>

t: REAL =
LET x1 = 42,
g = LAMBDA(x:INT): x + 1,
x2 = 2*x1 + 7/2
IN
(LET x3 = g(x1) IN x3 + x2) / x1;

Note that the same symbol = is used, unambiguously, in the syntax of global declarations,
let declarations, and as a predicate symbol.

'''Note:'''
A <math>\mathrm{LET}</math> term with a multiple symbols defines them sequentially.
A parallel version of the <math>\mathrm{LET}</math> construct will be introduced in a later version.

== Built-in theories and their symbols ==

In addition to user-defined symbols, CVC4 terms can use a number of predefined symbols:
the logical symbols, such as <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, etc.,
as well as theory symbols, function symbols belonging to one of the built-in theories.
They are described next, with the theory symbols grouped by theory.

=== Logical Symbols ===

The logical symbols in CVC4's language include
the equality and disequality predicate symbols, respectively written as = and /=,
the multiarity disequality symbol <math>\mathrm{DISTINCT}</math>,
together with the logical constants <math>\mathrm{TRUE}</math>, <math>\mathrm{FALSE}</math>,
the connectives <math>\mathrm{NOT}</math>, <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, <math>\mathrm{XOR}</math>, <math>\Rightarrow</math>, <math>\Leftrightarrow</math>, and
the first-order quantifiers <math>\mathrm{EXISTS}</math> and <math>\mathrm{FORALL}</math>,
all with the standard many-sorted logic semantics.

The binary connectives have infix syntax and type
<math>(\mathrm{BOOLEAN},\mathrm{BOOLEAN}) \to \mathrm{BOOLEAN}</math>.
The symbols = and /=, which are also infix, are instead parametrically polymorphic,
having type <math>(T,T) \to \mathrm{BOOLEAN}</math>
for every first-order type <math>T</math>.
They are interpreted respectively as the identity relation and its complement.

The DISTINCT symbol is both overloaded and polymorphic.
It has type <math>(T,...,T) \to \mathrm{BOOLEAN}</math>
for every sequence <math>(T,...,T)</math> of length <math>n > 0</math>
and first-order type <math>T</math>.
For each <math>n > 0</math>, it is interpreted as the relation
that holds exactly for tuples of pairwise distinct elements.

The syntax for quantifiers is similar to that of the lambda binder.

Here is an example of a formula built just of these logical symbols and variables:

A, B: TYPE;

q: BOOLEAN = FORALL (x,y: A, i,j,k: B):
i = j AND i /= k => EXISTS (z: A): x /= z OR z /= y;

Binding and scoping of quantified variables follows the same rules as
in let expressions.
In particular, a quantifier will shadow in its scope any constant and function symbols
with the same name as one of the variables it quantifies:

A: TYPE;
i, j: INT;

% The first occurrence of i and of j in f are constant symbols,
% the others are variables.

f: BOOLEAN = i = j AND FORALL (i,j: A): i = j OR i /= j;

Optionally, it is also possible to specify instantiation patterns
for quantified variables.
The general syntax for a quantified formula <math>\psi</math> with patterns is

<center>
<math>
Q\;(x_1:T_1, \ldots, x_k:T_k):\; p_1: \ldots\; p_n:\; \varphi
</math>
</center>

where <math>n \geq 0</math>, <math>Q</math> is
either <math>\mathrm{FORALL}</math> or <math>\mathrm{EXISTS}</math>,
<math>\varphi</math> is a term of type <math>\mathrm{BOOLEAN}</math>,
and each of the <math>p_i</math>'s,
a pattern for the quantifier <math>Q\;(x_1:T_1, \ldots, x_k:T_k)</math>, has the form

<center>
<math>
\mathrm{PATTERN}\; (t_1, \ldots, t_m)
</math>
</center>

where <math>m > 0</math> and <math>t_1, \ldots, t_m</math> are
arbitrary binder-free terms (no lets, no quantifiers).
Those terms can contain (free) variables, typically, but not exclusively,
drawn from <math>x_1, \ldots, x_k</math>.
(Additional variables can occur if <math>\psi</math> occurs in a bigger formula
binding those variables.)

A: TYPE;
b, c: A;
p, q: A -> BOOLEAN;
r: (A, A) -> BOOLEAN;

ASSERT FORALL (x0, x1, x2: A):
PATTERN (r(x0, x1), r(x1, x2)):
(r(x0, x1) AND r(x1, x2)) => r(x0, x2) ;

ASSERT FORALL (x: A):
PATTERN (r(x, b)):
PATTERN (r(x, c)):
p(x) => q(x) ;

ASSERT EXISTS (y: A):
FORALL (x: A):
PATTERN (r(x, y), p(y)):
r(x, y) => q(x) ;

Patterns have no logical meaning:
adding them to a formula does not change its semantics.
Their purpose is purely operational, as explained in
the [[#Instantiation Patterns | Instantiation Patterns]] section.

In addition to these constructs, CVC4 also has a general mixfix conditional operator
of the form

<center>
<math>
\mathrm{IF}\ b\ \mathrm{THEN}\ t\ \mathrm{ELSIF}\ b_1\ \mathrm{THEN}\ t_1\ \ldots\ \mathrm{ELSIF}\ b_n\ \mathrm{THEN}\ t_n\ \mathrm{ELSE}\ t_{n+1}\ \mathrm{ENDIF}
</math>
</center>

with <math>n \geq 0</math> where
<math>b, b_1, \ldots, b_n</math> are terms of type <math>\mathrm{BOOLEAN}</math> and
<math>t, t_1, \ldots, t_n, t_{n+1}</math> are terms of the same first-order type <math>T</math>:

% Conditional term
x, y, z, w: REAL;

t: REAL =
IF x > 0 THEN y
ELSIF x >= 1 THEN z
ELSIF x > 2 THEN w
ELSE 2/3 ENDIF;

=== User-defined Functions and Types ===

The theory of user-defined functions,also know in the SMT literature as
the theory ''Equality over Uninterpreted Functions'', or ''EUF'', is in effect
a family of theories of equality parametrized by the basic types and the free symbols
a user can define during a run of CVC4.

This theory has no built-in symbols (other than the logical ones).
Its types consist of ''all and only'' the user-defined types.
Its function symbols consist of ''all and only'' the user-defined free symbols.

=== Arithmetic ===

The real arithmetic theory has two types:
<math>\mathrm{REAL}</math> and <math>\mathrm{INTEGER}</math>
with the latter a subtype of the first.
Its built-in symbols for the usual arithmetic constants
and operators over the type <math>\mathrm{REAL}</math>, each with the expected type:
all numerals 0, 1, ..., as well as - (both unary and binary), +, *, /, <, >, <=, >=.
Application of the binary symbols are in infix form.
Note that + is only binary, and so an expression such as +4 is ill-formed.

Rational values can be expressed in decimal or fractional format,
e.g., 0.1, 23.243241, 1/2, 3/4, and so on.
A leading 0 is mandatory for decimal numbers smaller than one
(e.g., the syntax .3 cannot be used as a shorthand for 0.3).
However, a trailing 0 is ''not'' required for decimals that are whole numbers
(e.g., 3. is allowed as a shorthand for 3.0).
The size of the numerals used in the representation of natural and rational numbers
is unbounded; more accurately, bounded only by the amount of available memory.

=== Bit vectors ===

=== Arrays ===

The theory of arrays is a parametric theory of (total) unary maps.
It comes equipped with mixfix polymorphic selection and update operators, respectively
<center>
<math>\_[\_]</math> and <math>\_\ \mathrm{WITH}\ [\_]\ := \_</math> .
</center>
The semantics of these operators is the expected one:
for all first-order types <math>T_1</math> and <math>T_2</math>,
if <math>a</math> is of type <math>\mathrm{ARRAY}\ T_1 \mathrm{OF}\ T_2</math>,
<math>i</math> is of type <math>T_1</math>, and
<math>v</math> is of type <math>T_2</math>,
* <math>a[i]</math> denotes the value that <math>a</math> associates to index <math>i</math>,
* <math>a\ \mathrm{WITH}\ [i]\ := v</math> denotes a map that associates <math>v</math> to index <math>i</math> and is otherwise identical to <math>a</math>.
Sequential updates can be chained with the shorthand syntax
<math>\_\ \mathrm{WITH}\ [\_]\ := \_, \ldots, [\_]\ := \_</math>.

A: TYPE = ARRAY INT OF REAL;
a: A;
i: INT = 4;

% selection:

elem: REAL = a[i];

% update

a1: A = a WITH [10] := 1/2;

% sequential update
% (syntactic sugar for (a WITH [10] := 2/3) WITH [42] := 3/2)

a2: A = a WITH [10] := 2/3, [42] := 3/2;

Since arrays are just maps, equality between them is extensional, that is,
for two arrays of the same type to be different they have to map at least one
index to differ values.

=== Data types ===

The theory of inductive data types is in fact a family of theories parametrized
by a data type declaration specifying constructors and selectors
for one or more user-defined data types.

No built-in operators other than equality and disequality are provided
for this family in the native language.
Each user-provided data type declaration, however, generates constructor, selector and tester operators
as described in the [[#Inductive Data Types | Inductive Data Types]] section.

=== Tuples and Records ===

Semantically both records and tuples can be seen as special instances
of inductive data types.
CVC4 implements them internally indeed as data types.
In essence, a record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math>
is encoded as a data type of the form

<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\ \ \mathrm{Record} = \mathit{rec}(l_0:T_0, \ldots, l_n:T_n) \\
\mathrm{END};
\end{array}
</math>
</center>

Tuples of length <math>n</math> are in turn special cases of records whose field names are
the numerals from <math>0</math> to <math>n-1</math>.

Externally, tuples and records have their own syntax for constructor and selector operators.
* Records of type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> have the associated record constructor <math>(\#\ l_0 := \_,\; \ldots,\; l_n := \_\ \#)</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.
* Tuples of type <math>[\ T_0, \ldots, T_n\ ]</math> have the associated tuple constructor <math>(\ \_,\; \ldots,\; \_\ )</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.

The selector operators on records and tuples follows a dot notation syntax.

% Record construction and field selection
Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);
k: INT = x.key;
v: REAL = x.weight;

% Tuple construction and projection
y: [REAL, INT, REAL] = ( 4/5, 9, 11/9 );
first_elem: REAL = y.0;
third_elem: REAL = y.2;

Differently from data types, records and tuples are also provided with built-in update operators similar in syntax and semantics to the update operator for arrays.
More precisely, for each record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .l_i\ := \_
</math>
</center>

The operator maps a record <math>r</math> of that type and a value <math>v</math>
of type <math>T_i</math> to the record that stores <math>v</math> in field <math>l_i</math>
and is otherwise identical to <math>r</math>.
Analogously, for each tuple type <math>[T_0, \ldots, T_n]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .i\ := \_
</math>
</center>

with similar semantics.

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = x WITH .weight := 48;

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = y WITH .1 := 3;

Updates to a nested component can be combined in a single WITH operator:

Cache: TYPE = ARRAY [0..100] OF [# addr: INT, data: REAL #];
State: TYPE = [# pc: INT, cache: Cache #];

s0: State;
s1: State = s0 WITH .cache[10].data := 2/3;

Note that, differently from updates on arrays, tuple and record updates are
just additional syntactic sugar.
For instance, the record <code>x1</code> and tuple <code>y1</code> defined above
could have been equivalently defined as follows:

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = (# key := x.key, weight := 48 #);

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = ( y.0, 3, y.1 );

== Commands ==

In addition to declarations of types and function symbols,
the CVC4 native language contains the following commands:

* <math>\mathrm{ASSERT}\ F</math> -- Add the formula <math>F</math> to the current logical context <math>\Gamma</math>.
* [[#CHECKSAT|<math>\mathrm{CHECKSAT}\ F</math>]] -- Check if the formula <math>F</math> is satisfiable in the current logical context (<math>\Gamma \not\models_T \mathrm{NOT}\ F</math>).
* <math>\mathrm{CONTINUE}</math> -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, search for a counter-example different from the current one.
* [[#COUNTEREXAMPLE|<math>\mathrm{COUNTEREXAMPLE}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print the context that is a witness for invalidity/satisfiability.
* [[#COUNTERMODEL|<math>\mathrm{COUNTERMODEL}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print a model that makes the formula invalid/satisfiable. The model is provided in terms of concrete values for each free symbol.
* <math>\mathrm{OPTION}\ o\ v</math> -- Set the command-line option flag <math>o</math> to value <math>v</math>. The argument <math>o</math> is provide as a string literal enclosed in double-quotes and <math>v</math> as an integer value.
* <math>\mathrm{POP}</math> -- Equivalent to <math>\mathrm{POPTO}\ 1</math>
* [[#PUSH and POPTO|<math>\mathrm{POPTO}\ n</math>]] -- Restore the system to the state it was in right before the most recent call to <math>\mathrm{PUSH}</math> made from stack level <math>n</math>. Note that the current stack level is printed as part of the output of the <math>\mathrm{WHERE}</math> command.
* [[#PUSH and POPTO|<math>\mathrm{PUSH}</math>]] -- Save (checkpoint) the current state of the system.
* [[#QUERY|<math>\mathrm{QUERY}\ F</math>]] -- Check if the formula <math>F</math> is valid in the current logical context (<math>\Gamma\models_T F</math>).
* [[#RESTART|<math>\mathrm{RESTART}\ F</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, repeat the check but with the additional assumption <math>F</math> in the context.
* <math>\mathrm{PRINT}\ t</math> -- Parse and print back the term <math>t</math>.
* <math>\mathrm{TRANSFORM}\ t</math> -- Simplify the term <math>t</math> and print the result.
* <math>\mathrm{WHERE}</math> -- Print all the formulas in the current logical context <math>\Gamma</math>.

The remaining commands take a single argument, given as a string literal enclosed in double-quotes.

* <math>\mathrm{ECHO}\ s</math> -- Print string <math>s</math>
* <math>\mathrm{INCLUDE}\ f</math> -- Read commands from file <math>f</math>.
* <math>\mathrm{TRACE}\ f</math> -- Turn on tracing for the debug flag <math>f</math>.
* <math>\mathrm{UNTRACE}\ f</math> -- Turn off tracing for the debug flag <math>f</math>.

Here, we explain some of the above commands in more detail.

=== QUERY ===

The command <math>\mathrm{QUERY}\ F</math> invokes the core functionality of CVC4 to check
the validity of the formula <math>F</math> with respect to the assertions made thus far,
which constitute the context <math>\Gamma</math>.
The argument <math>F</math> must be well typed term of type <math>\mathrm{BOOLEAN}</math>,
as described in [[#Terms and Formulas | Terms and Formulas]].

The execution of this command always terminates and produces one of three possible answers:
<code>valid</code>, <code>invalid</code>, and <code>unknown</code>.

* A <code>valid</code> answer indicates that <math>\Gamma \models_T F</math>. After a query returning such an answer, the logical context <math>\Gamma</math> is exactly as it was before the query.
* An <code>invalid</code> answer indicates that <math>\Gamma \not\models_T F</math>, that is, there is a model of the background theory <math>T</math> that satisfies <math>\Gamma \cup \{\mathrm{NOT}\ F\}</math>. When <math>\mathrm{QUERY}\ F</math> returns <code>invalid</code>, the logical context <math>\Gamma</math> is augmented with a set <math>\Delta</math> of ground (i.e., variable-free) literals such that <math>\Gamma\cup\Delta</math> is satisfiable in <math>T</math>, but <math>\Gamma\cup\Delta\models_T \mathrm{NOT}\ F</math>. In fact, in this case <math>\Delta</math> ''propositionally entails'' <math>\mathrm{NOT}\ F</math>, in the sense that, every truth assignment to the literals of <math>\Delta</math> that satisfies <math>\Delta</math> falsifies <math>F</math>. We call the new context <math>\Gamma\cup\Delta</math> a ''counterexample'' for <math>F</math>.
* An <code>unknown</code> answer is similar to an <code>invalid</code> answer in that additional literals are added to the context which propositionally entail <math>\mathrm{NOT}\ F</math>. The difference in this case is that CVC4 cannot guarantee that <math>\Gamma\cup\Delta</math> is actually satisfiable in <math>T</math>.

CVC4 may report <code>unknown</code> when the context or the query contains
non-linear arithmetic terms or quantifiers.
In all other cases, it is expected to be sound and complete,
i.e., to report <code>Valid</code> if <math>\Gamma \models_T F</math>
and <code>Invalid</code> otherwise.

After an <code>invalid</code> (resp. <code>unknown</code>) answer,
counterexamples (resp. possible counterexamples) can be obtained with
a <math>\mathrm{WHERE}</math>, <math>\mathrm{COUNTEREXAMPLE}</math>,
or <math>\mathrm{COUNTERMODEL}</math> command.


Since the <math>\mathrm{QUERY}</math> command may modify
the current context, if one needs to check several formulas in a row
in the same context, it is a good idea to surround every
query by a <math>\mathrm{PUSH}</math> and <math>\mathrm{POP}</math> invocation
in order to preserve the context:

PUSH;
QUERY <formula>;
POP;

=== CHECKSAT ===

The command <math>\mathrm{CHECKSAT}\ F</math> behaves identically
to <math>\mathrm{QUERY}\ \mathrm{NOT}\ F</math>.

=== RESTART ===

The command <math>\mathrm{RESTART}\ F</math> can only be invoked after an invalid query.
For example, in an interactive setting:

QUERY <formula>;

CVC4> invalid

RESTART <formula2>;

Functionally, the behavior of the above command sequence is identical to the following:

PUSH;
QUERY <formula>;
POP;
ASSERT <formula2>;
QUERY <formula>;

The advantage of using the <math>\mathrm{RESTART}</math> command is that
the first command sequence may be executed much more efficiently that the second.
The reason is that with <math>\mathrm{RESTART}</math> CVC4 will re-use
what it has learned while answering the previous query rather than starting
over from scratch.

=== COUNTERMODEL ===

[More]

=== COUNTEREXAMPLE ===

[More]

=== PUSH and POPTO ===

CVC4's context can be understood as being stratified in ''assertion levels''
which are added and removed in a LIFO fashion.
The system starts at assertion level 0 and every execution of the PUSH command creates a new assertion level after the current one.
Each formula added to the context either by the user, via an ASSERT command, or internally by the system
is added to the most recent assertion level.
Executing POPTO n removes from the context the most recent n assertion levels and all the formulas in them.
So, for instance, POP 1 has the effect of retracting all formulas in the current assertion level (and removing that level).
Note that formulas at assertion level 0 cannot be retracted.

Note: Symbol declarations are always added at assertion level zero. So they are not affected by POPTO commands.

== Instantiation Patterns ==

CVC4 processes each universally quantified formula in the current context
by adding instances of the formula obtained by replacing its universal variables
with ground terms.
Patterns restrict the choice of ground terms for the quantified variables,
with the goal of controlling the potential explosion of ground instances.
In essence, adding patterns to a formula is a way for the user to tell CVC4
to focus only on certain instances which, in the user's opinion, will be
most helpful during a proof.

In more detail, patterns have the following effect on formulas that are found
in the logical context or get added to it later while CVC4 is trying to prove
the validity of some formula <math>F</math>.

If a formula in the current context starts with an existential quantifier,
CVC4 ''Skolemizes'' it, that is, replaces it in the context with the formula
obtained by substituting the existentially quantified variables
by fresh constants and dropping the quantifier.
Any patterns for the existential quantifier are simply ignored.

If a formula starts with a universal quantifier
<math>\mathrm{FORALL}\; (x_1:T_1, \ldots, x_n:T_n)</math>,
CVC4 adds to the context a number of instances of the formula,
with the goal of using them to prove the query <math>F</math> valid.
An instance is obtained by replacing each <math>x_i</math> with a ground term
of the same type occurring in one of the formulas in the context,
and dropping the universal quantifier.
If <math>x_i</math> occurs in a pattern
<math>\mathrm{PATTERN}\; (t_1, \ldots, t_m)</math> for the quantifier,
it will be instantiated only with terms obtained by simultaneously matching
all the terms in the pattern against ground terms in the current context
<math>\Gamma</math>.

Specifically, the matching process produces one or more substitutions
<math>\sigma</math> for the variables in <math>(t_1, \ldots, t_m)</math>
which satisfy the following invariant:
for each <math>i = 1, \ldots, m</math>, <math>\sigma(t_i)</math> is
a ground term and there is a ground term <math>s_i</math> in <math>\Gamma</math>
such that <math>\Gamma \models_T \sigma(t_i) = s_i</math>.
The variables of <math>(x_1:T_1, \ldots, x_n:T_n)</math> that occur
in the pattern are instantiated only with those substitutions
(while any remaining variables are instantiated arbitrarily).

The Skolemized version or the added instances of a context formula may themselves
start with a quantifier.
The same instantiation process is applied to them too, recursively.

Note that the matching mechanism is not limited to syntactic matching
but is modulo the equations asserted in the context.
Because of decidability and/or efficiency limitations, the matching process
is not exhaustive.
CVC4 will typically miss some substitutions that satisfy the invariant above.
As a consequence, it might fail to prove the validity of the query formula
<math>F</math>, which makes CVC4 incomplete for contexts containing
quantified formulas.
It should be noted though that exhaustive matching, which can be achieved
simply by not specifying any patterns, does not yield completeness anyway
since the instantiation of universal variables is still restricted
to just the ground terms in the context,
whereas in general additional ground terms might be needed.

CVC4's native language

2012-12-03T21:42:29Z

Tinelli: /* POPTO */

= CVC4 native input language =

The native input language consists of a sequence of symbol declarations and commands, each followed by a semicolon (<code>;</code>).

Any text after the first occurrence of a percent character and to the end of the current line is a comment:

%%% This is a native language comment

== Type System ==

CVC4's type system includes a set of built-in types which can be expanded with additional user-defined types.

The type system consists of ''first-order'' types, ''subtypes'' of first-order types, and ''higher-order'' types, all of which are interpreted as sets.
For convenience, we will sometimes identify below the interpretation of a type with the type itself.

First-order types consist of basic types and structured types. The basic types are <math>\mathrm{BOOLEAN}</math>, <math>\mathrm{REAL}</math>, <math>\mathrm{BITVECTOR}(n)</math> for all <math>n > 0</math>, as well as user-defined basic types (also called uninterpreted types).
The structured types are array, tuple, record types, and ML-style user-defined (inductive) datatypes.

'''Note:''' Currently, subtypes consist only of the built-in subtype <math>\mathrm{INT}</math> of <math>\mathrm{REAL}</math>.

Support for CVC3-style user-defined subtypes will be added in a later release.

Function types are the only higher-order types.
More precisely, they are just second-order types
since function symbols in CVC4, both built-in and user-defined, can take as argument or return only values of
a first-order type.

=== Basic Types ===

==== The BOOLEAN Type ====

The <math>\mathrm{BOOLEAN}</math> type is interpreted as the two-element set of Boolean values
<math>\{\mathrm{TRUE},\; \mathrm{FALSE}\}</math>.

'''Note:''' CVC4's treatment of this type differs from CVC3's where <math>\mathrm{BOOLEAN}</math> is used only as the type of formulas, but not as value type. CVC3 follows the two-tiered structure of classical first-order logic
which distinguishes between formulas and terms, and allows terms to occur in formulas but not vice versa (with the exception of the IF-THEN-ELSE construct).
CVC4 drops the distinction between terms and formulas and defines the latter just as terms of type <math>\mathrm{BOOLEAN}</math>. As such, formulas can occur as subterms of possibly non-Boolean terms.

Example:

% Boolean constants
a, b: BOOLEAN;

% REAL constants
x,y: REAL

% Boolean-valued function, can be used as a predicate symbol
p: REAL -> BOOLEAN;
ASSERT a => p(x - y)

% Real-valued function with Boolean argument
f: BOOLEAN -> REAL;

% The argument of f can be a formula ...
ASSERT f(a OR b) > 0.3 OR p(x);

% ... even a quantified one
ASSERT y = f(FORALL (r: REAL): r < r + 1);

==== The REAL Type ====

The <math>\mathrm{REAL}</math> type is interpreted as the set of real numbers.

Note that these are the (infinite precision) mathematical reals,
not the floating point numbers.
Support for floating point types is planned for future versions.

x, y : REAL;
QUERY (( x <= y ) AND ( y <= x )) => ( x = y );

==== The INT Type ====

The <math>\mathrm{INT}</math> type is interpreted as the set of integer numbers
and is considered a subtype of <math>\mathrm{REAL}</math>.
The latter means in particular that it is possible to mix integer and real terms
in expressions without the need of an explicit ''upcasting'' operator.

Note that these are the (infinite precision) mathematical integers,
not the finite precision machine integers used in most programming languages.
The latter are modeled by [[ #Bitvectors | bit vector ]] types.

x, y : INT;
QUERY ((2 * x + 4 * y <= 1) AND ( y >= x)) => (x <= 0);
z : REAL;
QUERY (2 * x + z <= 3.5) AND (z >= 1);

==== Bit Vector Types ====

For every positive integer <math>n</math>, the type <math>\mathrm{BITVECTOR}(n)</math> is interpreted as the set of all bit vectors of size <math>n</math>.
A rich set of bit vector operators is supported.

==== User-defined Basic Types ====

Users can define new basic types
(often referred to as ''uninterpreted'' types in the SMT literature).
Each such type is interpreted as a set of unspecified cardinality
but disjoint from any other type.

User-defined basic types are created by declarations like the following:

% User declarations of basic types:

MyBrandNewType: TYPE;

Apples, Oranges: TYPE;

=== Structured Types ===

CVC4's structured types are divided into the following families.

==== Array Types ====

Array types are created by the mixfix type constructors <math>\mathrm{ARRAY}\ \_\ \mathrm{OF}\ \_</math>
whose arguments can be instantiated by any value type.

I : TYPE;

%% Array types:

% Arrays with indices from I and values from REAL
Array1: TYPE = ARRAY I OF REAL;

% Arrays with integer indices and array values
Array2: TYPE = ARRAY INT OF (ARRAY INT OF REAL);

% Arrays with integer pair indices and integer values
IntMatrix: TYPE = ARRAY [INT, INT] OF INT;

An array type of the form <math>\mathrm{ARRAY}\ T_1\ \mathrm{OF}\ T_2</math> is interpreted
as the set of all total maps from <math>T_1</math> to <math>T_2</math>.
The main difference with the function type <math>T_1 \to T_2</math> is that arrays,
contrary to functions, are first-class objects of the language, that is, values of an array
type can be arguments or results of functions.
Furthermore, array types come equipped with an update operation.

==== Tuple Types ====

Tuple types are created by the mixfix type constructors

<center>
<math>
\begin{array}{l} [\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ \ ,\ \_\ ] \\[1ex] \ldots \end{array}
</math>
</center>

whose arguments can be instantiated by any value type.

IntArray: TYPE = ARRAY INT OF INT;

% Tuple type declarations

RealPair: TYPE = [REAL, REAL]

MyTuple: TYPE = [ REAL, IntArray, [INT, INT] ];

A tuple type of the form <math>[T_1, \ldots, T_n]</math> is interpreted
as the Cartesian product <math>T_1 \times \cdots \times T_n</math>.

Note that while the types <math>(T_1, \ldots, T_n) \to T</math> and
<math>[T_1 \times \cdots \times T_n] \to T</math> are semantically equivalent,
they are operationally different in CVC4.
The first is the type of functions that take <math>n</math> arguments
of respective type <math>T_1</math>, <math>\ldots</math>, <math>T_n</math>,
while the second is the type of functions that take one argument of an <math>n</math>-tuple type.

==== Record Types ====

Similar to, but more general than tuple types, record types are created by type constructors of the form

<center>
<math>
[\#\ l_1: \_\ ,\ \ldots\ ,\ l_n: \_\ \#]
</math>
</center>

where <math>n > 0</math>, <math>l_1,\ldots, l_n</math> are field labels,
and the arguments can be instantiated with any first-order types.

MyType: TYPE;

% Record declaration

RecordType: TYPE = [# id: REAL, age: INT, info: MyType #];

The order of the fields in a record type is meaningful:
permuting the field names gives a different type.

Note that record types are non-recursive.
For instance, it is not possible to declare a record type called <code>Person</code> containing
a field of type <code>Person</code>.
Recursive types are provided in CVC4 by the more general inductive data types.
(As a matter of fact, both record and tuple types are implemented internally as inductive data types.)

==== Inductive Data Types ====

Inductive data types in CVC4 are similar to inductive data types of functional languages.
They can be parametric or not.

===== Non-Parametric Data Types =====

Non-parametric data types are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1 & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2 & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types, including any <math>A_i</math>.
Such declarations define the data types <math>A_1, \ldots, A_n</math>.
For each data type <math>A_i</math> they introduce:

* constructor symbols <math>cons</math> of type <math>(T_1, \ldots, T_k) \to \mathit{type\_name}_i</math>,
* selector symbols <math>\mathit{sel}_j</math> of type <math>\mathit{type\_name}_i \to T_j</math>, and
* tester symbols <math>\mathit{is\_cons}</math> of type <math>\mathit{type\_name}_i \to \mathrm{BOOLEAN}</math>.

Note that permitting more than one data type to be defined in the same declarations allows
the definition of mutually recursive types.

% simple enumeration type

% implicitly defined are the testers: is_red, is_yellow and is_blue
% (similarly for the other data types)

DATATYPE
PrimaryColor = red | yellow | blue
END;

% infinite set of pairwise distinct values ..., v(-1), v(0), v(1), ...

DATATYPE
Id = v (id: INT)
END;

% ML-style integer lists

DATATYPE
IntList = nil | ins (head: INT, tail: IntList)
END;

% AST for lamba calculus

DATATYPE
Term = var (index: INT)
| apply (arg_1: Term, arg_2: Term)
| lambda (arg: INT, body: Term)
END;

% Trees

DATATYPE
Tree = tree (value: REAL, children: TreeList),
TreeList = nil_tl
| ins_tl (first_t1: Tree, rest_t1: TreeList)
END;

Constructor, selector and tester symbols defined for a data type have global scope.
So, for example, it is not possible for two different data types to use
the same name for a constructor.

An inductive data type is interpreted as a term algebra constructed by the constructor symbols
over some sets of generators.
For example, the type <code>IntList</code> defined above is interpreted as the set
of all terms constructed with <code>nil</code> and <code>ins</code> over the integers.

===== Parametric Data Types =====

Parametric data types are infinite families of (non-parametric) data types
with each family parametrized by one or more type variables.
They are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1[X_{1,1}, \ldots, X_{1,p_1}] & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2[X_{2,1}, \ldots, X_{2,p_2}] & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n[X_{n,1}, \ldots, X_{n,p_n}] & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name parametrized by the type variables <math>X_{i,1}, \ldots, X_{i,p_i}</math>
and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types,
possibly parametrized by <math>X_1, \ldots, X_p</math>, including any <math>A_i</math>.

% Parametric pairs
DATATYPE
Pair[X, Y] = pair (first: X, second: Y)
END;

% Parametric lists

DATATYPE
List[X] = nil | cons (head: X, tail: List[X])
END;

% Parametric trees using the list type above

DATATYPE
Tree[X] = node (value: X, children: List[Tree[X]]),
END;

The declarations above define infinitely many types of the form
Pair[S,T], List[T] and Tree[T] where S and T are first-order types.
Note that the identifier <code>List</code> above, for example, by itself does not denote a type.
In contrast, the terms <code>List[Real]</code>, <code>List[List[Real]]</code>, <code>List[Tree[INT]]</code>,
and so on do.

===== Restriction to Inductive Types =====

By adopting a term algebra semantics, CVC4 allows only ''inductive'' data types,
that is, data types whose values are essentially (labeled, ordered) finite trees.
Infinite structures such as streams or even finite but cyclic ones
such as circular lists are then excluded.
For instance, none of the following declarations define inductive data types,
and are rejected by CVC4:

DATATYPE
IntStream = s (first:INT, rest: IntStream)
END;

DATATYPE
RationalTree = node1 (child: RationalTree)
| node2 (left_child: RationalTree, right_child:RationalTree)
END;

DATATYPE
T1 = c1 (s1: T2),
T2 = c2 (s2: T1)
END;

In concrete, a declaration of <math>n \geq 1</math> datatypes <math>T_1, \ldots, T_n</math> will be rejected if for any one of the types <math>T_1, \ldots, T_n</math>, it is impossible to build a finite term of that type using only the constructors of <math>T_1, \ldots, T_n</math> and free constants of type other than <math>T_1, \ldots, T_n</math>.

Inductive data types are the only types where the user also chooses names for the built-in operations to:

* construct a value of the type (with the constructors),
* extract components from a value (with the selectors), or
* check if a value was constructed with a certain constructor or not (with the testers).

For all the other types, CVC4 provides predefined names for the built-in operations on the type.

=== Function Types ===

Function (<math>\to</math>) types are created by the mixfix type constructors
<center>
<math>
\begin{array}{l}
\_ \to \_ \\[1ex] (\ \_\ ,\ \_\ ) \to \_
\\[1ex] (\ \_\ ,\ \_\ ,\ \_\ ) \to \_
\\[1ex] \ldots
\end{array}
</math>
</center>
whose arguments can be instantiated by any first-order type.

% Function type declarations

UnaryFunType: TYPE = INT -> REAL;

BinaryFunType: TYPE = (REAL, REAL) -> ARRAY REAL OF REAL;

TernaryFunType: TYPE = (REAL, BITVECTOR(4), INT) -> BOOLEAN;

A function type of the form <math>(T_1, \ldots, T_n) \to T</math> with <math>n > 0</math> is interpreted as the set of all ''total'' functions from the Cartesian product <math>T_1 \times \cdots \times T_n</math> to <math>T</math>.

The example above also shows how to introduce type names.
A name like <code>UnaryFunType</code> above is just an abbreviation for the type <math>\mathrm{INT} \to \mathrm{REAL}</math> and can be used interchangeably with it.

In general, any type defined by a type expression <code>E</code> can be given a name with the declaration:

name : TYPE = E;

=== Type Checking ===

In CVC4, formulas and terms are statically typed at the level of types
(as opposed to subtypes) according to the usual rules of first-order many-sorted logic,
with the main difference that formulas are just terms of type <math>BOOLEAN</math>:

* each variable has one associated first-order type,
* each constant symbol has one or more associated first-order types,
* each function symbol has one or more associated function types,
* the type of a term consisting just of a variable is the type associated to that variable,
* the type of a term consisting just of a constant symbol is the type associated to that constant symbol,
* the term obtained by applying a function symbol <math>f</math> to the terms <math>t_1, \ldots, t_n</math> is <math>T</math> if <math>f</math> has type <math>(T_1, \ldots, T_n) \to T</math> and each <math>t_i</math> has type <math>T_i</math>.

Attempting to enter an ill-typed term will result in an error.

Another significant difference with standard many-sorted logic is that
some built-in symbols are parametrically polymorphic.
For instance, the function symbol for extracting the element of any array has
type <math>(\mathit{ARRAY}\ T_1\ \mathit{OF}\ T_2,\; T_1) \to T_2</math>
for all first-order types <math>T_1, T_2</math>.

==== Type Ascription ====

By the type inference rules above some terms might have more than one type.
This can happen with terms built with polymorphic data type constructors
that have more than one return type for the same input type.
In that case, a type ascription operator (<code>::</code>) must be applied
to the constructor to specify the intended return type.

DATATYPE [X]
List[X] = nil | cons (head: X, tail: List[X])
END;

ASSERT y = cons(1, nil::List[REAL]);

DATATYPE [X, Y]
Union[X, Y] = left(val_l: X) | right(val_r: Y)
END;

ASSERT y = left::Union[BOOLEAN, REAL](TRUE);

The constant symbol <math>\mathrm{nil}</math> declared above has infinitely many types
(<math>\mathrm{List}[\mathrm{REAL}]</math>, <math>\mathrm{List}[\mathrm{BOOLEAN}]</math>,
<math>\mathrm{List}[[\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{List}[\mathrm{List}[\mathrm{REAL}]]</math>, ...)
CVC4's type checker requires the user to indicate explicitly the type
of each occurrence of <code>nil</code> in a term.
Similarly,
the injection operator <code>left</code> has infinitely many return types
for the same input type, for instance:
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{REAL}]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, [\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{List}[\mathrm{REAL}]]</math>,
and so on.
Applications of <code>left</code> need to specify the intended returned typed, as shown above.

== Terms and Formulas ==

In addition to type expressions, CVC4 has expressions for terms and for formulas
(i.e., terms of type <math>\mathrm{BOOLEAN}</math>).
By and large, these are standard first-order terms built out of typed variables,
predefined theory-specific operators, free (i.e., user-defined) function symbols,
and quantifiers.
Extensions include an if-then-else operator, lambda abstractions, and local symbol
declarations, as illustrated below.
Note that these extensions still keep CVC4's language first-order.
In particular, lambda abstractions are restricted to take and return only terms of
a first-order type.
Similarly, variables can only be of a first-order type.

A number of built-in function symbols (for instance, the arithmetic ones) are used
as infix operators. All user-defined symbols are used as prefix ones.

User-defined, i.e., free, function symbols include ''constant symbols'' and
''predicate symbols'', respectively nullary function symbols and function symbols
with a <math>\mathrm{BOOLEAN}</math> return type.
These symbols are introduced with global declarations of the form
<math> f_1, \ldots, f_m: T;</math>
where <math>m > 0</math>, <math>f_i</math> are the names of the symbols and
<math>T</math> is their type:

% integer constants

a, b, c: INT;

% real constants

x, y, z: REAL;

% unary function

f1: REAL -> REAL;

% binary function

f2: (REAL, INT) -> REAL;

% unary function with a tuple argument

f3: [INT, REAL] -> BOOLEAN;

% binary predicate

p: (INT, REAL) -> BOOLEAN;

% Propositional "variables"

P, Q; BOOLEAN;

Like type declarations, function symbol declarations like the above have global scope
and must be unique.
In other words, it is not possible to declare a function symbol globally more than once
in the same lexical scope.
This entails among other things that globally-defined free symbols cannot be overloaded
with different types and that theory symbols cannot be redeclared globally as free symbols.

=== Global symbol definitions ===

As with types, a function symbol can be defined as the name of another term
of the corresponding type.
With constant symbols, this is done with a declaration of the form <math>f:T = t;</math> :

c: INT;

i: INT = 5 + 3*c; % i is effectively a shorthand for 5 + 3*c

j: REAL = 3/4;

t: [REAL, INT] = (2/3, -4);

r: [# key: INT, value: REAL #] = (# key := 4, value := (c + 1)/2 #);

f: BOOLEAN = FORALL (x:INT): x <= 0 OR x > c ;

A restriction on constants of type <math>\mathit{BOOLEAN}</math> is that their value
can only be a closed formula, that is, a formula with no free variables.

A term and its name can be used interchangeably in later expressions.
Named terms are often useful for shared subterms (terms used several times in different places)
since their use can make the input exponentially more concise.
Named terms are processed very efficiently by CVC4.
It is much more efficient to associate a complex term with a name directly rather than
to declare a constant and later assert that it is equal to the same term.
This point is explained in more detail later in section [[Commands | Commands]].

More generally, in CVC4 one can associate a term to function symbols of any arity.
For non-constant function symbols this is done with a declaration of the form

<center>
<math>f:(T_1, \ldots, T_n) \to T = \mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t\;;</math>
</center>

where <math>t</math> is any term of type <math>T</math> with free variables
in <math>\{x_1, \ldots, x_n\}</math>.
The lambda binder has the usual semantics and conforms to the usual lexical scoping rules:
within the term <math>t</math> the declaration of the symbols <math>x_1, \ldots, x_n</math>
as local variables of respective type <math>T_1, \ldots, T_n</math> hides any previous
declarations of those symbols that are in scope.

As a general shorthand, when <math>k</math> consecutive types
<math>T_i, \ldots, T_{i+k-1}</math> in the lambda expression
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t</math> are identical, the syntax
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x_i,\ldots, x_{i+k-1}:T_i,\ldots, x:T_n): t</math>
can also be used.

% Global declaration of x as a unary function symbol

x: REAL -> REAL;

% Local declarations of x as variable (hiding the global one)

f: REAL -> REAL = LAMBDA (x: REAL): 2*x + 3;

p: (INT, INT) -> BOOLEAN = LAMBDA (x,i: INT): i*x - 1 > 0;

g: (REAL, INT) -> [REAL, INT] = LAMBDA (x: REAL, i:INT): (x + 1, i - 3);

Note that lambda definitions are not recursive:
the symbol being defined cannot occur in the body of the lambda term.
They should be understood as macros.
For instance, any occurrence of the term <math>f(t)</math>
where <math>f</math> is as defined above will be treated
as if it was the term <math>(2*t + 3)</math>.

=== Local symbol definitions ===

Constant and function symbols can also be declared locally anywhere within a term
by means of a let binder.
This is done with a declaration of the form

<center>
<math>
\mathrm{LET}\ f = s \ \mathrm{IN}\ t ;
</math>
</center>

where <math>t</math> is a term with no free variables, possibly a lambda term.
Let binders can be nested arbitrarily and follow the usual lexical scoping rules.
The following general form
<center>
<math>
\mathrm{LET}\ f_1 = t_1, f_2 = t_2, \ldots, f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>
can used as a shorthand for
<center>
<math>
\mathrm{LET}\ f_1 = t_1\ \mathrm{IN}\
\mathrm{LET}\ f_2 = t_2\ \mathrm{IN}\
\ldots \
\mathrm{LET}\ f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>

t: REAL =
LET x1 = 42,
g = LAMBDA(x:INT): x + 1,
x2 = 2*x1 + 7/2
IN
(LET x3 = g(x1) IN x3 + x2) / x1;

Note that the same symbol = is used, unambiguously, in the syntax of global declarations,
let declarations, and as a predicate symbol.

'''Note:'''
A <math>\mathrm{LET}</math> term with a multiple symbols defines them sequentially.
A parallel version of the <math>\mathrm{LET}</math> construct will be introduced in a later version.

== Built-in theories and their symbols ==

In addition to user-defined symbols, CVC4 terms can use a number of predefined symbols:
the logical symbols, such as <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, etc.,
as well as theory symbols, function symbols belonging to one of the built-in theories.
They are described next, with the theory symbols grouped by theory.

=== Logical Symbols ===

The logical symbols in CVC4's language include
the equality and disequality predicate symbols, respectively written as = and /=,
the multiarity disequality symbol <math>\mathrm{DISTINCT}</math>,
together with the logical constants <math>\mathrm{TRUE}</math>, <math>\mathrm{FALSE}</math>,
the connectives <math>\mathrm{NOT}</math>, <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, <math>\mathrm{XOR}</math>, <math>\Rightarrow</math>, <math>\Leftrightarrow</math>, and
the first-order quantifiers <math>\mathrm{EXISTS}</math> and <math>\mathrm{FORALL}</math>,
all with the standard many-sorted logic semantics.

The binary connectives have infix syntax and type
<math>(\mathrm{BOOLEAN},\mathrm{BOOLEAN}) \to \mathrm{BOOLEAN}</math>.
The symbols = and /=, which are also infix, are instead parametrically polymorphic,
having type <math>(T,T) \to \mathrm{BOOLEAN}</math>
for every first-order type <math>T</math>.
They are interpreted respectively as the identity relation and its complement.

The DISTINCT symbol is both overloaded and polymorphic.
It has type <math>(T,...,T) \to \mathrm{BOOLEAN}</math>
for every sequence <math>(T,...,T)</math> of length <math>n > 0</math>
and first-order type <math>T</math>.
For each <math>n > 0</math>, it is interpreted as the relation
that holds exactly for tuples of pairwise distinct elements.

The syntax for quantifiers is similar to that of the lambda binder.

Here is an example of a formula built just of these logical symbols and variables:

A, B: TYPE;

q: BOOLEAN = FORALL (x,y: A, i,j,k: B):
i = j AND i /= k => EXISTS (z: A): x /= z OR z /= y;

Binding and scoping of quantified variables follows the same rules as
in let expressions.
In particular, a quantifier will shadow in its scope any constant and function symbols
with the same name as one of the variables it quantifies:

A: TYPE;
i, j: INT;

% The first occurrence of i and of j in f are constant symbols,
% the others are variables.

f: BOOLEAN = i = j AND FORALL (i,j: A): i = j OR i /= j;

Optionally, it is also possible to specify instantiation patterns
for quantified variables.
The general syntax for a quantified formula <math>\psi</math> with patterns is

<center>
<math>
Q\;(x_1:T_1, \ldots, x_k:T_k):\; p_1: \ldots\; p_n:\; \varphi
</math>
</center>

where <math>n \geq 0</math>, <math>Q</math> is
either <math>\mathrm{FORALL}</math> or <math>\mathrm{EXISTS}</math>,
<math>\varphi</math> is a term of type <math>\mathrm{BOOLEAN}</math>,
and each of the <math>p_i</math>'s,
a pattern for the quantifier <math>Q\;(x_1:T_1, \ldots, x_k:T_k)</math>, has the form

<center>
<math>
\mathrm{PATTERN}\; (t_1, \ldots, t_m)
</math>
</center>

where <math>m > 0</math> and <math>t_1, \ldots, t_m</math> are
arbitrary binder-free terms (no lets, no quantifiers).
Those terms can contain (free) variables, typically, but not exclusively,
drawn from <math>x_1, \ldots, x_k</math>.
(Additional variables can occur if <math>\psi</math> occurs in a bigger formula
binding those variables.)

A: TYPE;
b, c: A;
p, q: A -> BOOLEAN;
r: (A, A) -> BOOLEAN;

ASSERT FORALL (x0, x1, x2: A):
PATTERN (r(x0, x1), r(x1, x2)):
(r(x0, x1) AND r(x1, x2)) => r(x0, x2) ;

ASSERT FORALL (x: A):
PATTERN (r(x, b)):
PATTERN (r(x, c)):
p(x) => q(x) ;

ASSERT EXISTS (y: A):
FORALL (x: A):
PATTERN (r(x, y), p(y)):
r(x, y) => q(x) ;

Patterns have no logical meaning:
adding them to a formula does not change its semantics.
Their purpose is purely operational, as explained in
the [[#Instantiation Patterns | Instantiation Patterns]] section.

In addition to these constructs, CVC4 also has a general mixfix conditional operator
of the form

<center>
<math>
\mathrm{IF}\ b\ \mathrm{THEN}\ t\ \mathrm{ELSIF}\ b_1\ \mathrm{THEN}\ t_1\ \ldots\ \mathrm{ELSIF}\ b_n\ \mathrm{THEN}\ t_n\ \mathrm{ELSE}\ t_{n+1}\ \mathrm{ENDIF}
</math>
</center>

with <math>n \geq 0</math> where
<math>b, b_1, \ldots, b_n</math> are terms of type <math>\mathrm{BOOLEAN}</math> and
<math>t, t_1, \ldots, t_n, t_{n+1}</math> are terms of the same first-order type <math>T</math>:

% Conditional term
x, y, z, w: REAL;

t: REAL =
IF x > 0 THEN y
ELSIF x >= 1 THEN z
ELSIF x > 2 THEN w
ELSE 2/3 ENDIF;

=== User-defined Functions and Types ===

The theory of user-defined functions,also know in the SMT literature as
the theory ''Equality over Uninterpreted Functions'', or ''EUF'', is in effect
a family of theories of equality parametrized by the basic types and the free symbols
a user can define during a run of CVC4.

This theory has no built-in symbols (other than the logical ones).
Its types consist of ''all and only'' the user-defined types.
Its function symbols consist of ''all and only'' the user-defined free symbols.

=== Arithmetic ===

The real arithmetic theory has two types:
<math>\mathrm{REAL}</math> and <math>\mathrm{INTEGER}</math>
with the latter a subtype of the first.
Its built-in symbols for the usual arithmetic constants
and operators over the type <math>\mathrm{REAL}</math>, each with the expected type:
all numerals 0, 1, ..., as well as - (both unary and binary), +, *, /, <, >, <=, >=.
Application of the binary symbols are in infix form.
Note that + is only binary, and so an expression such as +4 is ill-formed.

Rational values can be expressed in decimal or fractional format,
e.g., 0.1, 23.243241, 1/2, 3/4, and so on.
A leading 0 is mandatory for decimal numbers smaller than one
(e.g., the syntax .3 cannot be used as a shorthand for 0.3).
However, a trailing 0 is ''not'' required for decimals that are whole numbers
(e.g., 3. is allowed as a shorthand for 3.0).
The size of the numerals used in the representation of natural and rational numbers
is unbounded; more accurately, bounded only by the amount of available memory.

=== Bit vectors ===

=== Arrays ===

The theory of arrays is a parametric theory of (total) unary maps.
It comes equipped with mixfix polymorphic selection and update operators, respectively
<center>
<math>\_[\_]</math> and <math>\_\ \mathrm{WITH}\ [\_]\ := \_</math> .
</center>
The semantics of these operators is the expected one:
for all first-order types <math>T_1</math> and <math>T_2</math>,
if <math>a</math> is of type <math>\mathrm{ARRAY}\ T_1 \mathrm{OF}\ T_2</math>,
<math>i</math> is of type <math>T_1</math>, and
<math>v</math> is of type <math>T_2</math>,
* <math>a[i]</math> denotes the value that <math>a</math> associates to index <math>i</math>,
* <math>a\ \mathrm{WITH}\ [i]\ := v</math> denotes a map that associates <math>v</math> to index <math>i</math> and is otherwise identical to <math>a</math>.
Sequential updates can be chained with the shorthand syntax
<math>\_\ \mathrm{WITH}\ [\_]\ := \_, \ldots, [\_]\ := \_</math>.

A: TYPE = ARRAY INT OF REAL;
a: A;
i: INT = 4;

% selection:

elem: REAL = a[i];

% update

a1: A = a WITH [10] := 1/2;

% sequential update
% (syntactic sugar for (a WITH [10] := 2/3) WITH [42] := 3/2)

a2: A = a WITH [10] := 2/3, [42] := 3/2;

Since arrays are just maps, equality between them is extensional, that is,
for two arrays of the same type to be different they have to map at least one
index to differ values.

=== Data types ===

The theory of inductive data types is in fact a family of theories parametrized
by a data type declaration specifying constructors and selectors
for one or more user-defined data types.

No built-in operators other than equality and disequality are provided
for this family in the native language.
Each user-provided data type declaration, however, generates constructor, selector and tester operators
as described in the [[#Inductive Data Types | Inductive Data Types]] section.

=== Tuples and Records ===

Semantically both records and tuples can be seen as special instances
of inductive data types.
CVC4 implements them internally indeed as data types.
In essence, a record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math>
is encoded as a data type of the form

<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\ \ \mathrm{Record} = \mathit{rec}(l_0:T_0, \ldots, l_n:T_n) \\
\mathrm{END};
\end{array}
</math>
</center>

Tuples of length <math>n</math> are in turn special cases of records whose field names are
the numerals from <math>0</math> to <math>n-1</math>.

Externally, tuples and records have their own syntax for constructor and selector operators.
* Records of type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> have the associated record constructor <math>(\#\ l_0 := \_,\; \ldots,\; l_n := \_\ \#)</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.
* Tuples of type <math>[\ T_0, \ldots, T_n\ ]</math> have the associated tuple constructor <math>(\ \_,\; \ldots,\; \_\ )</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.

The selector operators on records and tuples follows a dot notation syntax.

% Record construction and field selection
Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);
k: INT = x.key;
v: REAL = x.weight;

% Tuple construction and projection
y: [REAL, INT, REAL] = ( 4/5, 9, 11/9 );
first_elem: REAL = y.0;
third_elem: REAL = y.2;

Differently from data types, records and tuples are also provided with built-in update operators similar in syntax and semantics to the update operator for arrays.
More precisely, for each record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .l_i\ := \_
</math>
</center>

The operator maps a record <math>r</math> of that type and a value <math>v</math>
of type <math>T_i</math> to the record that stores <math>v</math> in field <math>l_i</math>
and is otherwise identical to <math>r</math>.
Analogously, for each tuple type <math>[T_0, \ldots, T_n]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .i\ := \_
</math>
</center>

with similar semantics.

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = x WITH .weight := 48;

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = y WITH .1 := 3;

Updates to a nested component can be combined in a single WITH operator:

Cache: TYPE = ARRAY [0..100] OF [# addr: INT, data: REAL #];
State: TYPE = [# pc: INT, cache: Cache #];

s0: State;
s1: State = s0 WITH .cache[10].data := 2/3;

Note that, differently from updates on arrays, tuple and record updates are
just additional syntactic sugar.
For instance, the record <code>x1</code> and tuple <code>y1</code> defined above
could have been equivalently defined as follows:

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = (# key := x.key, weight := 48 #);

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = ( y.0, 3, y.1 );

== Commands ==

In addition to declarations of types and function symbols,
the CVC4 native language contains the following commands:

* <math>\mathrm{ASSERT}\ F</math> -- Add the formula <math>F</math> to the current logical context <math>\Gamma</math>.
* [[#CHECKSAT|<math>\mathrm{CHECKSAT}\ F</math>]] -- Check if the formula <math>F</math> is satisfiable in the current logical context (<math>\Gamma \not\models_T \mathrm{NOT}\ F</math>).
* <math>\mathrm{CONTINUE}</math> -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, search for a counter-example different from the current one.
* [[#COUNTEREXAMPLE|<math>\mathrm{COUNTEREXAMPLE}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print the context that is a witness for invalidity/satisfiability.
* [[#COUNTERMODEL|<math>\mathrm{COUNTERMODEL}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print a model that makes the formula invalid/satisfiable. The model is provided in terms of concrete values for each free symbol.
* <math>\mathrm{OPTION}\ o\ v</math> -- Set the command-line option flag <math>o</math> to value <math>v</math>. The argument <math>o</math> is provide as a string literal enclosed in double-quotes and <math>v</math> as an integer value.
* <math>\mathrm{POP}</math> -- Equivalent to <math>\mathrm{POPTO}\ 1</math>
* [[#POPTO|<math>\mathrm{POPTO}\ n</math>]] -- Restore the system to the state it was in right before the most recent call to <math>\mathrm{PUSH}</math> made from stack level <math>n</math>. Note that the current stack level is printed as part of the output of the <math>\mathrm{WHERE}</math> command.
* <math>\mathrm{PUSH}</math> -- Save (checkpoint) the current state of the system.
* [[#QUERY|<math>\mathrm{QUERY}\ F</math>]] -- Check if the formula <math>F</math> is valid in the current logical context (<math>\Gamma\models_T F</math>).
* [[#RESTART|<math>\mathrm{RESTART}\ F</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, repeat the check but with the additional assumption <math>F</math> in the context.
* <math>\mathrm{PRINT}\ t</math> -- Parse and print back the term <math>t</math>.
* <math>\mathrm{TRANSFORM}\ t</math> -- Simplify the term <math>t</math> and print the result.
* <math>\mathrm{WHERE}</math> -- Print all the formulas in the current logical context <math>\Gamma</math>.

The remaining commands take a single argument, given as a string literal enclosed in double-quotes.

* <math>\mathrm{ECHO}\ s</math> -- Print string <math>s</math>
* <math>\mathrm{INCLUDE}\ f</math> -- Read commands from file <math>f</math>.
* <math>\mathrm{TRACE}\ f</math> -- Turn on tracing for the debug flag <math>f</math>.
* <math>\mathrm{UNTRACE}\ f</math> -- Turn off tracing for the debug flag <math>f</math>.

Here, we explain some of the above commands in more detail.

=== QUERY ===

The command <math>\mathrm{QUERY}\ F</math> invokes the core functionality of CVC4 to check
the validity of the formula <math>F</math> with respect to the assertions made thus far,
which constitute the context <math>\Gamma</math>.
The argument <math>F</math> must be well typed term of type <math>\mathrm{BOOLEAN}</math>,
as described in [[#Terms and Formulas | Terms and Formulas]].

The execution of this command always terminates and produces one of three possible answers:
<code>valid</code>, <code>invalid</code>, and <code>unknown</code>.

* A <code>valid</code> answer indicates that <math>\Gamma \models_T F</math>. After a query returning such an answer, the logical context <math>\Gamma</math> is exactly as it was before the query.
* An <code>invalid</code> answer indicates that <math>\Gamma \not\models_T F</math>, that is, there is a model of the background theory <math>T</math> that satisfies <math>\Gamma \cup \{\mathrm{NOT}\ F\}</math>. When <math>\mathrm{QUERY}\ F</math> returns <code>invalid</code>, the logical context <math>\Gamma</math> is augmented with a set <math>\Delta</math> of ground (i.e., variable-free) literals such that <math>\Gamma\cup\Delta</math> is satisfiable in <math>T</math>, but <math>\Gamma\cup\Delta\models_T \mathrm{NOT}\ F</math>. In fact, in this case <math>\Delta</math> ''propositionally entails'' <math>\mathrm{NOT}\ F</math>, in the sense that, every truth assignment to the literals of <math>\Delta</math> that satisfies <math>\Delta</math> falsifies <math>F</math>. We call the new context <math>\Gamma\cup\Delta</math> a ''counterexample'' for <math>F</math>.
* An <code>unknown</code> answer is similar to an <code>invalid</code> answer in that additional literals are added to the context which propositionally entail <math>\mathrm{NOT}\ F</math>. The difference in this case is that CVC4 cannot guarantee that <math>\Gamma\cup\Delta</math> is actually satisfiable in <math>T</math>.

CVC4 may report <code>unknown</code> when the context or the query contains
non-linear arithmetic terms or quantifiers.
In all other cases, it is expected to be sound and complete,
i.e., to report <code>Valid</code> if <math>\Gamma \models_T F</math>
and <code>Invalid</code> otherwise.

After an <code>invalid</code> (resp. <code>unknown</code>) answer,
counterexamples (resp. possible counterexamples) can be obtained with
a <math>\mathrm{WHERE}</math>, <math>\mathrm{COUNTEREXAMPLE}</math>,
or <math>\mathrm{COUNTERMODEL}</math> command.


Since the <math>\mathrm{QUERY}</math> command may modify
the current context, if one needs to check several formulas in a row
in the same context, it is a good idea to surround every
query by a <math>\mathrm{PUSH}</math> and <math>\mathrm{POP}</math> invocation
in order to preserve the context:

PUSH;
QUERY <formula>;
POP;

=== CHECKSAT ===

The command <math>\mathrm{CHECKSAT}\ F</math> behaves identically
to <math>\mathrm{QUERY}\ \mathrm{NOT}\ F</math>.

=== RESTART ===

The command <math>\mathrm{RESTART}\ F</math> can only be invoked after an invalid query.
For example, in an interactive setting:

QUERY <formula>;

CVC4> invalid

RESTART <formula2>;

Functionally, the behavior of the above command sequence is identical to the following:

PUSH;
QUERY <formula>;
POP;
ASSERT <formula2>;
QUERY <formula>;

The advantage of using the <math>\mathrm{RESTART}</math> command is that
the first command sequence may be executed much more efficiently that the second.
The reason is that with <math>\mathrm{RESTART}</math> CVC4 will re-use
what it has learned while answering the previous query rather than starting
over from scratch.

=== COUNTERMODEL ===

[More]

=== COUNTEREXAMPLE ===

[More]

=== PUSH and POPTO ===

CVC4's context can be understood as being stratified in ''assertion levels''
which are added and removed in a LIFO fashion.
The system starts at assertion level 0 and every execution of the PUSH command creates a new assertion level after the current one.
Each formula added to the context either by the user, via an ASSERT command, or internally by the system
is added to the most recent assertion level.
Executing POPTO n removes from the context the most recent n assertion levels and all the formulas in them.
So, for instance, POP 1 has the effect of retracting all formulas in the current assertion level (and removing that level).
Note that formulas at assertion level 0 cannot be retracted.

Note: Symbol declarations are always added at assertion level zero. So they are not affected by POPTO commands.

== Instantiation Patterns ==

CVC4 processes each universally quantified formula in the current context
by adding instances of the formula obtained by replacing its universal variables
with ground terms.
Patterns restrict the choice of ground terms for the quantified variables,
with the goal of controlling the potential explosion of ground instances.
In essence, adding patterns to a formula is a way for the user to tell CVC4
to focus only on certain instances which, in the user's opinion, will be
most helpful during a proof.

In more detail, patterns have the following effect on formulas that are found
in the logical context or get added to it later while CVC4 is trying to prove
the validity of some formula <math>F</math>.

If a formula in the current context starts with an existential quantifier,
CVC4 ''Skolemizes'' it, that is, replaces it in the context with the formula
obtained by substituting the existentially quantified variables
by fresh constants and dropping the quantifier.
Any patterns for the existential quantifier are simply ignored.

If a formula starts with a universal quantifier
<math>\mathrm{FORALL}\; (x_1:T_1, \ldots, x_n:T_n)</math>,
CVC4 adds to the context a number of instances of the formula,
with the goal of using them to prove the query <math>F</math> valid.
An instance is obtained by replacing each <math>x_i</math> with a ground term
of the same type occurring in one of the formulas in the context,
and dropping the universal quantifier.
If <math>x_i</math> occurs in a pattern
<math>\mathrm{PATTERN}\; (t_1, \ldots, t_m)</math> for the quantifier,
it will be instantiated only with terms obtained by simultaneously matching
all the terms in the pattern against ground terms in the current context
<math>\Gamma</math>.

Specifically, the matching process produces one or more substitutions
<math>\sigma</math> for the variables in <math>(t_1, \ldots, t_m)</math>
which satisfy the following invariant:
for each <math>i = 1, \ldots, m</math>, <math>\sigma(t_i)</math> is
a ground term and there is a ground term <math>s_i</math> in <math>\Gamma</math>
such that <math>\Gamma \models_T \sigma(t_i) = s_i</math>.
The variables of <math>(x_1:T_1, \ldots, x_n:T_n)</math> that occur
in the pattern are instantiated only with those substitutions
(while any remaining variables are instantiated arbitrarily).

The Skolemized version or the added instances of a context formula may themselves
start with a quantifier.
The same instantiation process is applied to them too, recursively.

Note that the matching mechanism is not limited to syntactic matching
but is modulo the equations asserted in the context.
Because of decidability and/or efficiency limitations, the matching process
is not exhaustive.
CVC4 will typically miss some substitutions that satisfy the invariant above.
As a consequence, it might fail to prove the validity of the query formula
<math>F</math>, which makes CVC4 incomplete for contexts containing
quantified formulas.
It should be noted though that exhaustive matching, which can be achieved
simply by not specifying any patterns, does not yield completeness anyway
since the instantiation of universal variables is still restricted
to just the ground terms in the context,
whereas in general additional ground terms might be needed.

CVC4's native language

2012-12-03T21:21:38Z

Tinelli: /* The BOOLEAN Type */

= CVC4 native input language =

The native input language consists of a sequence of symbol declarations and commands, each followed by a semicolon (<code>;</code>).

Any text after the first occurrence of a percent character and to the end of the current line is a comment:

%%% This is a native language comment

== Type System ==

CVC4's type system includes a set of built-in types which can be expanded with additional user-defined types.

The type system consists of ''first-order'' types, ''subtypes'' of first-order types, and ''higher-order'' types, all of which are interpreted as sets.
For convenience, we will sometimes identify below the interpretation of a type with the type itself.

First-order types consist of basic types and structured types. The basic types are <math>\mathrm{BOOLEAN}</math>, <math>\mathrm{REAL}</math>, <math>\mathrm{BITVECTOR}(n)</math> for all <math>n > 0</math>, as well as user-defined basic types (also called uninterpreted types).
The structured types are array, tuple, record types, and ML-style user-defined (inductive) datatypes.

'''Note:''' Currently, subtypes consist only of the built-in subtype <math>\mathrm{INT}</math> of <math>\mathrm{REAL}</math>.

Support for CVC3-style user-defined subtypes will be added in a later release.

Function types are the only higher-order types.
More precisely, they are just second-order types
since function symbols in CVC4, both built-in and user-defined, can take as argument or return only values of
a first-order type.

=== Basic Types ===

==== The BOOLEAN Type ====

The <math>\mathrm{BOOLEAN}</math> type is interpreted as the two-element set of Boolean values
<math>\{\mathrm{TRUE},\; \mathrm{FALSE}\}</math>.

'''Note:''' CVC4's treatment of this type differs from CVC3's where <math>\mathrm{BOOLEAN}</math> is used only as the type of formulas, but not as value type. CVC3 follows the two-tiered structure of classical first-order logic
which distinguishes between formulas and terms, and allows terms to occur in formulas but not vice versa (with the exception of the IF-THEN-ELSE construct).
CVC4 drops the distinction between terms and formulas and defines the latter just as terms of type <math>\mathrm{BOOLEAN}</math>. As such, formulas can occur as subterms of possibly non-Boolean terms.

Example:

% Boolean constants
a, b: BOOLEAN;

% REAL constants
x,y: REAL

% Boolean-valued function, can be used as a predicate symbol
p: REAL -> BOOLEAN;
ASSERT a => p(x - y)

% Real-valued function with Boolean argument
f: BOOLEAN -> REAL;

% The argument of f can be a formula ...
ASSERT f(a OR b) > 0.3 OR p(x);

% ... even a quantified one
ASSERT y = f(FORALL (r: REAL): r < r + 1);

==== The REAL Type ====

The <math>\mathrm{REAL}</math> type is interpreted as the set of real numbers.

Note that these are the (infinite precision) mathematical reals,
not the floating point numbers.
Support for floating point types is planned for future versions.

x, y : REAL;
QUERY (( x <= y ) AND ( y <= x )) => ( x = y );

==== The INT Type ====

The <math>\mathrm{INT}</math> type is interpreted as the set of integer numbers
and is considered a subtype of <math>\mathrm{REAL}</math>.
The latter means in particular that it is possible to mix integer and real terms
in expressions without the need of an explicit ''upcasting'' operator.

Note that these are the (infinite precision) mathematical integers,
not the finite precision machine integers used in most programming languages.
The latter are modeled by [[ #Bitvectors | bit vector ]] types.

x, y : INT;
QUERY ((2 * x + 4 * y <= 1) AND ( y >= x)) => (x <= 0);
z : REAL;
QUERY (2 * x + z <= 3.5) AND (z >= 1);

==== Bit Vector Types ====

For every positive integer <math>n</math>, the type <math>\mathrm{BITVECTOR}(n)</math> is interpreted as the set of all bit vectors of size <math>n</math>.
A rich set of bit vector operators is supported.

==== User-defined Basic Types ====

Users can define new basic types
(often referred to as ''uninterpreted'' types in the SMT literature).
Each such type is interpreted as a set of unspecified cardinality
but disjoint from any other type.

User-defined basic types are created by declarations like the following:

% User declarations of basic types:

MyBrandNewType: TYPE;

Apples, Oranges: TYPE;

=== Structured Types ===

CVC4's structured types are divided into the following families.

==== Array Types ====

Array types are created by the mixfix type constructors <math>\mathrm{ARRAY}\ \_\ \mathrm{OF}\ \_</math>
whose arguments can be instantiated by any value type.

I : TYPE;

%% Array types:

% Arrays with indices from I and values from REAL
Array1: TYPE = ARRAY I OF REAL;

% Arrays with integer indices and array values
Array2: TYPE = ARRAY INT OF (ARRAY INT OF REAL);

% Arrays with integer pair indices and integer values
IntMatrix: TYPE = ARRAY [INT, INT] OF INT;

An array type of the form <math>\mathrm{ARRAY}\ T_1\ \mathrm{OF}\ T_2</math> is interpreted
as the set of all total maps from <math>T_1</math> to <math>T_2</math>.
The main difference with the function type <math>T_1 \to T_2</math> is that arrays,
contrary to functions, are first-class objects of the language, that is, values of an array
type can be arguments or results of functions.
Furthermore, array types come equipped with an update operation.

==== Tuple Types ====

Tuple types are created by the mixfix type constructors

<center>
<math>
\begin{array}{l} [\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ \ ,\ \_\ ] \\[1ex] \ldots \end{array}
</math>
</center>

whose arguments can be instantiated by any value type.

IntArray: TYPE = ARRAY INT OF INT;

% Tuple type declarations

RealPair: TYPE = [REAL, REAL]

MyTuple: TYPE = [ REAL, IntArray, [INT, INT] ];

A tuple type of the form <math>[T_1, \ldots, T_n]</math> is interpreted
as the Cartesian product <math>T_1 \times \cdots \times T_n</math>.

Note that while the types <math>(T_1, \ldots, T_n) \to T</math> and
<math>[T_1 \times \cdots \times T_n] \to T</math> are semantically equivalent,
they are operationally different in CVC4.
The first is the type of functions that take <math>n</math> arguments
of respective type <math>T_1</math>, <math>\ldots</math>, <math>T_n</math>,
while the second is the type of functions that take one argument of an <math>n</math>-tuple type.

==== Record Types ====

Similar to, but more general than tuple types, record types are created by type constructors of the form

<center>
<math>
[\#\ l_1: \_\ ,\ \ldots\ ,\ l_n: \_\ \#]
</math>
</center>

where <math>n > 0</math>, <math>l_1,\ldots, l_n</math> are field labels,
and the arguments can be instantiated with any first-order types.

MyType: TYPE;

% Record declaration

RecordType: TYPE = [# id: REAL, age: INT, info: MyType #];

The order of the fields in a record type is meaningful:
permuting the field names gives a different type.

Note that record types are non-recursive.
For instance, it is not possible to declare a record type called <code>Person</code> containing
a field of type <code>Person</code>.
Recursive types are provided in CVC4 by the more general inductive data types.
(As a matter of fact, both record and tuple types are implemented internally as inductive data types.)

==== Inductive Data Types ====

Inductive data types in CVC4 are similar to inductive data types of functional languages.
They can be parametric or not.

===== Non-Parametric Data Types =====

Non-parametric data types are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1 & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2 & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types, including any <math>A_i</math>.
Such declarations define the data types <math>A_1, \ldots, A_n</math>.
For each data type <math>A_i</math> they introduce:

* constructor symbols <math>cons</math> of type <math>(T_1, \ldots, T_k) \to \mathit{type\_name}_i</math>,
* selector symbols <math>\mathit{sel}_j</math> of type <math>\mathit{type\_name}_i \to T_j</math>, and
* tester symbols <math>\mathit{is\_cons}</math> of type <math>\mathit{type\_name}_i \to \mathrm{BOOLEAN}</math>.

Note that permitting more than one data type to be defined in the same declarations allows
the definition of mutually recursive types.

% simple enumeration type

% implicitly defined are the testers: is_red, is_yellow and is_blue
% (similarly for the other data types)

DATATYPE
PrimaryColor = red | yellow | blue
END;

% infinite set of pairwise distinct values ..., v(-1), v(0), v(1), ...

DATATYPE
Id = v (id: INT)
END;

% ML-style integer lists

DATATYPE
IntList = nil | ins (head: INT, tail: IntList)
END;

% AST for lamba calculus

DATATYPE
Term = var (index: INT)
| apply (arg_1: Term, arg_2: Term)
| lambda (arg: INT, body: Term)
END;

% Trees

DATATYPE
Tree = tree (value: REAL, children: TreeList),
TreeList = nil_tl
| ins_tl (first_t1: Tree, rest_t1: TreeList)
END;

Constructor, selector and tester symbols defined for a data type have global scope.
So, for example, it is not possible for two different data types to use
the same name for a constructor.

An inductive data type is interpreted as a term algebra constructed by the constructor symbols
over some sets of generators.
For example, the type <code>IntList</code> defined above is interpreted as the set
of all terms constructed with <code>nil</code> and <code>ins</code> over the integers.

===== Parametric Data Types =====

Parametric data types are infinite families of (non-parametric) data types
with each family parametrized by one or more type variables.
They are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1[X_{1,1}, \ldots, X_{1,p_1}] & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2[X_{2,1}, \ldots, X_{2,p_2}] & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n[X_{n,1}, \ldots, X_{n,p_n}] & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name parametrized by the type variables <math>X_{i,1}, \ldots, X_{i,p_i}</math>
and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types,
possibly parametrized by <math>X_1, \ldots, X_p</math>, including any <math>A_i</math>.

% Parametric pairs
DATATYPE
Pair[X, Y] = pair (first: X, second: Y)
END;

% Parametric lists

DATATYPE
List[X] = nil | cons (head: X, tail: List[X])
END;

% Parametric trees using the list type above

DATATYPE
Tree[X] = node (value: X, children: List[Tree[X]]),
END;

The declarations above define infinitely many types of the form
Pair[S,T], List[T] and Tree[T] where S and T are first-order types.
Note that the identifier <code>List</code> above, for example, by itself does not denote a type.
In contrast, the terms <code>List[Real]</code>, <code>List[List[Real]]</code>, <code>List[Tree[INT]]</code>,
and so on do.

===== Restriction to Inductive Types =====

By adopting a term algebra semantics, CVC4 allows only ''inductive'' data types,
that is, data types whose values are essentially (labeled, ordered) finite trees.
Infinite structures such as streams or even finite but cyclic ones
such as circular lists are then excluded.
For instance, none of the following declarations define inductive data types,
and are rejected by CVC4:

DATATYPE
IntStream = s (first:INT, rest: IntStream)
END;

DATATYPE
RationalTree = node1 (child: RationalTree)
| node2 (left_child: RationalTree, right_child:RationalTree)
END;

DATATYPE
T1 = c1 (s1: T2),
T2 = c2 (s2: T1)
END;

In concrete, a declaration of <math>n \geq 1</math> datatypes <math>T_1, \ldots, T_n</math> will be rejected if for any one of the types <math>T_1, \ldots, T_n</math>, it is impossible to build a finite term of that type using only the constructors of <math>T_1, \ldots, T_n</math> and free constants of type other than <math>T_1, \ldots, T_n</math>.

Inductive data types are the only types where the user also chooses names for the built-in operations to:

* construct a value of the type (with the constructors),
* extract components from a value (with the selectors), or
* check if a value was constructed with a certain constructor or not (with the testers).

For all the other types, CVC4 provides predefined names for the built-in operations on the type.

=== Function Types ===

Function (<math>\to</math>) types are created by the mixfix type constructors
<center>
<math>
\begin{array}{l}
\_ \to \_ \\[1ex] (\ \_\ ,\ \_\ ) \to \_
\\[1ex] (\ \_\ ,\ \_\ ,\ \_\ ) \to \_
\\[1ex] \ldots
\end{array}
</math>
</center>
whose arguments can be instantiated by any first-order type.

% Function type declarations

UnaryFunType: TYPE = INT -> REAL;

BinaryFunType: TYPE = (REAL, REAL) -> ARRAY REAL OF REAL;

TernaryFunType: TYPE = (REAL, BITVECTOR(4), INT) -> BOOLEAN;

A function type of the form <math>(T_1, \ldots, T_n) \to T</math> with <math>n > 0</math> is interpreted as the set of all ''total'' functions from the Cartesian product <math>T_1 \times \cdots \times T_n</math> to <math>T</math>.

The example above also shows how to introduce type names.
A name like <code>UnaryFunType</code> above is just an abbreviation for the type <math>\mathrm{INT} \to \mathrm{REAL}</math> and can be used interchangeably with it.

In general, any type defined by a type expression <code>E</code> can be given a name with the declaration:

name : TYPE = E;

=== Type Checking ===

In CVC4, formulas and terms are statically typed at the level of types
(as opposed to subtypes) according to the usual rules of first-order many-sorted logic,
with the main difference that formulas are just terms of type <math>BOOLEAN</math>:

* each variable has one associated first-order type,
* each constant symbol has one or more associated first-order types,
* each function symbol has one or more associated function types,
* the type of a term consisting just of a variable is the type associated to that variable,
* the type of a term consisting just of a constant symbol is the type associated to that constant symbol,
* the term obtained by applying a function symbol <math>f</math> to the terms <math>t_1, \ldots, t_n</math> is <math>T</math> if <math>f</math> has type <math>(T_1, \ldots, T_n) \to T</math> and each <math>t_i</math> has type <math>T_i</math>.

Attempting to enter an ill-typed term will result in an error.

Another significant difference with standard many-sorted logic is that
some built-in symbols are parametrically polymorphic.
For instance, the function symbol for extracting the element of any array has
type <math>(\mathit{ARRAY}\ T_1\ \mathit{OF}\ T_2,\; T_1) \to T_2</math>
for all first-order types <math>T_1, T_2</math>.

==== Type Ascription ====

By the type inference rules above some terms might have more than one type.
This can happen with terms built with polymorphic data type constructors
that have more than one return type for the same input type.
In that case, a type ascription operator (<code>::</code>) must be applied
to the constructor to specify the intended return type.

DATATYPE [X]
List[X] = nil | cons (head: X, tail: List[X])
END;

ASSERT y = cons(1, nil::List[REAL]);

DATATYPE [X, Y]
Union[X, Y] = left(val_l: X) | right(val_r: Y)
END;

ASSERT y = left::Union[BOOLEAN, REAL](TRUE);

The constant symbol <math>\mathrm{nil}</math> declared above has infinitely many types
(<math>\mathrm{List}[\mathrm{REAL}]</math>, <math>\mathrm{List}[\mathrm{BOOLEAN}]</math>,
<math>\mathrm{List}[[\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{List}[\mathrm{List}[\mathrm{REAL}]]</math>, ...)
CVC4's type checker requires the user to indicate explicitly the type
of each occurrence of <code>nil</code> in a term.
Similarly,
the injection operator <code>left</code> has infinitely many return types
for the same input type, for instance:
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{REAL}]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, [\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{List}[\mathrm{REAL}]]</math>,
and so on.
Applications of <code>left</code> need to specify the intended returned typed, as shown above.

== Terms and Formulas ==

In addition to type expressions, CVC4 has expressions for terms and for formulas
(i.e., terms of type <math>\mathrm{BOOLEAN}</math>).
By and large, these are standard first-order terms built out of typed variables,
predefined theory-specific operators, free (i.e., user-defined) function symbols,
and quantifiers.
Extensions include an if-then-else operator, lambda abstractions, and local symbol
declarations, as illustrated below.
Note that these extensions still keep CVC4's language first-order.
In particular, lambda abstractions are restricted to take and return only terms of
a first-order type.
Similarly, variables can only be of a first-order type.

A number of built-in function symbols (for instance, the arithmetic ones) are used
as infix operators. All user-defined symbols are used as prefix ones.

User-defined, i.e., free, function symbols include ''constant symbols'' and
''predicate symbols'', respectively nullary function symbols and function symbols
with a <math>\mathrm{BOOLEAN}</math> return type.
These symbols are introduced with global declarations of the form
<math> f_1, \ldots, f_m: T;</math>
where <math>m > 0</math>, <math>f_i</math> are the names of the symbols and
<math>T</math> is their type:

% integer constants

a, b, c: INT;

% real constants

x, y, z: REAL;

% unary function

f1: REAL -> REAL;

% binary function

f2: (REAL, INT) -> REAL;

% unary function with a tuple argument

f3: [INT, REAL] -> BOOLEAN;

% binary predicate

p: (INT, REAL) -> BOOLEAN;

% Propositional "variables"

P, Q; BOOLEAN;

Like type declarations, function symbol declarations like the above have global scope
and must be unique.
In other words, it is not possible to declare a function symbol globally more than once
in the same lexical scope.
This entails among other things that globally-defined free symbols cannot be overloaded
with different types and that theory symbols cannot be redeclared globally as free symbols.

=== Global symbol definitions ===

As with types, a function symbol can be defined as the name of another term
of the corresponding type.
With constant symbols, this is done with a declaration of the form <math>f:T = t;</math> :

c: INT;

i: INT = 5 + 3*c; % i is effectively a shorthand for 5 + 3*c

j: REAL = 3/4;

t: [REAL, INT] = (2/3, -4);

r: [# key: INT, value: REAL #] = (# key := 4, value := (c + 1)/2 #);

f: BOOLEAN = FORALL (x:INT): x <= 0 OR x > c ;

A restriction on constants of type <math>\mathit{BOOLEAN}</math> is that their value
can only be a closed formula, that is, a formula with no free variables.

A term and its name can be used interchangeably in later expressions.
Named terms are often useful for shared subterms (terms used several times in different places)
since their use can make the input exponentially more concise.
Named terms are processed very efficiently by CVC4.
It is much more efficient to associate a complex term with a name directly rather than
to declare a constant and later assert that it is equal to the same term.
This point is explained in more detail later in section [[Commands | Commands]].

More generally, in CVC4 one can associate a term to function symbols of any arity.
For non-constant function symbols this is done with a declaration of the form

<center>
<math>f:(T_1, \ldots, T_n) \to T = \mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t\;;</math>
</center>

where <math>t</math> is any term of type <math>T</math> with free variables
in <math>\{x_1, \ldots, x_n\}</math>.
The lambda binder has the usual semantics and conforms to the usual lexical scoping rules:
within the term <math>t</math> the declaration of the symbols <math>x_1, \ldots, x_n</math>
as local variables of respective type <math>T_1, \ldots, T_n</math> hides any previous
declarations of those symbols that are in scope.

As a general shorthand, when <math>k</math> consecutive types
<math>T_i, \ldots, T_{i+k-1}</math> in the lambda expression
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t</math> are identical, the syntax
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x_i,\ldots, x_{i+k-1}:T_i,\ldots, x:T_n): t</math>
can also be used.

% Global declaration of x as a unary function symbol

x: REAL -> REAL;

% Local declarations of x as variable (hiding the global one)

f: REAL -> REAL = LAMBDA (x: REAL): 2*x + 3;

p: (INT, INT) -> BOOLEAN = LAMBDA (x,i: INT): i*x - 1 > 0;

g: (REAL, INT) -> [REAL, INT] = LAMBDA (x: REAL, i:INT): (x + 1, i - 3);

Note that lambda definitions are not recursive:
the symbol being defined cannot occur in the body of the lambda term.
They should be understood as macros.
For instance, any occurrence of the term <math>f(t)</math>
where <math>f</math> is as defined above will be treated
as if it was the term <math>(2*t + 3)</math>.

=== Local symbol definitions ===

Constant and function symbols can also be declared locally anywhere within a term
by means of a let binder.
This is done with a declaration of the form

<center>
<math>
\mathrm{LET}\ f = s \ \mathrm{IN}\ t ;
</math>
</center>

where <math>t</math> is a term with no free variables, possibly a lambda term.
Let binders can be nested arbitrarily and follow the usual lexical scoping rules.
The following general form
<center>
<math>
\mathrm{LET}\ f_1 = t_1, f_2 = t_2, \ldots, f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>
can used as a shorthand for
<center>
<math>
\mathrm{LET}\ f_1 = t_1\ \mathrm{IN}\
\mathrm{LET}\ f_2 = t_2\ \mathrm{IN}\
\ldots \
\mathrm{LET}\ f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>

t: REAL =
LET x1 = 42,
g = LAMBDA(x:INT): x + 1,
x2 = 2*x1 + 7/2
IN
(LET x3 = g(x1) IN x3 + x2) / x1;

Note that the same symbol = is used, unambiguously, in the syntax of global declarations,
let declarations, and as a predicate symbol.

'''Note:'''
A <math>\mathrm{LET}</math> term with a multiple symbols defines them sequentially.
A parallel version of the <math>\mathrm{LET}</math> construct will be introduced in a later version.

== Built-in theories and their symbols ==

In addition to user-defined symbols, CVC4 terms can use a number of predefined symbols:
the logical symbols, such as <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, etc.,
as well as theory symbols, function symbols belonging to one of the built-in theories.
They are described next, with the theory symbols grouped by theory.

=== Logical Symbols ===

The logical symbols in CVC4's language include
the equality and disequality predicate symbols, respectively written as = and /=,
the multiarity disequality symbol <math>\mathrm{DISTINCT}</math>,
together with the logical constants <math>\mathrm{TRUE}</math>, <math>\mathrm{FALSE}</math>,
the connectives <math>\mathrm{NOT}</math>, <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, <math>\mathrm{XOR}</math>, <math>\Rightarrow</math>, <math>\Leftrightarrow</math>, and
the first-order quantifiers <math>\mathrm{EXISTS}</math> and <math>\mathrm{FORALL}</math>,
all with the standard many-sorted logic semantics.

The binary connectives have infix syntax and type
<math>(\mathrm{BOOLEAN},\mathrm{BOOLEAN}) \to \mathrm{BOOLEAN}</math>.
The symbols = and /=, which are also infix, are instead parametrically polymorphic,
having type <math>(T,T) \to \mathrm{BOOLEAN}</math>
for every first-order type <math>T</math>.
They are interpreted respectively as the identity relation and its complement.

The DISTINCT symbol is both overloaded and polymorphic.
It has type <math>(T,...,T) \to \mathrm{BOOLEAN}</math>
for every sequence <math>(T,...,T)</math> of length <math>n > 0</math>
and first-order type <math>T</math>.
For each <math>n > 0</math>, it is interpreted as the relation
that holds exactly for tuples of pairwise distinct elements.

The syntax for quantifiers is similar to that of the lambda binder.

Here is an example of a formula built just of these logical symbols and variables:

A, B: TYPE;

q: BOOLEAN = FORALL (x,y: A, i,j,k: B):
i = j AND i /= k => EXISTS (z: A): x /= z OR z /= y;

Binding and scoping of quantified variables follows the same rules as
in let expressions.
In particular, a quantifier will shadow in its scope any constant and function symbols
with the same name as one of the variables it quantifies:

A: TYPE;
i, j: INT;

% The first occurrence of i and of j in f are constant symbols,
% the others are variables.

f: BOOLEAN = i = j AND FORALL (i,j: A): i = j OR i /= j;

Optionally, it is also possible to specify instantiation patterns
for quantified variables.
The general syntax for a quantified formula <math>\psi</math> with patterns is

<center>
<math>
Q\;(x_1:T_1, \ldots, x_k:T_k):\; p_1: \ldots\; p_n:\; \varphi
</math>
</center>

where <math>n \geq 0</math>, <math>Q</math> is
either <math>\mathrm{FORALL}</math> or <math>\mathrm{EXISTS}</math>,
<math>\varphi</math> is a term of type <math>\mathrm{BOOLEAN}</math>,
and each of the <math>p_i</math>'s,
a pattern for the quantifier <math>Q\;(x_1:T_1, \ldots, x_k:T_k)</math>, has the form

<center>
<math>
\mathrm{PATTERN}\; (t_1, \ldots, t_m)
</math>
</center>

where <math>m > 0</math> and <math>t_1, \ldots, t_m</math> are
arbitrary binder-free terms (no lets, no quantifiers).
Those terms can contain (free) variables, typically, but not exclusively,
drawn from <math>x_1, \ldots, x_k</math>.
(Additional variables can occur if <math>\psi</math> occurs in a bigger formula
binding those variables.)

A: TYPE;
b, c: A;
p, q: A -> BOOLEAN;
r: (A, A) -> BOOLEAN;

ASSERT FORALL (x0, x1, x2: A):
PATTERN (r(x0, x1), r(x1, x2)):
(r(x0, x1) AND r(x1, x2)) => r(x0, x2) ;

ASSERT FORALL (x: A):
PATTERN (r(x, b)):
PATTERN (r(x, c)):
p(x) => q(x) ;

ASSERT EXISTS (y: A):
FORALL (x: A):
PATTERN (r(x, y), p(y)):
r(x, y) => q(x) ;

Patterns have no logical meaning:
adding them to a formula does not change its semantics.
Their purpose is purely operational, as explained in
the [[#Instantiation Patterns | Instantiation Patterns]] section.

In addition to these constructs, CVC4 also has a general mixfix conditional operator
of the form

<center>
<math>
\mathrm{IF}\ b\ \mathrm{THEN}\ t\ \mathrm{ELSIF}\ b_1\ \mathrm{THEN}\ t_1\ \ldots\ \mathrm{ELSIF}\ b_n\ \mathrm{THEN}\ t_n\ \mathrm{ELSE}\ t_{n+1}\ \mathrm{ENDIF}
</math>
</center>

with <math>n \geq 0</math> where
<math>b, b_1, \ldots, b_n</math> are terms of type <math>\mathrm{BOOLEAN}</math> and
<math>t, t_1, \ldots, t_n, t_{n+1}</math> are terms of the same first-order type <math>T</math>:

% Conditional term
x, y, z, w: REAL;

t: REAL =
IF x > 0 THEN y
ELSIF x >= 1 THEN z
ELSIF x > 2 THEN w
ELSE 2/3 ENDIF;

=== User-defined Functions and Types ===

The theory of user-defined functions,also know in the SMT literature as
the theory ''Equality over Uninterpreted Functions'', or ''EUF'', is in effect
a family of theories of equality parametrized by the basic types and the free symbols
a user can define during a run of CVC4.

This theory has no built-in symbols (other than the logical ones).
Its types consist of ''all and only'' the user-defined types.
Its function symbols consist of ''all and only'' the user-defined free symbols.

=== Arithmetic ===

The real arithmetic theory has two types:
<math>\mathrm{REAL}</math> and <math>\mathrm{INTEGER}</math>
with the latter a subtype of the first.
Its built-in symbols for the usual arithmetic constants
and operators over the type <math>\mathrm{REAL}</math>, each with the expected type:
all numerals 0, 1, ..., as well as - (both unary and binary), +, *, /, <, >, <=, >=.
Application of the binary symbols are in infix form.
Note that + is only binary, and so an expression such as +4 is ill-formed.

Rational values can be expressed in decimal or fractional format,
e.g., 0.1, 23.243241, 1/2, 3/4, and so on.
A leading 0 is mandatory for decimal numbers smaller than one
(e.g., the syntax .3 cannot be used as a shorthand for 0.3).
However, a trailing 0 is ''not'' required for decimals that are whole numbers
(e.g., 3. is allowed as a shorthand for 3.0).
The size of the numerals used in the representation of natural and rational numbers
is unbounded; more accurately, bounded only by the amount of available memory.

=== Bit vectors ===

=== Arrays ===

The theory of arrays is a parametric theory of (total) unary maps.
It comes equipped with mixfix polymorphic selection and update operators, respectively
<center>
<math>\_[\_]</math> and <math>\_\ \mathrm{WITH}\ [\_]\ := \_</math> .
</center>
The semantics of these operators is the expected one:
for all first-order types <math>T_1</math> and <math>T_2</math>,
if <math>a</math> is of type <math>\mathrm{ARRAY}\ T_1 \mathrm{OF}\ T_2</math>,
<math>i</math> is of type <math>T_1</math>, and
<math>v</math> is of type <math>T_2</math>,
* <math>a[i]</math> denotes the value that <math>a</math> associates to index <math>i</math>,
* <math>a\ \mathrm{WITH}\ [i]\ := v</math> denotes a map that associates <math>v</math> to index <math>i</math> and is otherwise identical to <math>a</math>.
Sequential updates can be chained with the shorthand syntax
<math>\_\ \mathrm{WITH}\ [\_]\ := \_, \ldots, [\_]\ := \_</math>.

A: TYPE = ARRAY INT OF REAL;
a: A;
i: INT = 4;

% selection:

elem: REAL = a[i];

% update

a1: A = a WITH [10] := 1/2;

% sequential update
% (syntactic sugar for (a WITH [10] := 2/3) WITH [42] := 3/2)

a2: A = a WITH [10] := 2/3, [42] := 3/2;

Since arrays are just maps, equality between them is extensional, that is,
for two arrays of the same type to be different they have to map at least one
index to differ values.

=== Data types ===

The theory of inductive data types is in fact a family of theories parametrized
by a data type declaration specifying constructors and selectors
for one or more user-defined data types.

No built-in operators other than equality and disequality are provided
for this family in the native language.
Each user-provided data type declaration, however, generates constructor, selector and tester operators
as described in the [[#Inductive Data Types | Inductive Data Types]] section.

=== Tuples and Records ===

Semantically both records and tuples can be seen as special instances
of inductive data types.
CVC4 implements them internally indeed as data types.
In essence, a record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math>
is encoded as a data type of the form

<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\ \ \mathrm{Record} = \mathit{rec}(l_0:T_0, \ldots, l_n:T_n) \\
\mathrm{END};
\end{array}
</math>
</center>

Tuples of length <math>n</math> are in turn special cases of records whose field names are
the numerals from <math>0</math> to <math>n-1</math>.

Externally, tuples and records have their own syntax for constructor and selector operators.
* Records of type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> have the associated record constructor <math>(\#\ l_0 := \_,\; \ldots,\; l_n := \_\ \#)</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.
* Tuples of type <math>[\ T_0, \ldots, T_n\ ]</math> have the associated tuple constructor <math>(\ \_,\; \ldots,\; \_\ )</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.

The selector operators on records and tuples follows a dot notation syntax.

% Record construction and field selection
Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);
k: INT = x.key;
v: REAL = x.weight;

% Tuple construction and projection
y: [REAL, INT, REAL] = ( 4/5, 9, 11/9 );
first_elem: REAL = y.0;
third_elem: REAL = y.2;

Differently from data types, records and tuples are also provided with built-in update operators similar in syntax and semantics to the update operator for arrays.
More precisely, for each record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .l_i\ := \_
</math>
</center>

The operator maps a record <math>r</math> of that type and a value <math>v</math>
of type <math>T_i</math> to the record that stores <math>v</math> in field <math>l_i</math>
and is otherwise identical to <math>r</math>.
Analogously, for each tuple type <math>[T_0, \ldots, T_n]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .i\ := \_
</math>
</center>

with similar semantics.

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = x WITH .weight := 48;

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = y WITH .1 := 3;

Updates to a nested component can be combined in a single WITH operator:

Cache: TYPE = ARRAY [0..100] OF [# addr: INT, data: REAL #];
State: TYPE = [# pc: INT, cache: Cache #];

s0: State;
s1: State = s0 WITH .cache[10].data := 2/3;

Note that, differently from updates on arrays, tuple and record updates are
just additional syntactic sugar.
For instance, the record <code>x1</code> and tuple <code>y1</code> defined above
could have been equivalently defined as follows:

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = (# key := x.key, weight := 48 #);

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = ( y.0, 3, y.1 );

== Commands ==

In addition to declarations of types and function symbols,
the CVC4 native language contains the following commands:

* <math>\mathrm{ASSERT}\ F</math> -- Add the formula <math>F</math> to the current logical context <math>\Gamma</math>.
* [[#CHECKSAT|<math>\mathrm{CHECKSAT}\ F</math>]] -- Check if the formula <math>F</math> is satisfiable in the current logical context (<math>\Gamma \not\models_T \mathrm{NOT}\ F</math>).
* <math>\mathrm{CONTINUE}</math> -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, search for a counter-example different from the current one.
* [[#COUNTEREXAMPLE|<math>\mathrm{COUNTEREXAMPLE}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print the context that is a witness for invalidity/satisfiability.
* [[#COUNTERMODEL|<math>\mathrm{COUNTERMODEL}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print a model that makes the formula invalid/satisfiable. The model is provided in terms of concrete values for each free symbol.
* <math>\mathrm{OPTION}\ o\ v</math> -- Set the command-line option flag <math>o</math> to value <math>v</math>. The argument <math>o</math> is provide as a string literal enclosed in double-quotes and <math>v</math> as an integer value.
* <math>\mathrm{POP}</math> -- Equivalent to <math>\mathrm{POPTO}\ 1</math>
* [[#POPTO|<math>\mathrm{POPTO}\ n</math>]] -- Restore the system to the state it was in right before the most recent call to <math>\mathrm{PUSH}</math> made from stack level <math>n</math>. Note that the current stack level is printed as part of the output of the <math>\mathrm{WHERE}</math> command.
* <math>\mathrm{PUSH}</math> -- Save (checkpoint) the current state of the system.
* [[#QUERY|<math>\mathrm{QUERY}\ F</math>]] -- Check if the formula <math>F</math> is valid in the current logical context (<math>\Gamma\models_T F</math>).
* [[#RESTART|<math>\mathrm{RESTART}\ F</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, repeat the check but with the additional assumption <math>F</math> in the context.
* <math>\mathrm{PRINT}\ t</math> -- Parse and print back the term <math>t</math>.
* <math>\mathrm{TRANSFORM}\ t</math> -- Simplify the term <math>t</math> and print the result.
* <math>\mathrm{WHERE}</math> -- Print all the formulas in the current logical context <math>\Gamma</math>.

The remaining commands take a single argument, given as a string literal enclosed in double-quotes.

* <math>\mathrm{ECHO}\ s</math> -- Print string <math>s</math>
* <math>\mathrm{INCLUDE}\ f</math> -- Read commands from file <math>f</math>.
* <math>\mathrm{TRACE}\ f</math> -- Turn on tracing for the debug flag <math>f</math>.
* <math>\mathrm{UNTRACE}\ f</math> -- Turn off tracing for the debug flag <math>f</math>.

Here, we explain some of the above commands in more detail.

=== QUERY ===

The command <math>\mathrm{QUERY}\ F</math> invokes the core functionality of CVC4 to check
the validity of the formula <math>F</math> with respect to the assertions made thus far,
which constitute the context <math>\Gamma</math>.
The argument <math>F</math> must be well typed term of type <math>\mathrm{BOOLEAN}</math>,
as described in [[#Terms and Formulas | Terms and Formulas]].

The execution of this command always terminates and produces one of three possible answers:
<code>valid</code>, <code>invalid</code>, and <code>unknown</code>.

* A <code>valid</code> answer indicates that <math>\Gamma \models_T F</math>. After a query returning such an answer, the logical context <math>\Gamma</math> is exactly as it was before the query.
* An <code>invalid</code> answer indicates that <math>\Gamma \not\models_T F</math>, that is, there is a model of the background theory <math>T</math> that satisfies <math>\Gamma \cup \{\mathrm{NOT}\ F\}</math>. When <math>\mathrm{QUERY}\ F</math> returns <code>invalid</code>, the logical context <math>\Gamma</math> is augmented with a set <math>\Delta</math> of ground (i.e., variable-free) literals such that <math>\Gamma\cup\Delta</math> is satisfiable in <math>T</math>, but <math>\Gamma\cup\Delta\models_T \mathrm{NOT}\ F</math>. In fact, in this case <math>\Delta</math> ''propositionally entails'' <math>\mathrm{NOT}\ F</math>, in the sense that, every truth assignment to the literals of <math>\Delta</math> that satisfies <math>\Delta</math> falsifies <math>F</math>. We call the new context <math>\Gamma\cup\Delta</math> a ''counterexample'' for <math>F</math>.
* An <code>unknown</code> answer is similar to an <code>invalid</code> answer in that additional literals are added to the context which propositionally entail <math>\mathrm{NOT}\ F</math>. The difference in this case is that CVC4 cannot guarantee that <math>\Gamma\cup\Delta</math> is actually satisfiable in <math>T</math>.

CVC4 may report <code>unknown</code> when the context or the query contains
non-linear arithmetic terms or quantifiers.
In all other cases, it is expected to be sound and complete,
i.e., to report <code>Valid</code> if <math>\Gamma \models_T F</math>
and <code>Invalid</code> otherwise.

After an <code>invalid</code> (resp. <code>unknown</code>) answer,
counterexamples (resp. possible counterexamples) can be obtained with
a <math>\mathrm{WHERE}</math>, <math>\mathrm{COUNTEREXAMPLE}</math>,
or <math>\mathrm{COUNTERMODEL}</math> command.


Since the <math>\mathrm{QUERY}</math> command may modify
the current context, if one needs to check several formulas in a row
in the same context, it is a good idea to surround every
query by a <math>\mathrm{PUSH}</math> and <math>\mathrm{POP}</math> invocation
in order to preserve the context:

PUSH;
QUERY <formula>;
POP;

=== CHECKSAT ===

The command <math>\mathrm{CHECKSAT}\ F</math> behaves identically
to <math>\mathrm{QUERY}\ \mathrm{NOT}\ F</math>.

=== RESTART ===

The command <math>\mathrm{RESTART}\ F</math> can only be invoked after an invalid query.
For example, in an interactive setting:

QUERY <formula>;

CVC4> invalid

RESTART <formula2>;

Functionally, the behavior of the above command sequence is identical to the following:

PUSH;
QUERY <formula>;
POP;
ASSERT <formula2>;
QUERY <formula>;

The advantage of using the <math>\mathrm{RESTART}</math> command is that
the first command sequence may be executed much more efficiently that the second.
The reason is that with <math>\mathrm{RESTART}</math> CVC4 will re-use
what it has learned while answering the previous query rather than starting
over from scratch.

=== COUNTERMODEL ===

[More]

=== COUNTEREXAMPLE ===

[More]

=== POPTO ===

[More]

== Instantiation Patterns ==

CVC4 processes each universally quantified formula in the current context
by adding instances of the formula obtained by replacing its universal variables
with ground terms.
Patterns restrict the choice of ground terms for the quantified variables,
with the goal of controlling the potential explosion of ground instances.
In essence, adding patterns to a formula is a way for the user to tell CVC4
to focus only on certain instances which, in the user's opinion, will be
most helpful during a proof.

In more detail, patterns have the following effect on formulas that are found
in the logical context or get added to it later while CVC4 is trying to prove
the validity of some formula <math>F</math>.

If a formula in the current context starts with an existential quantifier,
CVC4 ''Skolemizes'' it, that is, replaces it in the context with the formula
obtained by substituting the existentially quantified variables
by fresh constants and dropping the quantifier.
Any patterns for the existential quantifier are simply ignored.

If a formula starts with a universal quantifier
<math>\mathrm{FORALL}\; (x_1:T_1, \ldots, x_n:T_n)</math>,
CVC4 adds to the context a number of instances of the formula,
with the goal of using them to prove the query <math>F</math> valid.
An instance is obtained by replacing each <math>x_i</math> with a ground term
of the same type occurring in one of the formulas in the context,
and dropping the universal quantifier.
If <math>x_i</math> occurs in a pattern
<math>\mathrm{PATTERN}\; (t_1, \ldots, t_m)</math> for the quantifier,
it will be instantiated only with terms obtained by simultaneously matching
all the terms in the pattern against ground terms in the current context
<math>\Gamma</math>.

Specifically, the matching process produces one or more substitutions
<math>\sigma</math> for the variables in <math>(t_1, \ldots, t_m)</math>
which satisfy the following invariant:
for each <math>i = 1, \ldots, m</math>, <math>\sigma(t_i)</math> is
a ground term and there is a ground term <math>s_i</math> in <math>\Gamma</math>
such that <math>\Gamma \models_T \sigma(t_i) = s_i</math>.
The variables of <math>(x_1:T_1, \ldots, x_n:T_n)</math> that occur
in the pattern are instantiated only with those substitutions
(while any remaining variables are instantiated arbitrarily).

The Skolemized version or the added instances of a context formula may themselves
start with a quantifier.
The same instantiation process is applied to them too, recursively.

Note that the matching mechanism is not limited to syntactic matching
but is modulo the equations asserted in the context.
Because of decidability and/or efficiency limitations, the matching process
is not exhaustive.
CVC4 will typically miss some substitutions that satisfy the invariant above.
As a consequence, it might fail to prove the validity of the query formula
<math>F</math>, which makes CVC4 incomplete for contexts containing
quantified formulas.
It should be noted though that exhaustive matching, which can be achieved
simply by not specifying any patterns, does not yield completeness anyway
since the instantiation of universal variables is still restricted
to just the ground terms in the context,
whereas in general additional ground terms might be needed.

CVC4's native language

2012-12-03T21:21:02Z

Tinelli: /* The BOOLEAN Type */

= CVC4 native input language =

The native input language consists of a sequence of symbol declarations and commands, each followed by a semicolon (<code>;</code>).

Any text after the first occurrence of a percent character and to the end of the current line is a comment:

%%% This is a native language comment

== Type System ==

CVC4's type system includes a set of built-in types which can be expanded with additional user-defined types.

The type system consists of ''first-order'' types, ''subtypes'' of first-order types, and ''higher-order'' types, all of which are interpreted as sets.
For convenience, we will sometimes identify below the interpretation of a type with the type itself.

First-order types consist of basic types and structured types. The basic types are <math>\mathrm{BOOLEAN}</math>, <math>\mathrm{REAL}</math>, <math>\mathrm{BITVECTOR}(n)</math> for all <math>n > 0</math>, as well as user-defined basic types (also called uninterpreted types).
The structured types are array, tuple, record types, and ML-style user-defined (inductive) datatypes.

'''Note:''' Currently, subtypes consist only of the built-in subtype <math>\mathrm{INT}</math> of <math>\mathrm{REAL}</math>.

Support for CVC3-style user-defined subtypes will be added in a later release.

Function types are the only higher-order types.
More precisely, they are just second-order types
since function symbols in CVC4, both built-in and user-defined, can take as argument or return only values of
a first-order type.

=== Basic Types ===

==== The BOOLEAN Type ====

The <math>\mathrm{BOOLEAN}</math> type is interpreted as the two-element set of Boolean values
<math>\{\mathrm{TRUE},\; \mathrm{FALSE}\}</math>.

'''Note:''' CVC4's treatment of this type differs from CVC3's where <math>\mathrm{BOOLEAN}</math> is used only as the type of formulas, but not as value type. CVC3 follows the two-tiered structure of classical first-order logic
which distinguishes between formulas and terms, and allows terms to occur in formulas but not vice versa (with the exception of the IF-THEN-ELSE construct).
CVC4 drops the distinction between terms and formulas and defines the latter just as terms of type <math>\mathrm{BOOLEAN}</math>. As such, formulas can occur as subterms of possibly non-Boolean terms.

Example:

% Boolean constants
a, b: BOOLEAN;

% REAL constants
x,y: REAL

% Boolean-valued function, can be used as a predicate symbol
p: REAL -> BOOLEAN;
ASSERT a => p(x - y)

% Real-valued function with Boolean argument
f: BOOLEAN -> REAL;

% The argument of f can be a formula ...
ASSERT f(a OR b) > 0.3 OR p(x);

% ... even a quantified one
ASSERT f(FORALL (r: REAL): r < r + 1);

==== The REAL Type ====

The <math>\mathrm{REAL}</math> type is interpreted as the set of real numbers.

Note that these are the (infinite precision) mathematical reals,
not the floating point numbers.
Support for floating point types is planned for future versions.

x, y : REAL;
QUERY (( x <= y ) AND ( y <= x )) => ( x = y );

==== The INT Type ====

The <math>\mathrm{INT}</math> type is interpreted as the set of integer numbers
and is considered a subtype of <math>\mathrm{REAL}</math>.
The latter means in particular that it is possible to mix integer and real terms
in expressions without the need of an explicit ''upcasting'' operator.

Note that these are the (infinite precision) mathematical integers,
not the finite precision machine integers used in most programming languages.
The latter are modeled by [[ #Bitvectors | bit vector ]] types.

x, y : INT;
QUERY ((2 * x + 4 * y <= 1) AND ( y >= x)) => (x <= 0);
z : REAL;
QUERY (2 * x + z <= 3.5) AND (z >= 1);

==== Bit Vector Types ====

For every positive integer <math>n</math>, the type <math>\mathrm{BITVECTOR}(n)</math> is interpreted as the set of all bit vectors of size <math>n</math>.
A rich set of bit vector operators is supported.

==== User-defined Basic Types ====

Users can define new basic types
(often referred to as ''uninterpreted'' types in the SMT literature).
Each such type is interpreted as a set of unspecified cardinality
but disjoint from any other type.

User-defined basic types are created by declarations like the following:

% User declarations of basic types:

MyBrandNewType: TYPE;

Apples, Oranges: TYPE;

=== Structured Types ===

CVC4's structured types are divided into the following families.

==== Array Types ====

Array types are created by the mixfix type constructors <math>\mathrm{ARRAY}\ \_\ \mathrm{OF}\ \_</math>
whose arguments can be instantiated by any value type.

I : TYPE;

%% Array types:

% Arrays with indices from I and values from REAL
Array1: TYPE = ARRAY I OF REAL;

% Arrays with integer indices and array values
Array2: TYPE = ARRAY INT OF (ARRAY INT OF REAL);

% Arrays with integer pair indices and integer values
IntMatrix: TYPE = ARRAY [INT, INT] OF INT;

An array type of the form <math>\mathrm{ARRAY}\ T_1\ \mathrm{OF}\ T_2</math> is interpreted
as the set of all total maps from <math>T_1</math> to <math>T_2</math>.
The main difference with the function type <math>T_1 \to T_2</math> is that arrays,
contrary to functions, are first-class objects of the language, that is, values of an array
type can be arguments or results of functions.
Furthermore, array types come equipped with an update operation.

==== Tuple Types ====

Tuple types are created by the mixfix type constructors

<center>
<math>
\begin{array}{l} [\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ \ ,\ \_\ ] \\[1ex] \ldots \end{array}
</math>
</center>

whose arguments can be instantiated by any value type.

IntArray: TYPE = ARRAY INT OF INT;

% Tuple type declarations

RealPair: TYPE = [REAL, REAL]

MyTuple: TYPE = [ REAL, IntArray, [INT, INT] ];

A tuple type of the form <math>[T_1, \ldots, T_n]</math> is interpreted
as the Cartesian product <math>T_1 \times \cdots \times T_n</math>.

Note that while the types <math>(T_1, \ldots, T_n) \to T</math> and
<math>[T_1 \times \cdots \times T_n] \to T</math> are semantically equivalent,
they are operationally different in CVC4.
The first is the type of functions that take <math>n</math> arguments
of respective type <math>T_1</math>, <math>\ldots</math>, <math>T_n</math>,
while the second is the type of functions that take one argument of an <math>n</math>-tuple type.

==== Record Types ====

Similar to, but more general than tuple types, record types are created by type constructors of the form

<center>
<math>
[\#\ l_1: \_\ ,\ \ldots\ ,\ l_n: \_\ \#]
</math>
</center>

where <math>n > 0</math>, <math>l_1,\ldots, l_n</math> are field labels,
and the arguments can be instantiated with any first-order types.

MyType: TYPE;

% Record declaration

RecordType: TYPE = [# id: REAL, age: INT, info: MyType #];

The order of the fields in a record type is meaningful:
permuting the field names gives a different type.

Note that record types are non-recursive.
For instance, it is not possible to declare a record type called <code>Person</code> containing
a field of type <code>Person</code>.
Recursive types are provided in CVC4 by the more general inductive data types.
(As a matter of fact, both record and tuple types are implemented internally as inductive data types.)

==== Inductive Data Types ====

Inductive data types in CVC4 are similar to inductive data types of functional languages.
They can be parametric or not.

===== Non-Parametric Data Types =====

Non-parametric data types are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1 & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2 & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types, including any <math>A_i</math>.
Such declarations define the data types <math>A_1, \ldots, A_n</math>.
For each data type <math>A_i</math> they introduce:

* constructor symbols <math>cons</math> of type <math>(T_1, \ldots, T_k) \to \mathit{type\_name}_i</math>,
* selector symbols <math>\mathit{sel}_j</math> of type <math>\mathit{type\_name}_i \to T_j</math>, and
* tester symbols <math>\mathit{is\_cons}</math> of type <math>\mathit{type\_name}_i \to \mathrm{BOOLEAN}</math>.

Note that permitting more than one data type to be defined in the same declarations allows
the definition of mutually recursive types.

% simple enumeration type

% implicitly defined are the testers: is_red, is_yellow and is_blue
% (similarly for the other data types)

DATATYPE
PrimaryColor = red | yellow | blue
END;

% infinite set of pairwise distinct values ..., v(-1), v(0), v(1), ...

DATATYPE
Id = v (id: INT)
END;

% ML-style integer lists

DATATYPE
IntList = nil | ins (head: INT, tail: IntList)
END;

% AST for lamba calculus

DATATYPE
Term = var (index: INT)
| apply (arg_1: Term, arg_2: Term)
| lambda (arg: INT, body: Term)
END;

% Trees

DATATYPE
Tree = tree (value: REAL, children: TreeList),
TreeList = nil_tl
| ins_tl (first_t1: Tree, rest_t1: TreeList)
END;

Constructor, selector and tester symbols defined for a data type have global scope.
So, for example, it is not possible for two different data types to use
the same name for a constructor.

An inductive data type is interpreted as a term algebra constructed by the constructor symbols
over some sets of generators.
For example, the type <code>IntList</code> defined above is interpreted as the set
of all terms constructed with <code>nil</code> and <code>ins</code> over the integers.

===== Parametric Data Types =====

Parametric data types are infinite families of (non-parametric) data types
with each family parametrized by one or more type variables.
They are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1[X_{1,1}, \ldots, X_{1,p_1}] & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2[X_{2,1}, \ldots, X_{2,p_2}] & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n[X_{n,1}, \ldots, X_{n,p_n}] & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name parametrized by the type variables <math>X_{i,1}, \ldots, X_{i,p_i}</math>
and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types,
possibly parametrized by <math>X_1, \ldots, X_p</math>, including any <math>A_i</math>.

% Parametric pairs
DATATYPE
Pair[X, Y] = pair (first: X, second: Y)
END;

% Parametric lists

DATATYPE
List[X] = nil | cons (head: X, tail: List[X])
END;

% Parametric trees using the list type above

DATATYPE
Tree[X] = node (value: X, children: List[Tree[X]]),
END;

The declarations above define infinitely many types of the form
Pair[S,T], List[T] and Tree[T] where S and T are first-order types.
Note that the identifier <code>List</code> above, for example, by itself does not denote a type.
In contrast, the terms <code>List[Real]</code>, <code>List[List[Real]]</code>, <code>List[Tree[INT]]</code>,
and so on do.

===== Restriction to Inductive Types =====

By adopting a term algebra semantics, CVC4 allows only ''inductive'' data types,
that is, data types whose values are essentially (labeled, ordered) finite trees.
Infinite structures such as streams or even finite but cyclic ones
such as circular lists are then excluded.
For instance, none of the following declarations define inductive data types,
and are rejected by CVC4:

DATATYPE
IntStream = s (first:INT, rest: IntStream)
END;

DATATYPE
RationalTree = node1 (child: RationalTree)
| node2 (left_child: RationalTree, right_child:RationalTree)
END;

DATATYPE
T1 = c1 (s1: T2),
T2 = c2 (s2: T1)
END;

In concrete, a declaration of <math>n \geq 1</math> datatypes <math>T_1, \ldots, T_n</math> will be rejected if for any one of the types <math>T_1, \ldots, T_n</math>, it is impossible to build a finite term of that type using only the constructors of <math>T_1, \ldots, T_n</math> and free constants of type other than <math>T_1, \ldots, T_n</math>.

Inductive data types are the only types where the user also chooses names for the built-in operations to:

* construct a value of the type (with the constructors),
* extract components from a value (with the selectors), or
* check if a value was constructed with a certain constructor or not (with the testers).

For all the other types, CVC4 provides predefined names for the built-in operations on the type.

=== Function Types ===

Function (<math>\to</math>) types are created by the mixfix type constructors
<center>
<math>
\begin{array}{l}
\_ \to \_ \\[1ex] (\ \_\ ,\ \_\ ) \to \_
\\[1ex] (\ \_\ ,\ \_\ ,\ \_\ ) \to \_
\\[1ex] \ldots
\end{array}
</math>
</center>
whose arguments can be instantiated by any first-order type.

% Function type declarations

UnaryFunType: TYPE = INT -> REAL;

BinaryFunType: TYPE = (REAL, REAL) -> ARRAY REAL OF REAL;

TernaryFunType: TYPE = (REAL, BITVECTOR(4), INT) -> BOOLEAN;

A function type of the form <math>(T_1, \ldots, T_n) \to T</math> with <math>n > 0</math> is interpreted as the set of all ''total'' functions from the Cartesian product <math>T_1 \times \cdots \times T_n</math> to <math>T</math>.

The example above also shows how to introduce type names.
A name like <code>UnaryFunType</code> above is just an abbreviation for the type <math>\mathrm{INT} \to \mathrm{REAL}</math> and can be used interchangeably with it.

In general, any type defined by a type expression <code>E</code> can be given a name with the declaration:

name : TYPE = E;

=== Type Checking ===

In CVC4, formulas and terms are statically typed at the level of types
(as opposed to subtypes) according to the usual rules of first-order many-sorted logic,
with the main difference that formulas are just terms of type <math>BOOLEAN</math>:

* each variable has one associated first-order type,
* each constant symbol has one or more associated first-order types,
* each function symbol has one or more associated function types,
* the type of a term consisting just of a variable is the type associated to that variable,
* the type of a term consisting just of a constant symbol is the type associated to that constant symbol,
* the term obtained by applying a function symbol <math>f</math> to the terms <math>t_1, \ldots, t_n</math> is <math>T</math> if <math>f</math> has type <math>(T_1, \ldots, T_n) \to T</math> and each <math>t_i</math> has type <math>T_i</math>.

Attempting to enter an ill-typed term will result in an error.

Another significant difference with standard many-sorted logic is that
some built-in symbols are parametrically polymorphic.
For instance, the function symbol for extracting the element of any array has
type <math>(\mathit{ARRAY}\ T_1\ \mathit{OF}\ T_2,\; T_1) \to T_2</math>
for all first-order types <math>T_1, T_2</math>.

==== Type Ascription ====

By the type inference rules above some terms might have more than one type.
This can happen with terms built with polymorphic data type constructors
that have more than one return type for the same input type.
In that case, a type ascription operator (<code>::</code>) must be applied
to the constructor to specify the intended return type.

DATATYPE [X]
List[X] = nil | cons (head: X, tail: List[X])
END;

ASSERT y = cons(1, nil::List[REAL]);

DATATYPE [X, Y]
Union[X, Y] = left(val_l: X) | right(val_r: Y)
END;

ASSERT y = left::Union[BOOLEAN, REAL](TRUE);

The constant symbol <math>\mathrm{nil}</math> declared above has infinitely many types
(<math>\mathrm{List}[\mathrm{REAL}]</math>, <math>\mathrm{List}[\mathrm{BOOLEAN}]</math>,
<math>\mathrm{List}[[\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{List}[\mathrm{List}[\mathrm{REAL}]]</math>, ...)
CVC4's type checker requires the user to indicate explicitly the type
of each occurrence of <code>nil</code> in a term.
Similarly,
the injection operator <code>left</code> has infinitely many return types
for the same input type, for instance:
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{REAL}]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, [\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{List}[\mathrm{REAL}]]</math>,
and so on.
Applications of <code>left</code> need to specify the intended returned typed, as shown above.

== Terms and Formulas ==

In addition to type expressions, CVC4 has expressions for terms and for formulas
(i.e., terms of type <math>\mathrm{BOOLEAN}</math>).
By and large, these are standard first-order terms built out of typed variables,
predefined theory-specific operators, free (i.e., user-defined) function symbols,
and quantifiers.
Extensions include an if-then-else operator, lambda abstractions, and local symbol
declarations, as illustrated below.
Note that these extensions still keep CVC4's language first-order.
In particular, lambda abstractions are restricted to take and return only terms of
a first-order type.
Similarly, variables can only be of a first-order type.

A number of built-in function symbols (for instance, the arithmetic ones) are used
as infix operators. All user-defined symbols are used as prefix ones.

User-defined, i.e., free, function symbols include ''constant symbols'' and
''predicate symbols'', respectively nullary function symbols and function symbols
with a <math>\mathrm{BOOLEAN}</math> return type.
These symbols are introduced with global declarations of the form
<math> f_1, \ldots, f_m: T;</math>
where <math>m > 0</math>, <math>f_i</math> are the names of the symbols and
<math>T</math> is their type:

% integer constants

a, b, c: INT;

% real constants

x, y, z: REAL;

% unary function

f1: REAL -> REAL;

% binary function

f2: (REAL, INT) -> REAL;

% unary function with a tuple argument

f3: [INT, REAL] -> BOOLEAN;

% binary predicate

p: (INT, REAL) -> BOOLEAN;

% Propositional "variables"

P, Q; BOOLEAN;

Like type declarations, function symbol declarations like the above have global scope
and must be unique.
In other words, it is not possible to declare a function symbol globally more than once
in the same lexical scope.
This entails among other things that globally-defined free symbols cannot be overloaded
with different types and that theory symbols cannot be redeclared globally as free symbols.

=== Global symbol definitions ===

As with types, a function symbol can be defined as the name of another term
of the corresponding type.
With constant symbols, this is done with a declaration of the form <math>f:T = t;</math> :

c: INT;

i: INT = 5 + 3*c; % i is effectively a shorthand for 5 + 3*c

j: REAL = 3/4;

t: [REAL, INT] = (2/3, -4);

r: [# key: INT, value: REAL #] = (# key := 4, value := (c + 1)/2 #);

f: BOOLEAN = FORALL (x:INT): x <= 0 OR x > c ;

A restriction on constants of type <math>\mathit{BOOLEAN}</math> is that their value
can only be a closed formula, that is, a formula with no free variables.

A term and its name can be used interchangeably in later expressions.
Named terms are often useful for shared subterms (terms used several times in different places)
since their use can make the input exponentially more concise.
Named terms are processed very efficiently by CVC4.
It is much more efficient to associate a complex term with a name directly rather than
to declare a constant and later assert that it is equal to the same term.
This point is explained in more detail later in section [[Commands | Commands]].

More generally, in CVC4 one can associate a term to function symbols of any arity.
For non-constant function symbols this is done with a declaration of the form

<center>
<math>f:(T_1, \ldots, T_n) \to T = \mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t\;;</math>
</center>

where <math>t</math> is any term of type <math>T</math> with free variables
in <math>\{x_1, \ldots, x_n\}</math>.
The lambda binder has the usual semantics and conforms to the usual lexical scoping rules:
within the term <math>t</math> the declaration of the symbols <math>x_1, \ldots, x_n</math>
as local variables of respective type <math>T_1, \ldots, T_n</math> hides any previous
declarations of those symbols that are in scope.

As a general shorthand, when <math>k</math> consecutive types
<math>T_i, \ldots, T_{i+k-1}</math> in the lambda expression
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t</math> are identical, the syntax
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x_i,\ldots, x_{i+k-1}:T_i,\ldots, x:T_n): t</math>
can also be used.

% Global declaration of x as a unary function symbol

x: REAL -> REAL;

% Local declarations of x as variable (hiding the global one)

f: REAL -> REAL = LAMBDA (x: REAL): 2*x + 3;

p: (INT, INT) -> BOOLEAN = LAMBDA (x,i: INT): i*x - 1 > 0;

g: (REAL, INT) -> [REAL, INT] = LAMBDA (x: REAL, i:INT): (x + 1, i - 3);

Note that lambda definitions are not recursive:
the symbol being defined cannot occur in the body of the lambda term.
They should be understood as macros.
For instance, any occurrence of the term <math>f(t)</math>
where <math>f</math> is as defined above will be treated
as if it was the term <math>(2*t + 3)</math>.

=== Local symbol definitions ===

Constant and function symbols can also be declared locally anywhere within a term
by means of a let binder.
This is done with a declaration of the form

<center>
<math>
\mathrm{LET}\ f = s \ \mathrm{IN}\ t ;
</math>
</center>

where <math>t</math> is a term with no free variables, possibly a lambda term.
Let binders can be nested arbitrarily and follow the usual lexical scoping rules.
The following general form
<center>
<math>
\mathrm{LET}\ f_1 = t_1, f_2 = t_2, \ldots, f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>
can used as a shorthand for
<center>
<math>
\mathrm{LET}\ f_1 = t_1\ \mathrm{IN}\
\mathrm{LET}\ f_2 = t_2\ \mathrm{IN}\
\ldots \
\mathrm{LET}\ f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>

t: REAL =
LET x1 = 42,
g = LAMBDA(x:INT): x + 1,
x2 = 2*x1 + 7/2
IN
(LET x3 = g(x1) IN x3 + x2) / x1;

Note that the same symbol = is used, unambiguously, in the syntax of global declarations,
let declarations, and as a predicate symbol.

'''Note:'''
A <math>\mathrm{LET}</math> term with a multiple symbols defines them sequentially.
A parallel version of the <math>\mathrm{LET}</math> construct will be introduced in a later version.

== Built-in theories and their symbols ==

In addition to user-defined symbols, CVC4 terms can use a number of predefined symbols:
the logical symbols, such as <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, etc.,
as well as theory symbols, function symbols belonging to one of the built-in theories.
They are described next, with the theory symbols grouped by theory.

=== Logical Symbols ===

The logical symbols in CVC4's language include
the equality and disequality predicate symbols, respectively written as = and /=,
the multiarity disequality symbol <math>\mathrm{DISTINCT}</math>,
together with the logical constants <math>\mathrm{TRUE}</math>, <math>\mathrm{FALSE}</math>,
the connectives <math>\mathrm{NOT}</math>, <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, <math>\mathrm{XOR}</math>, <math>\Rightarrow</math>, <math>\Leftrightarrow</math>, and
the first-order quantifiers <math>\mathrm{EXISTS}</math> and <math>\mathrm{FORALL}</math>,
all with the standard many-sorted logic semantics.

The binary connectives have infix syntax and type
<math>(\mathrm{BOOLEAN},\mathrm{BOOLEAN}) \to \mathrm{BOOLEAN}</math>.
The symbols = and /=, which are also infix, are instead parametrically polymorphic,
having type <math>(T,T) \to \mathrm{BOOLEAN}</math>
for every first-order type <math>T</math>.
They are interpreted respectively as the identity relation and its complement.

The DISTINCT symbol is both overloaded and polymorphic.
It has type <math>(T,...,T) \to \mathrm{BOOLEAN}</math>
for every sequence <math>(T,...,T)</math> of length <math>n > 0</math>
and first-order type <math>T</math>.
For each <math>n > 0</math>, it is interpreted as the relation
that holds exactly for tuples of pairwise distinct elements.

The syntax for quantifiers is similar to that of the lambda binder.

Here is an example of a formula built just of these logical symbols and variables:

A, B: TYPE;

q: BOOLEAN = FORALL (x,y: A, i,j,k: B):
i = j AND i /= k => EXISTS (z: A): x /= z OR z /= y;

Binding and scoping of quantified variables follows the same rules as
in let expressions.
In particular, a quantifier will shadow in its scope any constant and function symbols
with the same name as one of the variables it quantifies:

A: TYPE;
i, j: INT;

% The first occurrence of i and of j in f are constant symbols,
% the others are variables.

f: BOOLEAN = i = j AND FORALL (i,j: A): i = j OR i /= j;

Optionally, it is also possible to specify instantiation patterns
for quantified variables.
The general syntax for a quantified formula <math>\psi</math> with patterns is

<center>
<math>
Q\;(x_1:T_1, \ldots, x_k:T_k):\; p_1: \ldots\; p_n:\; \varphi
</math>
</center>

where <math>n \geq 0</math>, <math>Q</math> is
either <math>\mathrm{FORALL}</math> or <math>\mathrm{EXISTS}</math>,
<math>\varphi</math> is a term of type <math>\mathrm{BOOLEAN}</math>,
and each of the <math>p_i</math>'s,
a pattern for the quantifier <math>Q\;(x_1:T_1, \ldots, x_k:T_k)</math>, has the form

<center>
<math>
\mathrm{PATTERN}\; (t_1, \ldots, t_m)
</math>
</center>

where <math>m > 0</math> and <math>t_1, \ldots, t_m</math> are
arbitrary binder-free terms (no lets, no quantifiers).
Those terms can contain (free) variables, typically, but not exclusively,
drawn from <math>x_1, \ldots, x_k</math>.
(Additional variables can occur if <math>\psi</math> occurs in a bigger formula
binding those variables.)

A: TYPE;
b, c: A;
p, q: A -> BOOLEAN;
r: (A, A) -> BOOLEAN;

ASSERT FORALL (x0, x1, x2: A):
PATTERN (r(x0, x1), r(x1, x2)):
(r(x0, x1) AND r(x1, x2)) => r(x0, x2) ;

ASSERT FORALL (x: A):
PATTERN (r(x, b)):
PATTERN (r(x, c)):
p(x) => q(x) ;

ASSERT EXISTS (y: A):
FORALL (x: A):
PATTERN (r(x, y), p(y)):
r(x, y) => q(x) ;

Patterns have no logical meaning:
adding them to a formula does not change its semantics.
Their purpose is purely operational, as explained in
the [[#Instantiation Patterns | Instantiation Patterns]] section.

In addition to these constructs, CVC4 also has a general mixfix conditional operator
of the form

<center>
<math>
\mathrm{IF}\ b\ \mathrm{THEN}\ t\ \mathrm{ELSIF}\ b_1\ \mathrm{THEN}\ t_1\ \ldots\ \mathrm{ELSIF}\ b_n\ \mathrm{THEN}\ t_n\ \mathrm{ELSE}\ t_{n+1}\ \mathrm{ENDIF}
</math>
</center>

with <math>n \geq 0</math> where
<math>b, b_1, \ldots, b_n</math> are terms of type <math>\mathrm{BOOLEAN}</math> and
<math>t, t_1, \ldots, t_n, t_{n+1}</math> are terms of the same first-order type <math>T</math>:

% Conditional term
x, y, z, w: REAL;

t: REAL =
IF x > 0 THEN y
ELSIF x >= 1 THEN z
ELSIF x > 2 THEN w
ELSE 2/3 ENDIF;

=== User-defined Functions and Types ===

The theory of user-defined functions,also know in the SMT literature as
the theory ''Equality over Uninterpreted Functions'', or ''EUF'', is in effect
a family of theories of equality parametrized by the basic types and the free symbols
a user can define during a run of CVC4.

This theory has no built-in symbols (other than the logical ones).
Its types consist of ''all and only'' the user-defined types.
Its function symbols consist of ''all and only'' the user-defined free symbols.

=== Arithmetic ===

The real arithmetic theory has two types:
<math>\mathrm{REAL}</math> and <math>\mathrm{INTEGER}</math>
with the latter a subtype of the first.
Its built-in symbols for the usual arithmetic constants
and operators over the type <math>\mathrm{REAL}</math>, each with the expected type:
all numerals 0, 1, ..., as well as - (both unary and binary), +, *, /, <, >, <=, >=.
Application of the binary symbols are in infix form.
Note that + is only binary, and so an expression such as +4 is ill-formed.

Rational values can be expressed in decimal or fractional format,
e.g., 0.1, 23.243241, 1/2, 3/4, and so on.
A leading 0 is mandatory for decimal numbers smaller than one
(e.g., the syntax .3 cannot be used as a shorthand for 0.3).
However, a trailing 0 is ''not'' required for decimals that are whole numbers
(e.g., 3. is allowed as a shorthand for 3.0).
The size of the numerals used in the representation of natural and rational numbers
is unbounded; more accurately, bounded only by the amount of available memory.

=== Bit vectors ===

=== Arrays ===

The theory of arrays is a parametric theory of (total) unary maps.
It comes equipped with mixfix polymorphic selection and update operators, respectively
<center>
<math>\_[\_]</math> and <math>\_\ \mathrm{WITH}\ [\_]\ := \_</math> .
</center>
The semantics of these operators is the expected one:
for all first-order types <math>T_1</math> and <math>T_2</math>,
if <math>a</math> is of type <math>\mathrm{ARRAY}\ T_1 \mathrm{OF}\ T_2</math>,
<math>i</math> is of type <math>T_1</math>, and
<math>v</math> is of type <math>T_2</math>,
* <math>a[i]</math> denotes the value that <math>a</math> associates to index <math>i</math>,
* <math>a\ \mathrm{WITH}\ [i]\ := v</math> denotes a map that associates <math>v</math> to index <math>i</math> and is otherwise identical to <math>a</math>.
Sequential updates can be chained with the shorthand syntax
<math>\_\ \mathrm{WITH}\ [\_]\ := \_, \ldots, [\_]\ := \_</math>.

A: TYPE = ARRAY INT OF REAL;
a: A;
i: INT = 4;

% selection:

elem: REAL = a[i];

% update

a1: A = a WITH [10] := 1/2;

% sequential update
% (syntactic sugar for (a WITH [10] := 2/3) WITH [42] := 3/2)

a2: A = a WITH [10] := 2/3, [42] := 3/2;

Since arrays are just maps, equality between them is extensional, that is,
for two arrays of the same type to be different they have to map at least one
index to differ values.

=== Data types ===

The theory of inductive data types is in fact a family of theories parametrized
by a data type declaration specifying constructors and selectors
for one or more user-defined data types.

No built-in operators other than equality and disequality are provided
for this family in the native language.
Each user-provided data type declaration, however, generates constructor, selector and tester operators
as described in the [[#Inductive Data Types | Inductive Data Types]] section.

=== Tuples and Records ===

Semantically both records and tuples can be seen as special instances
of inductive data types.
CVC4 implements them internally indeed as data types.
In essence, a record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math>
is encoded as a data type of the form

<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\ \ \mathrm{Record} = \mathit{rec}(l_0:T_0, \ldots, l_n:T_n) \\
\mathrm{END};
\end{array}
</math>
</center>

Tuples of length <math>n</math> are in turn special cases of records whose field names are
the numerals from <math>0</math> to <math>n-1</math>.

Externally, tuples and records have their own syntax for constructor and selector operators.
* Records of type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> have the associated record constructor <math>(\#\ l_0 := \_,\; \ldots,\; l_n := \_\ \#)</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.
* Tuples of type <math>[\ T_0, \ldots, T_n\ ]</math> have the associated tuple constructor <math>(\ \_,\; \ldots,\; \_\ )</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.

The selector operators on records and tuples follows a dot notation syntax.

% Record construction and field selection
Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);
k: INT = x.key;
v: REAL = x.weight;

% Tuple construction and projection
y: [REAL, INT, REAL] = ( 4/5, 9, 11/9 );
first_elem: REAL = y.0;
third_elem: REAL = y.2;

Differently from data types, records and tuples are also provided with built-in update operators similar in syntax and semantics to the update operator for arrays.
More precisely, for each record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .l_i\ := \_
</math>
</center>

The operator maps a record <math>r</math> of that type and a value <math>v</math>
of type <math>T_i</math> to the record that stores <math>v</math> in field <math>l_i</math>
and is otherwise identical to <math>r</math>.
Analogously, for each tuple type <math>[T_0, \ldots, T_n]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .i\ := \_
</math>
</center>

with similar semantics.

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = x WITH .weight := 48;

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = y WITH .1 := 3;

Updates to a nested component can be combined in a single WITH operator:

Cache: TYPE = ARRAY [0..100] OF [# addr: INT, data: REAL #];
State: TYPE = [# pc: INT, cache: Cache #];

s0: State;
s1: State = s0 WITH .cache[10].data := 2/3;

Note that, differently from updates on arrays, tuple and record updates are
just additional syntactic sugar.
For instance, the record <code>x1</code> and tuple <code>y1</code> defined above
could have been equivalently defined as follows:

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = (# key := x.key, weight := 48 #);

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = ( y.0, 3, y.1 );

== Commands ==

In addition to declarations of types and function symbols,
the CVC4 native language contains the following commands:

* <math>\mathrm{ASSERT}\ F</math> -- Add the formula <math>F</math> to the current logical context <math>\Gamma</math>.
* [[#CHECKSAT|<math>\mathrm{CHECKSAT}\ F</math>]] -- Check if the formula <math>F</math> is satisfiable in the current logical context (<math>\Gamma \not\models_T \mathrm{NOT}\ F</math>).
* <math>\mathrm{CONTINUE}</math> -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, search for a counter-example different from the current one.
* [[#COUNTEREXAMPLE|<math>\mathrm{COUNTEREXAMPLE}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print the context that is a witness for invalidity/satisfiability.
* [[#COUNTERMODEL|<math>\mathrm{COUNTERMODEL}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print a model that makes the formula invalid/satisfiable. The model is provided in terms of concrete values for each free symbol.
* <math>\mathrm{OPTION}\ o\ v</math> -- Set the command-line option flag <math>o</math> to value <math>v</math>. The argument <math>o</math> is provide as a string literal enclosed in double-quotes and <math>v</math> as an integer value.
* <math>\mathrm{POP}</math> -- Equivalent to <math>\mathrm{POPTO}\ 1</math>
* [[#POPTO|<math>\mathrm{POPTO}\ n</math>]] -- Restore the system to the state it was in right before the most recent call to <math>\mathrm{PUSH}</math> made from stack level <math>n</math>. Note that the current stack level is printed as part of the output of the <math>\mathrm{WHERE}</math> command.
* <math>\mathrm{PUSH}</math> -- Save (checkpoint) the current state of the system.
* [[#QUERY|<math>\mathrm{QUERY}\ F</math>]] -- Check if the formula <math>F</math> is valid in the current logical context (<math>\Gamma\models_T F</math>).
* [[#RESTART|<math>\mathrm{RESTART}\ F</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, repeat the check but with the additional assumption <math>F</math> in the context.
* <math>\mathrm{PRINT}\ t</math> -- Parse and print back the term <math>t</math>.
* <math>\mathrm{TRANSFORM}\ t</math> -- Simplify the term <math>t</math> and print the result.
* <math>\mathrm{WHERE}</math> -- Print all the formulas in the current logical context <math>\Gamma</math>.

The remaining commands take a single argument, given as a string literal enclosed in double-quotes.

* <math>\mathrm{ECHO}\ s</math> -- Print string <math>s</math>
* <math>\mathrm{INCLUDE}\ f</math> -- Read commands from file <math>f</math>.
* <math>\mathrm{TRACE}\ f</math> -- Turn on tracing for the debug flag <math>f</math>.
* <math>\mathrm{UNTRACE}\ f</math> -- Turn off tracing for the debug flag <math>f</math>.

Here, we explain some of the above commands in more detail.

=== QUERY ===

The command <math>\mathrm{QUERY}\ F</math> invokes the core functionality of CVC4 to check
the validity of the formula <math>F</math> with respect to the assertions made thus far,
which constitute the context <math>\Gamma</math>.
The argument <math>F</math> must be well typed term of type <math>\mathrm{BOOLEAN}</math>,
as described in [[#Terms and Formulas | Terms and Formulas]].

The execution of this command always terminates and produces one of three possible answers:
<code>valid</code>, <code>invalid</code>, and <code>unknown</code>.

* A <code>valid</code> answer indicates that <math>\Gamma \models_T F</math>. After a query returning such an answer, the logical context <math>\Gamma</math> is exactly as it was before the query.
* An <code>invalid</code> answer indicates that <math>\Gamma \not\models_T F</math>, that is, there is a model of the background theory <math>T</math> that satisfies <math>\Gamma \cup \{\mathrm{NOT}\ F\}</math>. When <math>\mathrm{QUERY}\ F</math> returns <code>invalid</code>, the logical context <math>\Gamma</math> is augmented with a set <math>\Delta</math> of ground (i.e., variable-free) literals such that <math>\Gamma\cup\Delta</math> is satisfiable in <math>T</math>, but <math>\Gamma\cup\Delta\models_T \mathrm{NOT}\ F</math>. In fact, in this case <math>\Delta</math> ''propositionally entails'' <math>\mathrm{NOT}\ F</math>, in the sense that, every truth assignment to the literals of <math>\Delta</math> that satisfies <math>\Delta</math> falsifies <math>F</math>. We call the new context <math>\Gamma\cup\Delta</math> a ''counterexample'' for <math>F</math>.
* An <code>unknown</code> answer is similar to an <code>invalid</code> answer in that additional literals are added to the context which propositionally entail <math>\mathrm{NOT}\ F</math>. The difference in this case is that CVC4 cannot guarantee that <math>\Gamma\cup\Delta</math> is actually satisfiable in <math>T</math>.

CVC4 may report <code>unknown</code> when the context or the query contains
non-linear arithmetic terms or quantifiers.
In all other cases, it is expected to be sound and complete,
i.e., to report <code>Valid</code> if <math>\Gamma \models_T F</math>
and <code>Invalid</code> otherwise.

After an <code>invalid</code> (resp. <code>unknown</code>) answer,
counterexamples (resp. possible counterexamples) can be obtained with
a <math>\mathrm{WHERE}</math>, <math>\mathrm{COUNTEREXAMPLE}</math>,
or <math>\mathrm{COUNTERMODEL}</math> command.


Since the <math>\mathrm{QUERY}</math> command may modify
the current context, if one needs to check several formulas in a row
in the same context, it is a good idea to surround every
query by a <math>\mathrm{PUSH}</math> and <math>\mathrm{POP}</math> invocation
in order to preserve the context:

PUSH;
QUERY <formula>;
POP;

=== CHECKSAT ===

The command <math>\mathrm{CHECKSAT}\ F</math> behaves identically
to <math>\mathrm{QUERY}\ \mathrm{NOT}\ F</math>.

=== RESTART ===

The command <math>\mathrm{RESTART}\ F</math> can only be invoked after an invalid query.
For example, in an interactive setting:

QUERY <formula>;

CVC4> invalid

RESTART <formula2>;

Functionally, the behavior of the above command sequence is identical to the following:

PUSH;
QUERY <formula>;
POP;
ASSERT <formula2>;
QUERY <formula>;

The advantage of using the <math>\mathrm{RESTART}</math> command is that
the first command sequence may be executed much more efficiently that the second.
The reason is that with <math>\mathrm{RESTART}</math> CVC4 will re-use
what it has learned while answering the previous query rather than starting
over from scratch.

=== COUNTERMODEL ===

[More]

=== COUNTEREXAMPLE ===

[More]

=== POPTO ===

[More]

== Instantiation Patterns ==

CVC4 processes each universally quantified formula in the current context
by adding instances of the formula obtained by replacing its universal variables
with ground terms.
Patterns restrict the choice of ground terms for the quantified variables,
with the goal of controlling the potential explosion of ground instances.
In essence, adding patterns to a formula is a way for the user to tell CVC4
to focus only on certain instances which, in the user's opinion, will be
most helpful during a proof.

In more detail, patterns have the following effect on formulas that are found
in the logical context or get added to it later while CVC4 is trying to prove
the validity of some formula <math>F</math>.

If a formula in the current context starts with an existential quantifier,
CVC4 ''Skolemizes'' it, that is, replaces it in the context with the formula
obtained by substituting the existentially quantified variables
by fresh constants and dropping the quantifier.
Any patterns for the existential quantifier are simply ignored.

If a formula starts with a universal quantifier
<math>\mathrm{FORALL}\; (x_1:T_1, \ldots, x_n:T_n)</math>,
CVC4 adds to the context a number of instances of the formula,
with the goal of using them to prove the query <math>F</math> valid.
An instance is obtained by replacing each <math>x_i</math> with a ground term
of the same type occurring in one of the formulas in the context,
and dropping the universal quantifier.
If <math>x_i</math> occurs in a pattern
<math>\mathrm{PATTERN}\; (t_1, \ldots, t_m)</math> for the quantifier,
it will be instantiated only with terms obtained by simultaneously matching
all the terms in the pattern against ground terms in the current context
<math>\Gamma</math>.

Specifically, the matching process produces one or more substitutions
<math>\sigma</math> for the variables in <math>(t_1, \ldots, t_m)</math>
which satisfy the following invariant:
for each <math>i = 1, \ldots, m</math>, <math>\sigma(t_i)</math> is
a ground term and there is a ground term <math>s_i</math> in <math>\Gamma</math>
such that <math>\Gamma \models_T \sigma(t_i) = s_i</math>.
The variables of <math>(x_1:T_1, \ldots, x_n:T_n)</math> that occur
in the pattern are instantiated only with those substitutions
(while any remaining variables are instantiated arbitrarily).

The Skolemized version or the added instances of a context formula may themselves
start with a quantifier.
The same instantiation process is applied to them too, recursively.

Note that the matching mechanism is not limited to syntactic matching
but is modulo the equations asserted in the context.
Because of decidability and/or efficiency limitations, the matching process
is not exhaustive.
CVC4 will typically miss some substitutions that satisfy the invariant above.
As a consequence, it might fail to prove the validity of the query formula
<math>F</math>, which makes CVC4 incomplete for contexts containing
quantified formulas.
It should be noted though that exhaustive matching, which can be achieved
simply by not specifying any patterns, does not yield completeness anyway
since the instantiation of universal variables is still restricted
to just the ground terms in the context,
whereas in general additional ground terms might be needed.

CVC4's native language

2012-12-03T21:20:38Z

Tinelli: /* The BOOLEAN Type */

= CVC4 native input language =

The native input language consists of a sequence of symbol declarations and commands, each followed by a semicolon (<code>;</code>).

Any text after the first occurrence of a percent character and to the end of the current line is a comment:

%%% This is a native language comment

== Type System ==

CVC4's type system includes a set of built-in types which can be expanded with additional user-defined types.

The type system consists of ''first-order'' types, ''subtypes'' of first-order types, and ''higher-order'' types, all of which are interpreted as sets.
For convenience, we will sometimes identify below the interpretation of a type with the type itself.

First-order types consist of basic types and structured types. The basic types are <math>\mathrm{BOOLEAN}</math>, <math>\mathrm{REAL}</math>, <math>\mathrm{BITVECTOR}(n)</math> for all <math>n > 0</math>, as well as user-defined basic types (also called uninterpreted types).
The structured types are array, tuple, record types, and ML-style user-defined (inductive) datatypes.

'''Note:''' Currently, subtypes consist only of the built-in subtype <math>\mathrm{INT}</math> of <math>\mathrm{REAL}</math>.

Support for CVC3-style user-defined subtypes will be added in a later release.

Function types are the only higher-order types.
More precisely, they are just second-order types
since function symbols in CVC4, both built-in and user-defined, can take as argument or return only values of
a first-order type.

=== Basic Types ===

==== The BOOLEAN Type ====

The <math>\mathrm{BOOLEAN}</math> type is interpreted as the two-element set of Boolean values
<math>\{\mathrm{TRUE},\; \mathrm{FALSE}\}</math>.

'''Note:''' CVC4's treatment of this type differs from CVC3's where <math>\mathrm{BOOLEAN}</math> is used only as the type of formulas, but not as value type. CVC3 follows the two-tiered structure of classical first-order logic
which distinguishes between formulas and terms, and allows terms to occur in formulas but not vice versa (with the exception of the IF-THEN-ELSE construct).
CVC4 drops the distinction between terms and formulas and defines the latter just as terms of type <math>\mathrm{BOOLEAN}</math>. As such, formulas can occur as subterms of possibly non-Boolean terms.

Example:

% Boolean constants
a, b: BOOLEAN;

% REAL constants
x,y: REAL

% Boolean-valued function, can be used as a predicate symbol
p: REAL -> BOOLEAN;
ASSERT a => p(x - y)

% Real-valued function with Boolean argument
f: BOOLEAN -> REAL;

% the argument of f can be a formula
ASSERT f(a OR b) > 0.3 OR p(x);

% Even a quantified one
ASSERT f(FORALL (r: REAL): r < r + 1);

==== The REAL Type ====

The <math>\mathrm{REAL}</math> type is interpreted as the set of real numbers.

Note that these are the (infinite precision) mathematical reals,
not the floating point numbers.
Support for floating point types is planned for future versions.

x, y : REAL;
QUERY (( x <= y ) AND ( y <= x )) => ( x = y );

==== The INT Type ====

The <math>\mathrm{INT}</math> type is interpreted as the set of integer numbers
and is considered a subtype of <math>\mathrm{REAL}</math>.
The latter means in particular that it is possible to mix integer and real terms
in expressions without the need of an explicit ''upcasting'' operator.

Note that these are the (infinite precision) mathematical integers,
not the finite precision machine integers used in most programming languages.
The latter are modeled by [[ #Bitvectors | bit vector ]] types.

x, y : INT;
QUERY ((2 * x + 4 * y <= 1) AND ( y >= x)) => (x <= 0);
z : REAL;
QUERY (2 * x + z <= 3.5) AND (z >= 1);

==== Bit Vector Types ====

For every positive integer <math>n</math>, the type <math>\mathrm{BITVECTOR}(n)</math> is interpreted as the set of all bit vectors of size <math>n</math>.
A rich set of bit vector operators is supported.

==== User-defined Basic Types ====

Users can define new basic types
(often referred to as ''uninterpreted'' types in the SMT literature).
Each such type is interpreted as a set of unspecified cardinality
but disjoint from any other type.

User-defined basic types are created by declarations like the following:

% User declarations of basic types:

MyBrandNewType: TYPE;

Apples, Oranges: TYPE;

=== Structured Types ===

CVC4's structured types are divided into the following families.

==== Array Types ====

Array types are created by the mixfix type constructors <math>\mathrm{ARRAY}\ \_\ \mathrm{OF}\ \_</math>
whose arguments can be instantiated by any value type.

I : TYPE;

%% Array types:

% Arrays with indices from I and values from REAL
Array1: TYPE = ARRAY I OF REAL;

% Arrays with integer indices and array values
Array2: TYPE = ARRAY INT OF (ARRAY INT OF REAL);

% Arrays with integer pair indices and integer values
IntMatrix: TYPE = ARRAY [INT, INT] OF INT;

An array type of the form <math>\mathrm{ARRAY}\ T_1\ \mathrm{OF}\ T_2</math> is interpreted
as the set of all total maps from <math>T_1</math> to <math>T_2</math>.
The main difference with the function type <math>T_1 \to T_2</math> is that arrays,
contrary to functions, are first-class objects of the language, that is, values of an array
type can be arguments or results of functions.
Furthermore, array types come equipped with an update operation.

==== Tuple Types ====

Tuple types are created by the mixfix type constructors

<center>
<math>
\begin{array}{l} [\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ \ ,\ \_\ ] \\[1ex] \ldots \end{array}
</math>
</center>

whose arguments can be instantiated by any value type.

IntArray: TYPE = ARRAY INT OF INT;

% Tuple type declarations

RealPair: TYPE = [REAL, REAL]

MyTuple: TYPE = [ REAL, IntArray, [INT, INT] ];

A tuple type of the form <math>[T_1, \ldots, T_n]</math> is interpreted
as the Cartesian product <math>T_1 \times \cdots \times T_n</math>.

Note that while the types <math>(T_1, \ldots, T_n) \to T</math> and
<math>[T_1 \times \cdots \times T_n] \to T</math> are semantically equivalent,
they are operationally different in CVC4.
The first is the type of functions that take <math>n</math> arguments
of respective type <math>T_1</math>, <math>\ldots</math>, <math>T_n</math>,
while the second is the type of functions that take one argument of an <math>n</math>-tuple type.

==== Record Types ====

Similar to, but more general than tuple types, record types are created by type constructors of the form

<center>
<math>
[\#\ l_1: \_\ ,\ \ldots\ ,\ l_n: \_\ \#]
</math>
</center>

where <math>n > 0</math>, <math>l_1,\ldots, l_n</math> are field labels,
and the arguments can be instantiated with any first-order types.

MyType: TYPE;

% Record declaration

RecordType: TYPE = [# id: REAL, age: INT, info: MyType #];

The order of the fields in a record type is meaningful:
permuting the field names gives a different type.

Note that record types are non-recursive.
For instance, it is not possible to declare a record type called <code>Person</code> containing
a field of type <code>Person</code>.
Recursive types are provided in CVC4 by the more general inductive data types.
(As a matter of fact, both record and tuple types are implemented internally as inductive data types.)

==== Inductive Data Types ====

Inductive data types in CVC4 are similar to inductive data types of functional languages.
They can be parametric or not.

===== Non-Parametric Data Types =====

Non-parametric data types are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1 & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2 & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types, including any <math>A_i</math>.
Such declarations define the data types <math>A_1, \ldots, A_n</math>.
For each data type <math>A_i</math> they introduce:

* constructor symbols <math>cons</math> of type <math>(T_1, \ldots, T_k) \to \mathit{type\_name}_i</math>,
* selector symbols <math>\mathit{sel}_j</math> of type <math>\mathit{type\_name}_i \to T_j</math>, and
* tester symbols <math>\mathit{is\_cons}</math> of type <math>\mathit{type\_name}_i \to \mathrm{BOOLEAN}</math>.

Note that permitting more than one data type to be defined in the same declarations allows
the definition of mutually recursive types.

% simple enumeration type

% implicitly defined are the testers: is_red, is_yellow and is_blue
% (similarly for the other data types)

DATATYPE
PrimaryColor = red | yellow | blue
END;

% infinite set of pairwise distinct values ..., v(-1), v(0), v(1), ...

DATATYPE
Id = v (id: INT)
END;

% ML-style integer lists

DATATYPE
IntList = nil | ins (head: INT, tail: IntList)
END;

% AST for lamba calculus

DATATYPE
Term = var (index: INT)
| apply (arg_1: Term, arg_2: Term)
| lambda (arg: INT, body: Term)
END;

% Trees

DATATYPE
Tree = tree (value: REAL, children: TreeList),
TreeList = nil_tl
| ins_tl (first_t1: Tree, rest_t1: TreeList)
END;

Constructor, selector and tester symbols defined for a data type have global scope.
So, for example, it is not possible for two different data types to use
the same name for a constructor.

An inductive data type is interpreted as a term algebra constructed by the constructor symbols
over some sets of generators.
For example, the type <code>IntList</code> defined above is interpreted as the set
of all terms constructed with <code>nil</code> and <code>ins</code> over the integers.

===== Parametric Data Types =====

Parametric data types are infinite families of (non-parametric) data types
with each family parametrized by one or more type variables.
They are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1[X_{1,1}, \ldots, X_{1,p_1}] & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2[X_{2,1}, \ldots, X_{2,p_2}] & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n[X_{n,1}, \ldots, X_{n,p_n}] & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name parametrized by the type variables <math>X_{i,1}, \ldots, X_{i,p_i}</math>
and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types,
possibly parametrized by <math>X_1, \ldots, X_p</math>, including any <math>A_i</math>.

% Parametric pairs
DATATYPE
Pair[X, Y] = pair (first: X, second: Y)
END;

% Parametric lists

DATATYPE
List[X] = nil | cons (head: X, tail: List[X])
END;

% Parametric trees using the list type above

DATATYPE
Tree[X] = node (value: X, children: List[Tree[X]]),
END;

The declarations above define infinitely many types of the form
Pair[S,T], List[T] and Tree[T] where S and T are first-order types.
Note that the identifier <code>List</code> above, for example, by itself does not denote a type.
In contrast, the terms <code>List[Real]</code>, <code>List[List[Real]]</code>, <code>List[Tree[INT]]</code>,
and so on do.

===== Restriction to Inductive Types =====

By adopting a term algebra semantics, CVC4 allows only ''inductive'' data types,
that is, data types whose values are essentially (labeled, ordered) finite trees.
Infinite structures such as streams or even finite but cyclic ones
such as circular lists are then excluded.
For instance, none of the following declarations define inductive data types,
and are rejected by CVC4:

DATATYPE
IntStream = s (first:INT, rest: IntStream)
END;

DATATYPE
RationalTree = node1 (child: RationalTree)
| node2 (left_child: RationalTree, right_child:RationalTree)
END;

DATATYPE
T1 = c1 (s1: T2),
T2 = c2 (s2: T1)
END;

In concrete, a declaration of <math>n \geq 1</math> datatypes <math>T_1, \ldots, T_n</math> will be rejected if for any one of the types <math>T_1, \ldots, T_n</math>, it is impossible to build a finite term of that type using only the constructors of <math>T_1, \ldots, T_n</math> and free constants of type other than <math>T_1, \ldots, T_n</math>.

Inductive data types are the only types where the user also chooses names for the built-in operations to:

* construct a value of the type (with the constructors),
* extract components from a value (with the selectors), or
* check if a value was constructed with a certain constructor or not (with the testers).

For all the other types, CVC4 provides predefined names for the built-in operations on the type.

=== Function Types ===

Function (<math>\to</math>) types are created by the mixfix type constructors
<center>
<math>
\begin{array}{l}
\_ \to \_ \\[1ex] (\ \_\ ,\ \_\ ) \to \_
\\[1ex] (\ \_\ ,\ \_\ ,\ \_\ ) \to \_
\\[1ex] \ldots
\end{array}
</math>
</center>
whose arguments can be instantiated by any first-order type.

% Function type declarations

UnaryFunType: TYPE = INT -> REAL;

BinaryFunType: TYPE = (REAL, REAL) -> ARRAY REAL OF REAL;

TernaryFunType: TYPE = (REAL, BITVECTOR(4), INT) -> BOOLEAN;

A function type of the form <math>(T_1, \ldots, T_n) \to T</math> with <math>n > 0</math> is interpreted as the set of all ''total'' functions from the Cartesian product <math>T_1 \times \cdots \times T_n</math> to <math>T</math>.

The example above also shows how to introduce type names.
A name like <code>UnaryFunType</code> above is just an abbreviation for the type <math>\mathrm{INT} \to \mathrm{REAL}</math> and can be used interchangeably with it.

In general, any type defined by a type expression <code>E</code> can be given a name with the declaration:

name : TYPE = E;

=== Type Checking ===

In CVC4, formulas and terms are statically typed at the level of types
(as opposed to subtypes) according to the usual rules of first-order many-sorted logic,
with the main difference that formulas are just terms of type <math>BOOLEAN</math>:

* each variable has one associated first-order type,
* each constant symbol has one or more associated first-order types,
* each function symbol has one or more associated function types,
* the type of a term consisting just of a variable is the type associated to that variable,
* the type of a term consisting just of a constant symbol is the type associated to that constant symbol,
* the term obtained by applying a function symbol <math>f</math> to the terms <math>t_1, \ldots, t_n</math> is <math>T</math> if <math>f</math> has type <math>(T_1, \ldots, T_n) \to T</math> and each <math>t_i</math> has type <math>T_i</math>.

Attempting to enter an ill-typed term will result in an error.

Another significant difference with standard many-sorted logic is that
some built-in symbols are parametrically polymorphic.
For instance, the function symbol for extracting the element of any array has
type <math>(\mathit{ARRAY}\ T_1\ \mathit{OF}\ T_2,\; T_1) \to T_2</math>
for all first-order types <math>T_1, T_2</math>.

==== Type Ascription ====

By the type inference rules above some terms might have more than one type.
This can happen with terms built with polymorphic data type constructors
that have more than one return type for the same input type.
In that case, a type ascription operator (<code>::</code>) must be applied
to the constructor to specify the intended return type.

DATATYPE [X]
List[X] = nil | cons (head: X, tail: List[X])
END;

ASSERT y = cons(1, nil::List[REAL]);

DATATYPE [X, Y]
Union[X, Y] = left(val_l: X) | right(val_r: Y)
END;

ASSERT y = left::Union[BOOLEAN, REAL](TRUE);

The constant symbol <math>\mathrm{nil}</math> declared above has infinitely many types
(<math>\mathrm{List}[\mathrm{REAL}]</math>, <math>\mathrm{List}[\mathrm{BOOLEAN}]</math>,
<math>\mathrm{List}[[\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{List}[\mathrm{List}[\mathrm{REAL}]]</math>, ...)
CVC4's type checker requires the user to indicate explicitly the type
of each occurrence of <code>nil</code> in a term.
Similarly,
the injection operator <code>left</code> has infinitely many return types
for the same input type, for instance:
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{REAL}]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, [\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{List}[\mathrm{REAL}]]</math>,
and so on.
Applications of <code>left</code> need to specify the intended returned typed, as shown above.

== Terms and Formulas ==

In addition to type expressions, CVC4 has expressions for terms and for formulas
(i.e., terms of type <math>\mathrm{BOOLEAN}</math>).
By and large, these are standard first-order terms built out of typed variables,
predefined theory-specific operators, free (i.e., user-defined) function symbols,
and quantifiers.
Extensions include an if-then-else operator, lambda abstractions, and local symbol
declarations, as illustrated below.
Note that these extensions still keep CVC4's language first-order.
In particular, lambda abstractions are restricted to take and return only terms of
a first-order type.
Similarly, variables can only be of a first-order type.

A number of built-in function symbols (for instance, the arithmetic ones) are used
as infix operators. All user-defined symbols are used as prefix ones.

User-defined, i.e., free, function symbols include ''constant symbols'' and
''predicate symbols'', respectively nullary function symbols and function symbols
with a <math>\mathrm{BOOLEAN}</math> return type.
These symbols are introduced with global declarations of the form
<math> f_1, \ldots, f_m: T;</math>
where <math>m > 0</math>, <math>f_i</math> are the names of the symbols and
<math>T</math> is their type:

% integer constants

a, b, c: INT;

% real constants

x, y, z: REAL;

% unary function

f1: REAL -> REAL;

% binary function

f2: (REAL, INT) -> REAL;

% unary function with a tuple argument

f3: [INT, REAL] -> BOOLEAN;

% binary predicate

p: (INT, REAL) -> BOOLEAN;

% Propositional "variables"

P, Q; BOOLEAN;

Like type declarations, function symbol declarations like the above have global scope
and must be unique.
In other words, it is not possible to declare a function symbol globally more than once
in the same lexical scope.
This entails among other things that globally-defined free symbols cannot be overloaded
with different types and that theory symbols cannot be redeclared globally as free symbols.

=== Global symbol definitions ===

As with types, a function symbol can be defined as the name of another term
of the corresponding type.
With constant symbols, this is done with a declaration of the form <math>f:T = t;</math> :

c: INT;

i: INT = 5 + 3*c; % i is effectively a shorthand for 5 + 3*c

j: REAL = 3/4;

t: [REAL, INT] = (2/3, -4);

r: [# key: INT, value: REAL #] = (# key := 4, value := (c + 1)/2 #);

f: BOOLEAN = FORALL (x:INT): x <= 0 OR x > c ;

A restriction on constants of type <math>\mathit{BOOLEAN}</math> is that their value
can only be a closed formula, that is, a formula with no free variables.

A term and its name can be used interchangeably in later expressions.
Named terms are often useful for shared subterms (terms used several times in different places)
since their use can make the input exponentially more concise.
Named terms are processed very efficiently by CVC4.
It is much more efficient to associate a complex term with a name directly rather than
to declare a constant and later assert that it is equal to the same term.
This point is explained in more detail later in section [[Commands | Commands]].

More generally, in CVC4 one can associate a term to function symbols of any arity.
For non-constant function symbols this is done with a declaration of the form

<center>
<math>f:(T_1, \ldots, T_n) \to T = \mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t\;;</math>
</center>

where <math>t</math> is any term of type <math>T</math> with free variables
in <math>\{x_1, \ldots, x_n\}</math>.
The lambda binder has the usual semantics and conforms to the usual lexical scoping rules:
within the term <math>t</math> the declaration of the symbols <math>x_1, \ldots, x_n</math>
as local variables of respective type <math>T_1, \ldots, T_n</math> hides any previous
declarations of those symbols that are in scope.

As a general shorthand, when <math>k</math> consecutive types
<math>T_i, \ldots, T_{i+k-1}</math> in the lambda expression
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t</math> are identical, the syntax
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x_i,\ldots, x_{i+k-1}:T_i,\ldots, x:T_n): t</math>
can also be used.

% Global declaration of x as a unary function symbol

x: REAL -> REAL;

% Local declarations of x as variable (hiding the global one)

f: REAL -> REAL = LAMBDA (x: REAL): 2*x + 3;

p: (INT, INT) -> BOOLEAN = LAMBDA (x,i: INT): i*x - 1 > 0;

g: (REAL, INT) -> [REAL, INT] = LAMBDA (x: REAL, i:INT): (x + 1, i - 3);

Note that lambda definitions are not recursive:
the symbol being defined cannot occur in the body of the lambda term.
They should be understood as macros.
For instance, any occurrence of the term <math>f(t)</math>
where <math>f</math> is as defined above will be treated
as if it was the term <math>(2*t + 3)</math>.

=== Local symbol definitions ===

Constant and function symbols can also be declared locally anywhere within a term
by means of a let binder.
This is done with a declaration of the form

<center>
<math>
\mathrm{LET}\ f = s \ \mathrm{IN}\ t ;
</math>
</center>

where <math>t</math> is a term with no free variables, possibly a lambda term.
Let binders can be nested arbitrarily and follow the usual lexical scoping rules.
The following general form
<center>
<math>
\mathrm{LET}\ f_1 = t_1, f_2 = t_2, \ldots, f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>
can used as a shorthand for
<center>
<math>
\mathrm{LET}\ f_1 = t_1\ \mathrm{IN}\
\mathrm{LET}\ f_2 = t_2\ \mathrm{IN}\
\ldots \
\mathrm{LET}\ f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>

t: REAL =
LET x1 = 42,
g = LAMBDA(x:INT): x + 1,
x2 = 2*x1 + 7/2
IN
(LET x3 = g(x1) IN x3 + x2) / x1;

Note that the same symbol = is used, unambiguously, in the syntax of global declarations,
let declarations, and as a predicate symbol.

'''Note:'''
A <math>\mathrm{LET}</math> term with a multiple symbols defines them sequentially.
A parallel version of the <math>\mathrm{LET}</math> construct will be introduced in a later version.

== Built-in theories and their symbols ==

In addition to user-defined symbols, CVC4 terms can use a number of predefined symbols:
the logical symbols, such as <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, etc.,
as well as theory symbols, function symbols belonging to one of the built-in theories.
They are described next, with the theory symbols grouped by theory.

=== Logical Symbols ===

The logical symbols in CVC4's language include
the equality and disequality predicate symbols, respectively written as = and /=,
the multiarity disequality symbol <math>\mathrm{DISTINCT}</math>,
together with the logical constants <math>\mathrm{TRUE}</math>, <math>\mathrm{FALSE}</math>,
the connectives <math>\mathrm{NOT}</math>, <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, <math>\mathrm{XOR}</math>, <math>\Rightarrow</math>, <math>\Leftrightarrow</math>, and
the first-order quantifiers <math>\mathrm{EXISTS}</math> and <math>\mathrm{FORALL}</math>,
all with the standard many-sorted logic semantics.

The binary connectives have infix syntax and type
<math>(\mathrm{BOOLEAN},\mathrm{BOOLEAN}) \to \mathrm{BOOLEAN}</math>.
The symbols = and /=, which are also infix, are instead parametrically polymorphic,
having type <math>(T,T) \to \mathrm{BOOLEAN}</math>
for every first-order type <math>T</math>.
They are interpreted respectively as the identity relation and its complement.

The DISTINCT symbol is both overloaded and polymorphic.
It has type <math>(T,...,T) \to \mathrm{BOOLEAN}</math>
for every sequence <math>(T,...,T)</math> of length <math>n > 0</math>
and first-order type <math>T</math>.
For each <math>n > 0</math>, it is interpreted as the relation
that holds exactly for tuples of pairwise distinct elements.

The syntax for quantifiers is similar to that of the lambda binder.

Here is an example of a formula built just of these logical symbols and variables:

A, B: TYPE;

q: BOOLEAN = FORALL (x,y: A, i,j,k: B):
i = j AND i /= k => EXISTS (z: A): x /= z OR z /= y;

Binding and scoping of quantified variables follows the same rules as
in let expressions.
In particular, a quantifier will shadow in its scope any constant and function symbols
with the same name as one of the variables it quantifies:

A: TYPE;
i, j: INT;

% The first occurrence of i and of j in f are constant symbols,
% the others are variables.

f: BOOLEAN = i = j AND FORALL (i,j: A): i = j OR i /= j;

Optionally, it is also possible to specify instantiation patterns
for quantified variables.
The general syntax for a quantified formula <math>\psi</math> with patterns is

<center>
<math>
Q\;(x_1:T_1, \ldots, x_k:T_k):\; p_1: \ldots\; p_n:\; \varphi
</math>
</center>

where <math>n \geq 0</math>, <math>Q</math> is
either <math>\mathrm{FORALL}</math> or <math>\mathrm{EXISTS}</math>,
<math>\varphi</math> is a term of type <math>\mathrm{BOOLEAN}</math>,
and each of the <math>p_i</math>'s,
a pattern for the quantifier <math>Q\;(x_1:T_1, \ldots, x_k:T_k)</math>, has the form

<center>
<math>
\mathrm{PATTERN}\; (t_1, \ldots, t_m)
</math>
</center>

where <math>m > 0</math> and <math>t_1, \ldots, t_m</math> are
arbitrary binder-free terms (no lets, no quantifiers).
Those terms can contain (free) variables, typically, but not exclusively,
drawn from <math>x_1, \ldots, x_k</math>.
(Additional variables can occur if <math>\psi</math> occurs in a bigger formula
binding those variables.)

A: TYPE;
b, c: A;
p, q: A -> BOOLEAN;
r: (A, A) -> BOOLEAN;

ASSERT FORALL (x0, x1, x2: A):
PATTERN (r(x0, x1), r(x1, x2)):
(r(x0, x1) AND r(x1, x2)) => r(x0, x2) ;

ASSERT FORALL (x: A):
PATTERN (r(x, b)):
PATTERN (r(x, c)):
p(x) => q(x) ;

ASSERT EXISTS (y: A):
FORALL (x: A):
PATTERN (r(x, y), p(y)):
r(x, y) => q(x) ;

Patterns have no logical meaning:
adding them to a formula does not change its semantics.
Their purpose is purely operational, as explained in
the [[#Instantiation Patterns | Instantiation Patterns]] section.

In addition to these constructs, CVC4 also has a general mixfix conditional operator
of the form

<center>
<math>
\mathrm{IF}\ b\ \mathrm{THEN}\ t\ \mathrm{ELSIF}\ b_1\ \mathrm{THEN}\ t_1\ \ldots\ \mathrm{ELSIF}\ b_n\ \mathrm{THEN}\ t_n\ \mathrm{ELSE}\ t_{n+1}\ \mathrm{ENDIF}
</math>
</center>

with <math>n \geq 0</math> where
<math>b, b_1, \ldots, b_n</math> are terms of type <math>\mathrm{BOOLEAN}</math> and
<math>t, t_1, \ldots, t_n, t_{n+1}</math> are terms of the same first-order type <math>T</math>:

% Conditional term
x, y, z, w: REAL;

t: REAL =
IF x > 0 THEN y
ELSIF x >= 1 THEN z
ELSIF x > 2 THEN w
ELSE 2/3 ENDIF;

=== User-defined Functions and Types ===

The theory of user-defined functions,also know in the SMT literature as
the theory ''Equality over Uninterpreted Functions'', or ''EUF'', is in effect
a family of theories of equality parametrized by the basic types and the free symbols
a user can define during a run of CVC4.

This theory has no built-in symbols (other than the logical ones).
Its types consist of ''all and only'' the user-defined types.
Its function symbols consist of ''all and only'' the user-defined free symbols.

=== Arithmetic ===

The real arithmetic theory has two types:
<math>\mathrm{REAL}</math> and <math>\mathrm{INTEGER}</math>
with the latter a subtype of the first.
Its built-in symbols for the usual arithmetic constants
and operators over the type <math>\mathrm{REAL}</math>, each with the expected type:
all numerals 0, 1, ..., as well as - (both unary and binary), +, *, /, <, >, <=, >=.
Application of the binary symbols are in infix form.
Note that + is only binary, and so an expression such as +4 is ill-formed.

Rational values can be expressed in decimal or fractional format,
e.g., 0.1, 23.243241, 1/2, 3/4, and so on.
A leading 0 is mandatory for decimal numbers smaller than one
(e.g., the syntax .3 cannot be used as a shorthand for 0.3).
However, a trailing 0 is ''not'' required for decimals that are whole numbers
(e.g., 3. is allowed as a shorthand for 3.0).
The size of the numerals used in the representation of natural and rational numbers
is unbounded; more accurately, bounded only by the amount of available memory.

=== Bit vectors ===

=== Arrays ===

The theory of arrays is a parametric theory of (total) unary maps.
It comes equipped with mixfix polymorphic selection and update operators, respectively
<center>
<math>\_[\_]</math> and <math>\_\ \mathrm{WITH}\ [\_]\ := \_</math> .
</center>
The semantics of these operators is the expected one:
for all first-order types <math>T_1</math> and <math>T_2</math>,
if <math>a</math> is of type <math>\mathrm{ARRAY}\ T_1 \mathrm{OF}\ T_2</math>,
<math>i</math> is of type <math>T_1</math>, and
<math>v</math> is of type <math>T_2</math>,
* <math>a[i]</math> denotes the value that <math>a</math> associates to index <math>i</math>,
* <math>a\ \mathrm{WITH}\ [i]\ := v</math> denotes a map that associates <math>v</math> to index <math>i</math> and is otherwise identical to <math>a</math>.
Sequential updates can be chained with the shorthand syntax
<math>\_\ \mathrm{WITH}\ [\_]\ := \_, \ldots, [\_]\ := \_</math>.

A: TYPE = ARRAY INT OF REAL;
a: A;
i: INT = 4;

% selection:

elem: REAL = a[i];

% update

a1: A = a WITH [10] := 1/2;

% sequential update
% (syntactic sugar for (a WITH [10] := 2/3) WITH [42] := 3/2)

a2: A = a WITH [10] := 2/3, [42] := 3/2;

Since arrays are just maps, equality between them is extensional, that is,
for two arrays of the same type to be different they have to map at least one
index to differ values.

=== Data types ===

The theory of inductive data types is in fact a family of theories parametrized
by a data type declaration specifying constructors and selectors
for one or more user-defined data types.

No built-in operators other than equality and disequality are provided
for this family in the native language.
Each user-provided data type declaration, however, generates constructor, selector and tester operators
as described in the [[#Inductive Data Types | Inductive Data Types]] section.

=== Tuples and Records ===

Semantically both records and tuples can be seen as special instances
of inductive data types.
CVC4 implements them internally indeed as data types.
In essence, a record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math>
is encoded as a data type of the form

<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\ \ \mathrm{Record} = \mathit{rec}(l_0:T_0, \ldots, l_n:T_n) \\
\mathrm{END};
\end{array}
</math>
</center>

Tuples of length <math>n</math> are in turn special cases of records whose field names are
the numerals from <math>0</math> to <math>n-1</math>.

Externally, tuples and records have their own syntax for constructor and selector operators.
* Records of type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> have the associated record constructor <math>(\#\ l_0 := \_,\; \ldots,\; l_n := \_\ \#)</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.
* Tuples of type <math>[\ T_0, \ldots, T_n\ ]</math> have the associated tuple constructor <math>(\ \_,\; \ldots,\; \_\ )</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.

The selector operators on records and tuples follows a dot notation syntax.

% Record construction and field selection
Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);
k: INT = x.key;
v: REAL = x.weight;

% Tuple construction and projection
y: [REAL, INT, REAL] = ( 4/5, 9, 11/9 );
first_elem: REAL = y.0;
third_elem: REAL = y.2;

Differently from data types, records and tuples are also provided with built-in update operators similar in syntax and semantics to the update operator for arrays.
More precisely, for each record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .l_i\ := \_
</math>
</center>

The operator maps a record <math>r</math> of that type and a value <math>v</math>
of type <math>T_i</math> to the record that stores <math>v</math> in field <math>l_i</math>
and is otherwise identical to <math>r</math>.
Analogously, for each tuple type <math>[T_0, \ldots, T_n]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .i\ := \_
</math>
</center>

with similar semantics.

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = x WITH .weight := 48;

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = y WITH .1 := 3;

Updates to a nested component can be combined in a single WITH operator:

Cache: TYPE = ARRAY [0..100] OF [# addr: INT, data: REAL #];
State: TYPE = [# pc: INT, cache: Cache #];

s0: State;
s1: State = s0 WITH .cache[10].data := 2/3;

Note that, differently from updates on arrays, tuple and record updates are
just additional syntactic sugar.
For instance, the record <code>x1</code> and tuple <code>y1</code> defined above
could have been equivalently defined as follows:

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = (# key := x.key, weight := 48 #);

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = ( y.0, 3, y.1 );

== Commands ==

In addition to declarations of types and function symbols,
the CVC4 native language contains the following commands:

* <math>\mathrm{ASSERT}\ F</math> -- Add the formula <math>F</math> to the current logical context <math>\Gamma</math>.
* [[#CHECKSAT|<math>\mathrm{CHECKSAT}\ F</math>]] -- Check if the formula <math>F</math> is satisfiable in the current logical context (<math>\Gamma \not\models_T \mathrm{NOT}\ F</math>).
* <math>\mathrm{CONTINUE}</math> -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, search for a counter-example different from the current one.
* [[#COUNTEREXAMPLE|<math>\mathrm{COUNTEREXAMPLE}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print the context that is a witness for invalidity/satisfiability.
* [[#COUNTERMODEL|<math>\mathrm{COUNTERMODEL}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print a model that makes the formula invalid/satisfiable. The model is provided in terms of concrete values for each free symbol.
* <math>\mathrm{OPTION}\ o\ v</math> -- Set the command-line option flag <math>o</math> to value <math>v</math>. The argument <math>o</math> is provide as a string literal enclosed in double-quotes and <math>v</math> as an integer value.
* <math>\mathrm{POP}</math> -- Equivalent to <math>\mathrm{POPTO}\ 1</math>
* [[#POPTO|<math>\mathrm{POPTO}\ n</math>]] -- Restore the system to the state it was in right before the most recent call to <math>\mathrm{PUSH}</math> made from stack level <math>n</math>. Note that the current stack level is printed as part of the output of the <math>\mathrm{WHERE}</math> command.
* <math>\mathrm{PUSH}</math> -- Save (checkpoint) the current state of the system.
* [[#QUERY|<math>\mathrm{QUERY}\ F</math>]] -- Check if the formula <math>F</math> is valid in the current logical context (<math>\Gamma\models_T F</math>).
* [[#RESTART|<math>\mathrm{RESTART}\ F</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, repeat the check but with the additional assumption <math>F</math> in the context.
* <math>\mathrm{PRINT}\ t</math> -- Parse and print back the term <math>t</math>.
* <math>\mathrm{TRANSFORM}\ t</math> -- Simplify the term <math>t</math> and print the result.
* <math>\mathrm{WHERE}</math> -- Print all the formulas in the current logical context <math>\Gamma</math>.

The remaining commands take a single argument, given as a string literal enclosed in double-quotes.

* <math>\mathrm{ECHO}\ s</math> -- Print string <math>s</math>
* <math>\mathrm{INCLUDE}\ f</math> -- Read commands from file <math>f</math>.
* <math>\mathrm{TRACE}\ f</math> -- Turn on tracing for the debug flag <math>f</math>.
* <math>\mathrm{UNTRACE}\ f</math> -- Turn off tracing for the debug flag <math>f</math>.

Here, we explain some of the above commands in more detail.

=== QUERY ===

The command <math>\mathrm{QUERY}\ F</math> invokes the core functionality of CVC4 to check
the validity of the formula <math>F</math> with respect to the assertions made thus far,
which constitute the context <math>\Gamma</math>.
The argument <math>F</math> must be well typed term of type <math>\mathrm{BOOLEAN}</math>,
as described in [[#Terms and Formulas | Terms and Formulas]].

The execution of this command always terminates and produces one of three possible answers:
<code>valid</code>, <code>invalid</code>, and <code>unknown</code>.

* A <code>valid</code> answer indicates that <math>\Gamma \models_T F</math>. After a query returning such an answer, the logical context <math>\Gamma</math> is exactly as it was before the query.
* An <code>invalid</code> answer indicates that <math>\Gamma \not\models_T F</math>, that is, there is a model of the background theory <math>T</math> that satisfies <math>\Gamma \cup \{\mathrm{NOT}\ F\}</math>. When <math>\mathrm{QUERY}\ F</math> returns <code>invalid</code>, the logical context <math>\Gamma</math> is augmented with a set <math>\Delta</math> of ground (i.e., variable-free) literals such that <math>\Gamma\cup\Delta</math> is satisfiable in <math>T</math>, but <math>\Gamma\cup\Delta\models_T \mathrm{NOT}\ F</math>. In fact, in this case <math>\Delta</math> ''propositionally entails'' <math>\mathrm{NOT}\ F</math>, in the sense that, every truth assignment to the literals of <math>\Delta</math> that satisfies <math>\Delta</math> falsifies <math>F</math>. We call the new context <math>\Gamma\cup\Delta</math> a ''counterexample'' for <math>F</math>.
* An <code>unknown</code> answer is similar to an <code>invalid</code> answer in that additional literals are added to the context which propositionally entail <math>\mathrm{NOT}\ F</math>. The difference in this case is that CVC4 cannot guarantee that <math>\Gamma\cup\Delta</math> is actually satisfiable in <math>T</math>.

CVC4 may report <code>unknown</code> when the context or the query contains
non-linear arithmetic terms or quantifiers.
In all other cases, it is expected to be sound and complete,
i.e., to report <code>Valid</code> if <math>\Gamma \models_T F</math>
and <code>Invalid</code> otherwise.

After an <code>invalid</code> (resp. <code>unknown</code>) answer,
counterexamples (resp. possible counterexamples) can be obtained with
a <math>\mathrm{WHERE}</math>, <math>\mathrm{COUNTEREXAMPLE}</math>,
or <math>\mathrm{COUNTERMODEL}</math> command.


Since the <math>\mathrm{QUERY}</math> command may modify
the current context, if one needs to check several formulas in a row
in the same context, it is a good idea to surround every
query by a <math>\mathrm{PUSH}</math> and <math>\mathrm{POP}</math> invocation
in order to preserve the context:

PUSH;
QUERY <formula>;
POP;

=== CHECKSAT ===

The command <math>\mathrm{CHECKSAT}\ F</math> behaves identically
to <math>\mathrm{QUERY}\ \mathrm{NOT}\ F</math>.

=== RESTART ===

The command <math>\mathrm{RESTART}\ F</math> can only be invoked after an invalid query.
For example, in an interactive setting:

QUERY <formula>;

CVC4> invalid

RESTART <formula2>;

Functionally, the behavior of the above command sequence is identical to the following:

PUSH;
QUERY <formula>;
POP;
ASSERT <formula2>;
QUERY <formula>;

The advantage of using the <math>\mathrm{RESTART}</math> command is that
the first command sequence may be executed much more efficiently that the second.
The reason is that with <math>\mathrm{RESTART}</math> CVC4 will re-use
what it has learned while answering the previous query rather than starting
over from scratch.

=== COUNTERMODEL ===

[More]

=== COUNTEREXAMPLE ===

[More]

=== POPTO ===

[More]

== Instantiation Patterns ==

CVC4 processes each universally quantified formula in the current context
by adding instances of the formula obtained by replacing its universal variables
with ground terms.
Patterns restrict the choice of ground terms for the quantified variables,
with the goal of controlling the potential explosion of ground instances.
In essence, adding patterns to a formula is a way for the user to tell CVC4
to focus only on certain instances which, in the user's opinion, will be
most helpful during a proof.

In more detail, patterns have the following effect on formulas that are found
in the logical context or get added to it later while CVC4 is trying to prove
the validity of some formula <math>F</math>.

If a formula in the current context starts with an existential quantifier,
CVC4 ''Skolemizes'' it, that is, replaces it in the context with the formula
obtained by substituting the existentially quantified variables
by fresh constants and dropping the quantifier.
Any patterns for the existential quantifier are simply ignored.

If a formula starts with a universal quantifier
<math>\mathrm{FORALL}\; (x_1:T_1, \ldots, x_n:T_n)</math>,
CVC4 adds to the context a number of instances of the formula,
with the goal of using them to prove the query <math>F</math> valid.
An instance is obtained by replacing each <math>x_i</math> with a ground term
of the same type occurring in one of the formulas in the context,
and dropping the universal quantifier.
If <math>x_i</math> occurs in a pattern
<math>\mathrm{PATTERN}\; (t_1, \ldots, t_m)</math> for the quantifier,
it will be instantiated only with terms obtained by simultaneously matching
all the terms in the pattern against ground terms in the current context
<math>\Gamma</math>.

Specifically, the matching process produces one or more substitutions
<math>\sigma</math> for the variables in <math>(t_1, \ldots, t_m)</math>
which satisfy the following invariant:
for each <math>i = 1, \ldots, m</math>, <math>\sigma(t_i)</math> is
a ground term and there is a ground term <math>s_i</math> in <math>\Gamma</math>
such that <math>\Gamma \models_T \sigma(t_i) = s_i</math>.
The variables of <math>(x_1:T_1, \ldots, x_n:T_n)</math> that occur
in the pattern are instantiated only with those substitutions
(while any remaining variables are instantiated arbitrarily).

The Skolemized version or the added instances of a context formula may themselves
start with a quantifier.
The same instantiation process is applied to them too, recursively.

Note that the matching mechanism is not limited to syntactic matching
but is modulo the equations asserted in the context.
Because of decidability and/or efficiency limitations, the matching process
is not exhaustive.
CVC4 will typically miss some substitutions that satisfy the invariant above.
As a consequence, it might fail to prove the validity of the query formula
<math>F</math>, which makes CVC4 incomplete for contexts containing
quantified formulas.
It should be noted though that exhaustive matching, which can be achieved
simply by not specifying any patterns, does not yield completeness anyway
since the instantiation of universal variables is still restricted
to just the ground terms in the context,
whereas in general additional ground terms might be needed.

CVC4's native language

2012-12-03T21:19:41Z

Tinelli: Added example

= CVC4 native input language =

The native input language consists of a sequence of symbol declarations and commands, each followed by a semicolon (<code>;</code>).

Any text after the first occurrence of a percent character and to the end of the current line is a comment:

%%% This is a native language comment

== Type System ==

CVC4's type system includes a set of built-in types which can be expanded with additional user-defined types.

The type system consists of ''first-order'' types, ''subtypes'' of first-order types, and ''higher-order'' types, all of which are interpreted as sets.
For convenience, we will sometimes identify below the interpretation of a type with the type itself.

First-order types consist of basic types and structured types. The basic types are <math>\mathrm{BOOLEAN}</math>, <math>\mathrm{REAL}</math>, <math>\mathrm{BITVECTOR}(n)</math> for all <math>n > 0</math>, as well as user-defined basic types (also called uninterpreted types).
The structured types are array, tuple, record types, and ML-style user-defined (inductive) datatypes.

'''Note:''' Currently, subtypes consist only of the built-in subtype <math>\mathrm{INT}</math> of <math>\mathrm{REAL}</math>.

Support for CVC3-style user-defined subtypes will be added in a later release.

Function types are the only higher-order types.
More precisely, they are just second-order types
since function symbols in CVC4, both built-in and user-defined, can take as argument or return only values of
a first-order type.

=== Basic Types ===

==== The BOOLEAN Type ====

The <math>\mathrm{BOOLEAN}</math> type is interpreted as the two-element set of Boolean values
<math>\{\mathrm{TRUE},\; \mathrm{FALSE}\}</math>.

'''Note:''' CVC4's treatment of this type differs from CVC3's where <math>\mathrm{BOOLEAN}</math> is used only as the type of formulas, but not as value type. CVC3 follows the two-tiered structure of classical first-order logic
which distinguishes between formulas and terms, and allows terms to occur in formulas but not vice versa (with the exception of the IF-THEN-ELSE construct).
CVC4 drops the distinction between terms and formulas and defines the latter just as terms of type <math>\mathrm{BOOLEAN}</math>. As such, formulas can occur as subterms of possibly non-Boolean terms.

Example:

% Boolean constants
a, b: BOOLEAN;

% REAL constants
x,y: REAL

% Boolean-valued function, can be used as a predicate symbol
p: REAL -> BOOLEAN;
ASSERT a => p(x - y)

% Real-valued function with Boolean argument
f: BOOLEAN -> REAL;

% the argument of f can be formula
ASSERT f(a OR b) > 0.3 OR p(x);

% Even a quantified one
ASSERT f(FORALL (r: REAL): r < r + 1);

==== The REAL Type ====

The <math>\mathrm{REAL}</math> type is interpreted as the set of real numbers.

Note that these are the (infinite precision) mathematical reals,
not the floating point numbers.
Support for floating point types is planned for future versions.

x, y : REAL;
QUERY (( x <= y ) AND ( y <= x )) => ( x = y );

==== The INT Type ====

The <math>\mathrm{INT}</math> type is interpreted as the set of integer numbers
and is considered a subtype of <math>\mathrm{REAL}</math>.
The latter means in particular that it is possible to mix integer and real terms
in expressions without the need of an explicit ''upcasting'' operator.

Note that these are the (infinite precision) mathematical integers,
not the finite precision machine integers used in most programming languages.
The latter are modeled by [[ #Bitvectors | bit vector ]] types.

x, y : INT;
QUERY ((2 * x + 4 * y <= 1) AND ( y >= x)) => (x <= 0);
z : REAL;
QUERY (2 * x + z <= 3.5) AND (z >= 1);

==== Bit Vector Types ====

For every positive integer <math>n</math>, the type <math>\mathrm{BITVECTOR}(n)</math> is interpreted as the set of all bit vectors of size <math>n</math>.
A rich set of bit vector operators is supported.

==== User-defined Basic Types ====

Users can define new basic types
(often referred to as ''uninterpreted'' types in the SMT literature).
Each such type is interpreted as a set of unspecified cardinality
but disjoint from any other type.

User-defined basic types are created by declarations like the following:

% User declarations of basic types:

MyBrandNewType: TYPE;

Apples, Oranges: TYPE;

=== Structured Types ===

CVC4's structured types are divided into the following families.

==== Array Types ====

Array types are created by the mixfix type constructors <math>\mathrm{ARRAY}\ \_\ \mathrm{OF}\ \_</math>
whose arguments can be instantiated by any value type.

I : TYPE;

%% Array types:

% Arrays with indices from I and values from REAL
Array1: TYPE = ARRAY I OF REAL;

% Arrays with integer indices and array values
Array2: TYPE = ARRAY INT OF (ARRAY INT OF REAL);

% Arrays with integer pair indices and integer values
IntMatrix: TYPE = ARRAY [INT, INT] OF INT;

An array type of the form <math>\mathrm{ARRAY}\ T_1\ \mathrm{OF}\ T_2</math> is interpreted
as the set of all total maps from <math>T_1</math> to <math>T_2</math>.
The main difference with the function type <math>T_1 \to T_2</math> is that arrays,
contrary to functions, are first-class objects of the language, that is, values of an array
type can be arguments or results of functions.
Furthermore, array types come equipped with an update operation.

==== Tuple Types ====

Tuple types are created by the mixfix type constructors

<center>
<math>
\begin{array}{l} [\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ \ ,\ \_\ ] \\[1ex] \ldots \end{array}
</math>
</center>

whose arguments can be instantiated by any value type.

IntArray: TYPE = ARRAY INT OF INT;

% Tuple type declarations

RealPair: TYPE = [REAL, REAL]

MyTuple: TYPE = [ REAL, IntArray, [INT, INT] ];

A tuple type of the form <math>[T_1, \ldots, T_n]</math> is interpreted
as the Cartesian product <math>T_1 \times \cdots \times T_n</math>.

Note that while the types <math>(T_1, \ldots, T_n) \to T</math> and
<math>[T_1 \times \cdots \times T_n] \to T</math> are semantically equivalent,
they are operationally different in CVC4.
The first is the type of functions that take <math>n</math> arguments
of respective type <math>T_1</math>, <math>\ldots</math>, <math>T_n</math>,
while the second is the type of functions that take one argument of an <math>n</math>-tuple type.

==== Record Types ====

Similar to, but more general than tuple types, record types are created by type constructors of the form

<center>
<math>
[\#\ l_1: \_\ ,\ \ldots\ ,\ l_n: \_\ \#]
</math>
</center>

where <math>n > 0</math>, <math>l_1,\ldots, l_n</math> are field labels,
and the arguments can be instantiated with any first-order types.

MyType: TYPE;

% Record declaration

RecordType: TYPE = [# id: REAL, age: INT, info: MyType #];

The order of the fields in a record type is meaningful:
permuting the field names gives a different type.

Note that record types are non-recursive.
For instance, it is not possible to declare a record type called <code>Person</code> containing
a field of type <code>Person</code>.
Recursive types are provided in CVC4 by the more general inductive data types.
(As a matter of fact, both record and tuple types are implemented internally as inductive data types.)

==== Inductive Data Types ====

Inductive data types in CVC4 are similar to inductive data types of functional languages.
They can be parametric or not.

===== Non-Parametric Data Types =====

Non-parametric data types are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1 & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2 & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types, including any <math>A_i</math>.
Such declarations define the data types <math>A_1, \ldots, A_n</math>.
For each data type <math>A_i</math> they introduce:

* constructor symbols <math>cons</math> of type <math>(T_1, \ldots, T_k) \to \mathit{type\_name}_i</math>,
* selector symbols <math>\mathit{sel}_j</math> of type <math>\mathit{type\_name}_i \to T_j</math>, and
* tester symbols <math>\mathit{is\_cons}</math> of type <math>\mathit{type\_name}_i \to \mathrm{BOOLEAN}</math>.

Note that permitting more than one data type to be defined in the same declarations allows
the definition of mutually recursive types.

% simple enumeration type

% implicitly defined are the testers: is_red, is_yellow and is_blue
% (similarly for the other data types)

DATATYPE
PrimaryColor = red | yellow | blue
END;

% infinite set of pairwise distinct values ..., v(-1), v(0), v(1), ...

DATATYPE
Id = v (id: INT)
END;

% ML-style integer lists

DATATYPE
IntList = nil | ins (head: INT, tail: IntList)
END;

% AST for lamba calculus

DATATYPE
Term = var (index: INT)
| apply (arg_1: Term, arg_2: Term)
| lambda (arg: INT, body: Term)
END;

% Trees

DATATYPE
Tree = tree (value: REAL, children: TreeList),
TreeList = nil_tl
| ins_tl (first_t1: Tree, rest_t1: TreeList)
END;

Constructor, selector and tester symbols defined for a data type have global scope.
So, for example, it is not possible for two different data types to use
the same name for a constructor.

An inductive data type is interpreted as a term algebra constructed by the constructor symbols
over some sets of generators.
For example, the type <code>IntList</code> defined above is interpreted as the set
of all terms constructed with <code>nil</code> and <code>ins</code> over the integers.

===== Parametric Data Types =====

Parametric data types are infinite families of (non-parametric) data types
with each family parametrized by one or more type variables.
They are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1[X_{1,1}, \ldots, X_{1,p_1}] & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2[X_{2,1}, \ldots, X_{2,p_2}] & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n[X_{n,1}, \ldots, X_{n,p_n}] & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name parametrized by the type variables <math>X_{i,1}, \ldots, X_{i,p_i}</math>
and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types,
possibly parametrized by <math>X_1, \ldots, X_p</math>, including any <math>A_i</math>.

% Parametric pairs
DATATYPE
Pair[X, Y] = pair (first: X, second: Y)
END;

% Parametric lists

DATATYPE
List[X] = nil | cons (head: X, tail: List[X])
END;

% Parametric trees using the list type above

DATATYPE
Tree[X] = node (value: X, children: List[Tree[X]]),
END;

The declarations above define infinitely many types of the form
Pair[S,T], List[T] and Tree[T] where S and T are first-order types.
Note that the identifier <code>List</code> above, for example, by itself does not denote a type.
In contrast, the terms <code>List[Real]</code>, <code>List[List[Real]]</code>, <code>List[Tree[INT]]</code>,
and so on do.

===== Restriction to Inductive Types =====

By adopting a term algebra semantics, CVC4 allows only ''inductive'' data types,
that is, data types whose values are essentially (labeled, ordered) finite trees.
Infinite structures such as streams or even finite but cyclic ones
such as circular lists are then excluded.
For instance, none of the following declarations define inductive data types,
and are rejected by CVC4:

DATATYPE
IntStream = s (first:INT, rest: IntStream)
END;

DATATYPE
RationalTree = node1 (child: RationalTree)
| node2 (left_child: RationalTree, right_child:RationalTree)
END;

DATATYPE
T1 = c1 (s1: T2),
T2 = c2 (s2: T1)
END;

In concrete, a declaration of <math>n \geq 1</math> datatypes <math>T_1, \ldots, T_n</math> will be rejected if for any one of the types <math>T_1, \ldots, T_n</math>, it is impossible to build a finite term of that type using only the constructors of <math>T_1, \ldots, T_n</math> and free constants of type other than <math>T_1, \ldots, T_n</math>.

Inductive data types are the only types where the user also chooses names for the built-in operations to:

* construct a value of the type (with the constructors),
* extract components from a value (with the selectors), or
* check if a value was constructed with a certain constructor or not (with the testers).

For all the other types, CVC4 provides predefined names for the built-in operations on the type.

=== Function Types ===

Function (<math>\to</math>) types are created by the mixfix type constructors
<center>
<math>
\begin{array}{l}
\_ \to \_ \\[1ex] (\ \_\ ,\ \_\ ) \to \_
\\[1ex] (\ \_\ ,\ \_\ ,\ \_\ ) \to \_
\\[1ex] \ldots
\end{array}
</math>
</center>
whose arguments can be instantiated by any first-order type.

% Function type declarations

UnaryFunType: TYPE = INT -> REAL;

BinaryFunType: TYPE = (REAL, REAL) -> ARRAY REAL OF REAL;

TernaryFunType: TYPE = (REAL, BITVECTOR(4), INT) -> BOOLEAN;

A function type of the form <math>(T_1, \ldots, T_n) \to T</math> with <math>n > 0</math> is interpreted as the set of all ''total'' functions from the Cartesian product <math>T_1 \times \cdots \times T_n</math> to <math>T</math>.

The example above also shows how to introduce type names.
A name like <code>UnaryFunType</code> above is just an abbreviation for the type <math>\mathrm{INT} \to \mathrm{REAL}</math> and can be used interchangeably with it.

In general, any type defined by a type expression <code>E</code> can be given a name with the declaration:

name : TYPE = E;

=== Type Checking ===

In CVC4, formulas and terms are statically typed at the level of types
(as opposed to subtypes) according to the usual rules of first-order many-sorted logic,
with the main difference that formulas are just terms of type <math>BOOLEAN</math>:

* each variable has one associated first-order type,
* each constant symbol has one or more associated first-order types,
* each function symbol has one or more associated function types,
* the type of a term consisting just of a variable is the type associated to that variable,
* the type of a term consisting just of a constant symbol is the type associated to that constant symbol,
* the term obtained by applying a function symbol <math>f</math> to the terms <math>t_1, \ldots, t_n</math> is <math>T</math> if <math>f</math> has type <math>(T_1, \ldots, T_n) \to T</math> and each <math>t_i</math> has type <math>T_i</math>.

Attempting to enter an ill-typed term will result in an error.

Another significant difference with standard many-sorted logic is that
some built-in symbols are parametrically polymorphic.
For instance, the function symbol for extracting the element of any array has
type <math>(\mathit{ARRAY}\ T_1\ \mathit{OF}\ T_2,\; T_1) \to T_2</math>
for all first-order types <math>T_1, T_2</math>.

==== Type Ascription ====

By the type inference rules above some terms might have more than one type.
This can happen with terms built with polymorphic data type constructors
that have more than one return type for the same input type.
In that case, a type ascription operator (<code>::</code>) must be applied
to the constructor to specify the intended return type.

DATATYPE [X]
List[X] = nil | cons (head: X, tail: List[X])
END;

ASSERT y = cons(1, nil::List[REAL]);

DATATYPE [X, Y]
Union[X, Y] = left(val_l: X) | right(val_r: Y)
END;

ASSERT y = left::Union[BOOLEAN, REAL](TRUE);

The constant symbol <math>\mathrm{nil}</math> declared above has infinitely many types
(<math>\mathrm{List}[\mathrm{REAL}]</math>, <math>\mathrm{List}[\mathrm{BOOLEAN}]</math>,
<math>\mathrm{List}[[\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{List}[\mathrm{List}[\mathrm{REAL}]]</math>, ...)
CVC4's type checker requires the user to indicate explicitly the type
of each occurrence of <code>nil</code> in a term.
Similarly,
the injection operator <code>left</code> has infinitely many return types
for the same input type, for instance:
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{REAL}]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, [\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{List}[\mathrm{REAL}]]</math>,
and so on.
Applications of <code>left</code> need to specify the intended returned typed, as shown above.

== Terms and Formulas ==

In addition to type expressions, CVC4 has expressions for terms and for formulas
(i.e., terms of type <math>\mathrm{BOOLEAN}</math>).
By and large, these are standard first-order terms built out of typed variables,
predefined theory-specific operators, free (i.e., user-defined) function symbols,
and quantifiers.
Extensions include an if-then-else operator, lambda abstractions, and local symbol
declarations, as illustrated below.
Note that these extensions still keep CVC4's language first-order.
In particular, lambda abstractions are restricted to take and return only terms of
a first-order type.
Similarly, variables can only be of a first-order type.

A number of built-in function symbols (for instance, the arithmetic ones) are used
as infix operators. All user-defined symbols are used as prefix ones.

User-defined, i.e., free, function symbols include ''constant symbols'' and
''predicate symbols'', respectively nullary function symbols and function symbols
with a <math>\mathrm{BOOLEAN}</math> return type.
These symbols are introduced with global declarations of the form
<math> f_1, \ldots, f_m: T;</math>
where <math>m > 0</math>, <math>f_i</math> are the names of the symbols and
<math>T</math> is their type:

% integer constants

a, b, c: INT;

% real constants

x, y, z: REAL;

% unary function

f1: REAL -> REAL;

% binary function

f2: (REAL, INT) -> REAL;

% unary function with a tuple argument

f3: [INT, REAL] -> BOOLEAN;

% binary predicate

p: (INT, REAL) -> BOOLEAN;

% Propositional "variables"

P, Q; BOOLEAN;

Like type declarations, function symbol declarations like the above have global scope
and must be unique.
In other words, it is not possible to declare a function symbol globally more than once
in the same lexical scope.
This entails among other things that globally-defined free symbols cannot be overloaded
with different types and that theory symbols cannot be redeclared globally as free symbols.

=== Global symbol definitions ===

As with types, a function symbol can be defined as the name of another term
of the corresponding type.
With constant symbols, this is done with a declaration of the form <math>f:T = t;</math> :

c: INT;

i: INT = 5 + 3*c; % i is effectively a shorthand for 5 + 3*c

j: REAL = 3/4;

t: [REAL, INT] = (2/3, -4);

r: [# key: INT, value: REAL #] = (# key := 4, value := (c + 1)/2 #);

f: BOOLEAN = FORALL (x:INT): x <= 0 OR x > c ;

A restriction on constants of type <math>\mathit{BOOLEAN}</math> is that their value
can only be a closed formula, that is, a formula with no free variables.

A term and its name can be used interchangeably in later expressions.
Named terms are often useful for shared subterms (terms used several times in different places)
since their use can make the input exponentially more concise.
Named terms are processed very efficiently by CVC4.
It is much more efficient to associate a complex term with a name directly rather than
to declare a constant and later assert that it is equal to the same term.
This point is explained in more detail later in section [[Commands | Commands]].

More generally, in CVC4 one can associate a term to function symbols of any arity.
For non-constant function symbols this is done with a declaration of the form

<center>
<math>f:(T_1, \ldots, T_n) \to T = \mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t\;;</math>
</center>

where <math>t</math> is any term of type <math>T</math> with free variables
in <math>\{x_1, \ldots, x_n\}</math>.
The lambda binder has the usual semantics and conforms to the usual lexical scoping rules:
within the term <math>t</math> the declaration of the symbols <math>x_1, \ldots, x_n</math>
as local variables of respective type <math>T_1, \ldots, T_n</math> hides any previous
declarations of those symbols that are in scope.

As a general shorthand, when <math>k</math> consecutive types
<math>T_i, \ldots, T_{i+k-1}</math> in the lambda expression
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t</math> are identical, the syntax
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x_i,\ldots, x_{i+k-1}:T_i,\ldots, x:T_n): t</math>
can also be used.

% Global declaration of x as a unary function symbol

x: REAL -> REAL;

% Local declarations of x as variable (hiding the global one)

f: REAL -> REAL = LAMBDA (x: REAL): 2*x + 3;

p: (INT, INT) -> BOOLEAN = LAMBDA (x,i: INT): i*x - 1 > 0;

g: (REAL, INT) -> [REAL, INT] = LAMBDA (x: REAL, i:INT): (x + 1, i - 3);

Note that lambda definitions are not recursive:
the symbol being defined cannot occur in the body of the lambda term.
They should be understood as macros.
For instance, any occurrence of the term <math>f(t)</math>
where <math>f</math> is as defined above will be treated
as if it was the term <math>(2*t + 3)</math>.

=== Local symbol definitions ===

Constant and function symbols can also be declared locally anywhere within a term
by means of a let binder.
This is done with a declaration of the form

<center>
<math>
\mathrm{LET}\ f = s \ \mathrm{IN}\ t ;
</math>
</center>

where <math>t</math> is a term with no free variables, possibly a lambda term.
Let binders can be nested arbitrarily and follow the usual lexical scoping rules.
The following general form
<center>
<math>
\mathrm{LET}\ f_1 = t_1, f_2 = t_2, \ldots, f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>
can used as a shorthand for
<center>
<math>
\mathrm{LET}\ f_1 = t_1\ \mathrm{IN}\
\mathrm{LET}\ f_2 = t_2\ \mathrm{IN}\
\ldots \
\mathrm{LET}\ f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>

t: REAL =
LET x1 = 42,
g = LAMBDA(x:INT): x + 1,
x2 = 2*x1 + 7/2
IN
(LET x3 = g(x1) IN x3 + x2) / x1;

Note that the same symbol = is used, unambiguously, in the syntax of global declarations,
let declarations, and as a predicate symbol.

'''Note:'''
A <math>\mathrm{LET}</math> term with a multiple symbols defines them sequentially.
A parallel version of the <math>\mathrm{LET}</math> construct will be introduced in a later version.

== Built-in theories and their symbols ==

In addition to user-defined symbols, CVC4 terms can use a number of predefined symbols:
the logical symbols, such as <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, etc.,
as well as theory symbols, function symbols belonging to one of the built-in theories.
They are described next, with the theory symbols grouped by theory.

=== Logical Symbols ===

The logical symbols in CVC4's language include
the equality and disequality predicate symbols, respectively written as = and /=,
the multiarity disequality symbol <math>\mathrm{DISTINCT}</math>,
together with the logical constants <math>\mathrm{TRUE}</math>, <math>\mathrm{FALSE}</math>,
the connectives <math>\mathrm{NOT}</math>, <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, <math>\mathrm{XOR}</math>, <math>\Rightarrow</math>, <math>\Leftrightarrow</math>, and
the first-order quantifiers <math>\mathrm{EXISTS}</math> and <math>\mathrm{FORALL}</math>,
all with the standard many-sorted logic semantics.

The binary connectives have infix syntax and type
<math>(\mathrm{BOOLEAN},\mathrm{BOOLEAN}) \to \mathrm{BOOLEAN}</math>.
The symbols = and /=, which are also infix, are instead parametrically polymorphic,
having type <math>(T,T) \to \mathrm{BOOLEAN}</math>
for every first-order type <math>T</math>.
They are interpreted respectively as the identity relation and its complement.

The DISTINCT symbol is both overloaded and polymorphic.
It has type <math>(T,...,T) \to \mathrm{BOOLEAN}</math>
for every sequence <math>(T,...,T)</math> of length <math>n > 0</math>
and first-order type <math>T</math>.
For each <math>n > 0</math>, it is interpreted as the relation
that holds exactly for tuples of pairwise distinct elements.

The syntax for quantifiers is similar to that of the lambda binder.

Here is an example of a formula built just of these logical symbols and variables:

A, B: TYPE;

q: BOOLEAN = FORALL (x,y: A, i,j,k: B):
i = j AND i /= k => EXISTS (z: A): x /= z OR z /= y;

Binding and scoping of quantified variables follows the same rules as
in let expressions.
In particular, a quantifier will shadow in its scope any constant and function symbols
with the same name as one of the variables it quantifies:

A: TYPE;
i, j: INT;

% The first occurrence of i and of j in f are constant symbols,
% the others are variables.

f: BOOLEAN = i = j AND FORALL (i,j: A): i = j OR i /= j;

Optionally, it is also possible to specify instantiation patterns
for quantified variables.
The general syntax for a quantified formula <math>\psi</math> with patterns is

<center>
<math>
Q\;(x_1:T_1, \ldots, x_k:T_k):\; p_1: \ldots\; p_n:\; \varphi
</math>
</center>

where <math>n \geq 0</math>, <math>Q</math> is
either <math>\mathrm{FORALL}</math> or <math>\mathrm{EXISTS}</math>,
<math>\varphi</math> is a term of type <math>\mathrm{BOOLEAN}</math>,
and each of the <math>p_i</math>'s,
a pattern for the quantifier <math>Q\;(x_1:T_1, \ldots, x_k:T_k)</math>, has the form

<center>
<math>
\mathrm{PATTERN}\; (t_1, \ldots, t_m)
</math>
</center>

where <math>m > 0</math> and <math>t_1, \ldots, t_m</math> are
arbitrary binder-free terms (no lets, no quantifiers).
Those terms can contain (free) variables, typically, but not exclusively,
drawn from <math>x_1, \ldots, x_k</math>.
(Additional variables can occur if <math>\psi</math> occurs in a bigger formula
binding those variables.)

A: TYPE;
b, c: A;
p, q: A -> BOOLEAN;
r: (A, A) -> BOOLEAN;

ASSERT FORALL (x0, x1, x2: A):
PATTERN (r(x0, x1), r(x1, x2)):
(r(x0, x1) AND r(x1, x2)) => r(x0, x2) ;

ASSERT FORALL (x: A):
PATTERN (r(x, b)):
PATTERN (r(x, c)):
p(x) => q(x) ;

ASSERT EXISTS (y: A):
FORALL (x: A):
PATTERN (r(x, y), p(y)):
r(x, y) => q(x) ;

Patterns have no logical meaning:
adding them to a formula does not change its semantics.
Their purpose is purely operational, as explained in
the [[#Instantiation Patterns | Instantiation Patterns]] section.

In addition to these constructs, CVC4 also has a general mixfix conditional operator
of the form

<center>
<math>
\mathrm{IF}\ b\ \mathrm{THEN}\ t\ \mathrm{ELSIF}\ b_1\ \mathrm{THEN}\ t_1\ \ldots\ \mathrm{ELSIF}\ b_n\ \mathrm{THEN}\ t_n\ \mathrm{ELSE}\ t_{n+1}\ \mathrm{ENDIF}
</math>
</center>

with <math>n \geq 0</math> where
<math>b, b_1, \ldots, b_n</math> are terms of type <math>\mathrm{BOOLEAN}</math> and
<math>t, t_1, \ldots, t_n, t_{n+1}</math> are terms of the same first-order type <math>T</math>:

% Conditional term
x, y, z, w: REAL;

t: REAL =
IF x > 0 THEN y
ELSIF x >= 1 THEN z
ELSIF x > 2 THEN w
ELSE 2/3 ENDIF;

=== User-defined Functions and Types ===

The theory of user-defined functions,also know in the SMT literature as
the theory ''Equality over Uninterpreted Functions'', or ''EUF'', is in effect
a family of theories of equality parametrized by the basic types and the free symbols
a user can define during a run of CVC4.

This theory has no built-in symbols (other than the logical ones).
Its types consist of ''all and only'' the user-defined types.
Its function symbols consist of ''all and only'' the user-defined free symbols.

=== Arithmetic ===

The real arithmetic theory has two types:
<math>\mathrm{REAL}</math> and <math>\mathrm{INTEGER}</math>
with the latter a subtype of the first.
Its built-in symbols for the usual arithmetic constants
and operators over the type <math>\mathrm{REAL}</math>, each with the expected type:
all numerals 0, 1, ..., as well as - (both unary and binary), +, *, /, <, >, <=, >=.
Application of the binary symbols are in infix form.
Note that + is only binary, and so an expression such as +4 is ill-formed.

Rational values can be expressed in decimal or fractional format,
e.g., 0.1, 23.243241, 1/2, 3/4, and so on.
A leading 0 is mandatory for decimal numbers smaller than one
(e.g., the syntax .3 cannot be used as a shorthand for 0.3).
However, a trailing 0 is ''not'' required for decimals that are whole numbers
(e.g., 3. is allowed as a shorthand for 3.0).
The size of the numerals used in the representation of natural and rational numbers
is unbounded; more accurately, bounded only by the amount of available memory.

=== Bit vectors ===

=== Arrays ===

The theory of arrays is a parametric theory of (total) unary maps.
It comes equipped with mixfix polymorphic selection and update operators, respectively
<center>
<math>\_[\_]</math> and <math>\_\ \mathrm{WITH}\ [\_]\ := \_</math> .
</center>
The semantics of these operators is the expected one:
for all first-order types <math>T_1</math> and <math>T_2</math>,
if <math>a</math> is of type <math>\mathrm{ARRAY}\ T_1 \mathrm{OF}\ T_2</math>,
<math>i</math> is of type <math>T_1</math>, and
<math>v</math> is of type <math>T_2</math>,
* <math>a[i]</math> denotes the value that <math>a</math> associates to index <math>i</math>,
* <math>a\ \mathrm{WITH}\ [i]\ := v</math> denotes a map that associates <math>v</math> to index <math>i</math> and is otherwise identical to <math>a</math>.
Sequential updates can be chained with the shorthand syntax
<math>\_\ \mathrm{WITH}\ [\_]\ := \_, \ldots, [\_]\ := \_</math>.

A: TYPE = ARRAY INT OF REAL;
a: A;
i: INT = 4;

% selection:

elem: REAL = a[i];

% update

a1: A = a WITH [10] := 1/2;

% sequential update
% (syntactic sugar for (a WITH [10] := 2/3) WITH [42] := 3/2)

a2: A = a WITH [10] := 2/3, [42] := 3/2;

Since arrays are just maps, equality between them is extensional, that is,
for two arrays of the same type to be different they have to map at least one
index to differ values.

=== Data types ===

The theory of inductive data types is in fact a family of theories parametrized
by a data type declaration specifying constructors and selectors
for one or more user-defined data types.

No built-in operators other than equality and disequality are provided
for this family in the native language.
Each user-provided data type declaration, however, generates constructor, selector and tester operators
as described in the [[#Inductive Data Types | Inductive Data Types]] section.

=== Tuples and Records ===

Semantically both records and tuples can be seen as special instances
of inductive data types.
CVC4 implements them internally indeed as data types.
In essence, a record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math>
is encoded as a data type of the form

<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\ \ \mathrm{Record} = \mathit{rec}(l_0:T_0, \ldots, l_n:T_n) \\
\mathrm{END};
\end{array}
</math>
</center>

Tuples of length <math>n</math> are in turn special cases of records whose field names are
the numerals from <math>0</math> to <math>n-1</math>.

Externally, tuples and records have their own syntax for constructor and selector operators.
* Records of type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> have the associated record constructor <math>(\#\ l_0 := \_,\; \ldots,\; l_n := \_\ \#)</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.
* Tuples of type <math>[\ T_0, \ldots, T_n\ ]</math> have the associated tuple constructor <math>(\ \_,\; \ldots,\; \_\ )</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.

The selector operators on records and tuples follows a dot notation syntax.

% Record construction and field selection
Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);
k: INT = x.key;
v: REAL = x.weight;

% Tuple construction and projection
y: [REAL, INT, REAL] = ( 4/5, 9, 11/9 );
first_elem: REAL = y.0;
third_elem: REAL = y.2;

Differently from data types, records and tuples are also provided with built-in update operators similar in syntax and semantics to the update operator for arrays.
More precisely, for each record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .l_i\ := \_
</math>
</center>

The operator maps a record <math>r</math> of that type and a value <math>v</math>
of type <math>T_i</math> to the record that stores <math>v</math> in field <math>l_i</math>
and is otherwise identical to <math>r</math>.
Analogously, for each tuple type <math>[T_0, \ldots, T_n]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .i\ := \_
</math>
</center>

with similar semantics.

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = x WITH .weight := 48;

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = y WITH .1 := 3;

Updates to a nested component can be combined in a single WITH operator:

Cache: TYPE = ARRAY [0..100] OF [# addr: INT, data: REAL #];
State: TYPE = [# pc: INT, cache: Cache #];

s0: State;
s1: State = s0 WITH .cache[10].data := 2/3;

Note that, differently from updates on arrays, tuple and record updates are
just additional syntactic sugar.
For instance, the record <code>x1</code> and tuple <code>y1</code> defined above
could have been equivalently defined as follows:

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = (# key := x.key, weight := 48 #);

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = ( y.0, 3, y.1 );

== Commands ==

In addition to declarations of types and function symbols,
the CVC4 native language contains the following commands:

* <math>\mathrm{ASSERT}\ F</math> -- Add the formula <math>F</math> to the current logical context <math>\Gamma</math>.
* [[#CHECKSAT|<math>\mathrm{CHECKSAT}\ F</math>]] -- Check if the formula <math>F</math> is satisfiable in the current logical context (<math>\Gamma \not\models_T \mathrm{NOT}\ F</math>).
* <math>\mathrm{CONTINUE}</math> -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, search for a counter-example different from the current one.
* [[#COUNTEREXAMPLE|<math>\mathrm{COUNTEREXAMPLE}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print the context that is a witness for invalidity/satisfiability.
* [[#COUNTERMODEL|<math>\mathrm{COUNTERMODEL}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print a model that makes the formula invalid/satisfiable. The model is provided in terms of concrete values for each free symbol.
* <math>\mathrm{OPTION}\ o\ v</math> -- Set the command-line option flag <math>o</math> to value <math>v</math>. The argument <math>o</math> is provide as a string literal enclosed in double-quotes and <math>v</math> as an integer value.
* <math>\mathrm{POP}</math> -- Equivalent to <math>\mathrm{POPTO}\ 1</math>
* [[#POPTO|<math>\mathrm{POPTO}\ n</math>]] -- Restore the system to the state it was in right before the most recent call to <math>\mathrm{PUSH}</math> made from stack level <math>n</math>. Note that the current stack level is printed as part of the output of the <math>\mathrm{WHERE}</math> command.
* <math>\mathrm{PUSH}</math> -- Save (checkpoint) the current state of the system.
* [[#QUERY|<math>\mathrm{QUERY}\ F</math>]] -- Check if the formula <math>F</math> is valid in the current logical context (<math>\Gamma\models_T F</math>).
* [[#RESTART|<math>\mathrm{RESTART}\ F</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, repeat the check but with the additional assumption <math>F</math> in the context.
* <math>\mathrm{PRINT}\ t</math> -- Parse and print back the term <math>t</math>.
* <math>\mathrm{TRANSFORM}\ t</math> -- Simplify the term <math>t</math> and print the result.
* <math>\mathrm{WHERE}</math> -- Print all the formulas in the current logical context <math>\Gamma</math>.

The remaining commands take a single argument, given as a string literal enclosed in double-quotes.

* <math>\mathrm{ECHO}\ s</math> -- Print string <math>s</math>
* <math>\mathrm{INCLUDE}\ f</math> -- Read commands from file <math>f</math>.
* <math>\mathrm{TRACE}\ f</math> -- Turn on tracing for the debug flag <math>f</math>.
* <math>\mathrm{UNTRACE}\ f</math> -- Turn off tracing for the debug flag <math>f</math>.

Here, we explain some of the above commands in more detail.

=== QUERY ===

The command <math>\mathrm{QUERY}\ F</math> invokes the core functionality of CVC4 to check
the validity of the formula <math>F</math> with respect to the assertions made thus far,
which constitute the context <math>\Gamma</math>.
The argument <math>F</math> must be well typed term of type <math>\mathrm{BOOLEAN}</math>,
as described in [[#Terms and Formulas | Terms and Formulas]].

The execution of this command always terminates and produces one of three possible answers:
<code>valid</code>, <code>invalid</code>, and <code>unknown</code>.

* A <code>valid</code> answer indicates that <math>\Gamma \models_T F</math>. After a query returning such an answer, the logical context <math>\Gamma</math> is exactly as it was before the query.
* An <code>invalid</code> answer indicates that <math>\Gamma \not\models_T F</math>, that is, there is a model of the background theory <math>T</math> that satisfies <math>\Gamma \cup \{\mathrm{NOT}\ F\}</math>. When <math>\mathrm{QUERY}\ F</math> returns <code>invalid</code>, the logical context <math>\Gamma</math> is augmented with a set <math>\Delta</math> of ground (i.e., variable-free) literals such that <math>\Gamma\cup\Delta</math> is satisfiable in <math>T</math>, but <math>\Gamma\cup\Delta\models_T \mathrm{NOT}\ F</math>. In fact, in this case <math>\Delta</math> ''propositionally entails'' <math>\mathrm{NOT}\ F</math>, in the sense that, every truth assignment to the literals of <math>\Delta</math> that satisfies <math>\Delta</math> falsifies <math>F</math>. We call the new context <math>\Gamma\cup\Delta</math> a ''counterexample'' for <math>F</math>.
* An <code>unknown</code> answer is similar to an <code>invalid</code> answer in that additional literals are added to the context which propositionally entail <math>\mathrm{NOT}\ F</math>. The difference in this case is that CVC4 cannot guarantee that <math>\Gamma\cup\Delta</math> is actually satisfiable in <math>T</math>.

CVC4 may report <code>unknown</code> when the context or the query contains
non-linear arithmetic terms or quantifiers.
In all other cases, it is expected to be sound and complete,
i.e., to report <code>Valid</code> if <math>\Gamma \models_T F</math>
and <code>Invalid</code> otherwise.

After an <code>invalid</code> (resp. <code>unknown</code>) answer,
counterexamples (resp. possible counterexamples) can be obtained with
a <math>\mathrm{WHERE}</math>, <math>\mathrm{COUNTEREXAMPLE}</math>,
or <math>\mathrm{COUNTERMODEL}</math> command.


Since the <math>\mathrm{QUERY}</math> command may modify
the current context, if one needs to check several formulas in a row
in the same context, it is a good idea to surround every
query by a <math>\mathrm{PUSH}</math> and <math>\mathrm{POP}</math> invocation
in order to preserve the context:

PUSH;
QUERY <formula>;
POP;

=== CHECKSAT ===

The command <math>\mathrm{CHECKSAT}\ F</math> behaves identically
to <math>\mathrm{QUERY}\ \mathrm{NOT}\ F</math>.

=== RESTART ===

The command <math>\mathrm{RESTART}\ F</math> can only be invoked after an invalid query.
For example, in an interactive setting:

QUERY <formula>;

CVC4> invalid

RESTART <formula2>;

Functionally, the behavior of the above command sequence is identical to the following:

PUSH;
QUERY <formula>;
POP;
ASSERT <formula2>;
QUERY <formula>;

The advantage of using the <math>\mathrm{RESTART}</math> command is that
the first command sequence may be executed much more efficiently that the second.
The reason is that with <math>\mathrm{RESTART}</math> CVC4 will re-use
what it has learned while answering the previous query rather than starting
over from scratch.

=== COUNTERMODEL ===

[More]

=== COUNTEREXAMPLE ===

[More]

=== POPTO ===

[More]

== Instantiation Patterns ==

CVC4 processes each universally quantified formula in the current context
by adding instances of the formula obtained by replacing its universal variables
with ground terms.
Patterns restrict the choice of ground terms for the quantified variables,
with the goal of controlling the potential explosion of ground instances.
In essence, adding patterns to a formula is a way for the user to tell CVC4
to focus only on certain instances which, in the user's opinion, will be
most helpful during a proof.

In more detail, patterns have the following effect on formulas that are found
in the logical context or get added to it later while CVC4 is trying to prove
the validity of some formula <math>F</math>.

If a formula in the current context starts with an existential quantifier,
CVC4 ''Skolemizes'' it, that is, replaces it in the context with the formula
obtained by substituting the existentially quantified variables
by fresh constants and dropping the quantifier.
Any patterns for the existential quantifier are simply ignored.

If a formula starts with a universal quantifier
<math>\mathrm{FORALL}\; (x_1:T_1, \ldots, x_n:T_n)</math>,
CVC4 adds to the context a number of instances of the formula,
with the goal of using them to prove the query <math>F</math> valid.
An instance is obtained by replacing each <math>x_i</math> with a ground term
of the same type occurring in one of the formulas in the context,
and dropping the universal quantifier.
If <math>x_i</math> occurs in a pattern
<math>\mathrm{PATTERN}\; (t_1, \ldots, t_m)</math> for the quantifier,
it will be instantiated only with terms obtained by simultaneously matching
all the terms in the pattern against ground terms in the current context
<math>\Gamma</math>.

Specifically, the matching process produces one or more substitutions
<math>\sigma</math> for the variables in <math>(t_1, \ldots, t_m)</math>
which satisfy the following invariant:
for each <math>i = 1, \ldots, m</math>, <math>\sigma(t_i)</math> is
a ground term and there is a ground term <math>s_i</math> in <math>\Gamma</math>
such that <math>\Gamma \models_T \sigma(t_i) = s_i</math>.
The variables of <math>(x_1:T_1, \ldots, x_n:T_n)</math> that occur
in the pattern are instantiated only with those substitutions
(while any remaining variables are instantiated arbitrarily).

The Skolemized version or the added instances of a context formula may themselves
start with a quantifier.
The same instantiation process is applied to them too, recursively.

Note that the matching mechanism is not limited to syntactic matching
but is modulo the equations asserted in the context.
Because of decidability and/or efficiency limitations, the matching process
is not exhaustive.
CVC4 will typically miss some substitutions that satisfy the invariant above.
As a consequence, it might fail to prove the validity of the query formula
<math>F</math>, which makes CVC4 incomplete for contexts containing
quantified formulas.
It should be noted though that exhaustive matching, which can be achieved
simply by not specifying any patterns, does not yield completeness anyway
since the instantiation of universal variables is still restricted
to just the ground terms in the context,
whereas in general additional ground terms might be needed.

CVC4's native language

2012-11-30T23:19:02Z

Tinelli: /* Local symbol definitions */

= CVC4 native input language =

The native input language consists of a sequence of symbol declarations and commands, each followed by a semicolon (<code>;</code>).

Any text after the first occurrence of a percent character and to the end of the current line is a comment:

%%% This is a native language comment

== Type System ==

CVC4's type system includes a set of built-in types which can be expanded with additional user-defined types.

The type system consists of ''first-order'' types, ''subtypes'' of first-order types, and ''higher-order'' types, all of which are interpreted as sets.
For convenience, we will sometimes identify below the interpretation of a type with the type itself.

First-order types consist of basic types and structured types. The basic types are <math>\mathrm{BOOLEAN}</math>, <math>\mathrm{REAL}</math>, <math>\mathrm{BITVECTOR}(n)</math> for all <math>n > 0</math>, as well as user-defined basic types (also called uninterpreted types).
The structured types are array, tuple, record types, and ML-style user-defined (inductive) datatypes.

'''Note:''' Currently, subtypes consist only of the built-in subtype <math>\mathrm{INT}</math> of <math>\mathrm{REAL}</math>.

Support for CVC3-style user-defined subtypes will be added in a later release.

Function types are the only higher-order types.
More precisely, they are just second-order types
since function symbols in CVC4, both built-in and user-defined, can take as argument or return only values of
a first-order type.

=== Basic Types ===

==== The BOOLEAN Type ====

The <math>\mathrm{BOOLEAN}</math> type is interpreted as the two-element set of Boolean values
<math>\{\mathrm{TRUE},\; \mathrm{FALSE}\}</math>.

'''Note:''' CVC4's treatment of this type differs from CVC3's where <math>\mathrm{BOOLEAN}</math> is used only as the type of formulas, but not as value type. CVC3 follows the two-tiered structure of classical first-order logic
which distinguishes between formulas and terms, and allows terms to occur in formulas but not vice versa (with the exception of the IF-THEN-ELSE construct).
CVC4 drops the distinction between terms and formulas and defines the latter just as terms of type <math>\mathrm{BOOLEAN}</math>. As such, formulas can occur as subterms of possibly non-Boolean terms.

Example:

[To do]

==== The REAL Type ====

The <math>\mathrm{REAL}</math> type is interpreted as the set of real numbers.

Note that these are the (infinite precision) mathematical reals,
not the floating point numbers.
Support for floating point types is planned for future versions.

x, y : REAL;
QUERY (( x <= y ) AND ( y <= x )) => ( x = y );

==== The INT Type ====

The <math>\mathrm{INT}</math> type is interpreted as the set of integer numbers
and is considered as a subtype of <math>\mathrm{REAL}</math>.
The latter means in particular that it is possible to mix integer and real terms
in expressions without the need of an explicit ''upcasting'' operator.

Note that these are the (infinite precision) mathematical integers,
not the finite precision machine integers used in most programming languages.
The latter are models by [[ #Bitvectors | bit vector ]] types.

x, y : INT;
QUERY ((2 * x + 4 * y <= 1) AND ( y >= x)) => (x <= 0);
z : REAL;
QUERY (2 * x + z <= 3.5) AND (z >= 1);

==== Bit Vector Types ====

For every positive integer <math>n</math>, the type <math>\mathrm{BITVECTOR}(n)</math> is interpreted as the set of all bit vectors of size <math>n</math>.
A rich set of bit vector operators is supported.

==== User-defined Basic Types ====

Users can define new basic types
(often referred to as ''uninterpreted'' types in the SMT literature).
Each such type is interpreted as a set of unspecified cardinality
but disjoint from any other type.

User-defined basic types are created by declarations like the following:

% User declarations of basic types:

MyBrandNewType: TYPE;

Apples, Oranges: TYPE;

=== Structured Types ===

CVC4's structured types are divided in the following families.

==== Array Types ====

Array types are created by the mixfix type constructors <math>\mathrm{ARRAY}\ \_\ \mathrm{OF}\ \_</math>
whose arguments can be instantiated by any value type.

I : TYPE;

%% Array types:

% Arrays with indices from I and values from REAL
Array1: TYPE = ARRAY I OF REAL;

% Arrays with integer indices and array values
Array2: TYPE = ARRAY INT OF (ARRAY INT OF REAL);

% Arrays with integer pair indices and integer values
IntMatrix: TYPE = ARRAY [INT, INT] OF INT;

An array type of the form <math>\mathrm{ARRAY}\ T_1\ \mathrm{OF}\ T_2</math> is interpreted
as the set of all total maps from <math>T_1</math> to <math>T_2</math>.
The main difference with the function type <math>T_1 \to T_2</math> is that arrays,
contrary to functions, are first-class objects of the language, that is, values of an array
type can be arguments or results of functions.
Furthermore, array types come equipped with an update operation.

==== Tuple Types ====

Tuple types are created by the mixfix type constructors

<center>
<math>
\begin{array}{l} [\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ \ ,\ \_\ ] \\[1ex] \ldots \end{array}
</math>
</center>

whose arguments can be instantiated by any value type.

IntArray: TYPE = ARRAY INT OF INT;

% Tuple type declarations

RealPair: TYPE = [REAL, REAL]

MyTuple: TYPE = [ REAL, IntArray, [INT, INT] ];

A tuple type of the form <math>[T_1, \ldots, T_n]</math> is interpreted
as the Cartesian product <math>T_1 \times \cdots \times T_n</math>.

Note that while the types <math>(T_1, \ldots, T_n) \to T</math> and
<math>[T_1 \times \cdots \times T_n] \to T</math> are semantically equivalent,
they are operationally different in CVC4.
The first is the type of functions that take <math>n</math> arguments
of respective type <math>T_1</math>, <math>\ldots</math>, <math>T_n</math>,
while the second is the type of functions that take one argument of an <math>n</math>-tuple type.

==== Record Types ====

Similar to, but more general than tuple types, record types are created by type constructors of the form

<center>
<math>
[\#\ l_1: \_\ ,\ \ldots\ ,\ l_n: \_\ \#]
</math>
</center>

where <math>n > 0</math>, <math>l_1,\ldots, l_n</math> are field labels,
and the arguments can be instantiated with any first-order types.

MyType: TYPE;

% Record declaration

RecordType: TYPE = [# id: REAL, age: INT, info: MyType #];

The order of the fields in a record type is meaningful:
permuting the field names gives a different type.

Note that record types are non-recursive.
For instance, it is not possible to declare a record type called <code>Person</code> containing
a field of type <code>Person</code>.
Recursive types are provided in CVC4 by the more general inductive data types.
(As a matter of fact, both record and tuple types are implemented internally as inductive data types.)

==== Inductive Data Types ====

Inductive data types in CVC4 are similar to inductive data types of functional languages.
They can be parametric or not.

===== Non-Parametric Data Types =====

Non-parametric data types are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1 & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2 & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types, including any <math>A_i</math>.
Such declarations define the data types <math>A_1, \ldots, A_n</math>.
For each data type <math>A_i</math> they introduce:

* constructor symbols <math>cons</math> of type <math>(T_1, \ldots, T_k) \to \mathit{type\_name}_i</math>,
* selector symbols <math>\mathit{sel}_j</math> of type <math>\mathit{type\_name}_i \to T_j</math>, and
* tester symbols <math>\mathit{is\_cons}</math> of type <math>\mathit{type\_name}_i \to \mathrm{BOOLEAN}</math>.

Note that permitting more than one data type to be defined in the same declarations allows
the definition of mutually recursive types.

% simple enumeration type

% implicitly defined are the testers: is_red, is_yellow and is_blue
% (similarly for the other data types)

DATATYPE
PrimaryColor = red | yellow | blue
END;

% infinite set of pairwise distinct values ..., v(-1), v(0), v(1), ...

DATATYPE
Id = v (id: INT)
END;

% ML-style integer lists

DATATYPE
IntList = nil | ins (head: INT, tail: IntList)
END;

% AST for lamba calculus

DATATYPE
Term = var (index: INT)
| apply (arg_1: Term, arg_2: Term)
| lambda (arg: INT, body: Term)
END;

% Trees

DATATYPE
Tree = tree (value: REAL, children: TreeList),
TreeList = nil_tl
| ins_tl (first_t1: Tree, rest_t1: TreeList)
END;

Constructor, selector and tester symbols defined for a data type have global scope.
So, for example, it is not possible for two different data types to use
the same name for a constructor.

An inductive data type is interpreted as a term algebra constructed by the constructor symbols
over some sets of generators.
For example, the type <code>IntList</code> defined above is interpreted as the set
of all terms constructed with <code>nil</code> and <code>ins</code> over the integers.

===== Parametric Data Types =====

Parametric data types are infinite families of (non-parametric) data types
with each family parametrized by one or more type variables.
They are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1[X_{1,1}, \ldots, X_{1,p_1}] & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2[X_{2,1}, \ldots, X_{2,p_2}] & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n[X_{n,1}, \ldots, X_{n,p_n}] & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name parametrized by the type variables <math>X_{i,1}, \ldots, X_{i,p_i}</math>
and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types,
possibly parametrized by <math>X_1, \ldots, X_p</math>, including any <math>A_i</math>.

% Parametric pairs
DATATYPE
Pair[X, Y] = pair (first: X, second: Y)
END;

% Parametric lists

DATATYPE
List[X] = nil | cons (head: X, tail: List[X])
END;

% Parametric trees using the list type above

DATATYPE
Tree[X] = node (value: X, children: List[Tree[X]]),
END;

The declarations above define infinitely many types of the form
Pair[S,T], List[T] and Tree[T] where S and T are first-order types.
Note that the identifier <code>List</code> above, for example, by itself does not denote a type.
In contrast, the terms <code>List[Real]</code>, <code>List[List[Real]]</code>, <code>List[Tree[INT]]</code>,
and so on do.

===== Restriction to Inductive Types =====

By adopting a term algebra semantics, CVC4 allows only ''inductive'' data types,
that is, data types whose values are essentially (labeled, ordered) finite trees.
Infinite structures such as streams or even finite but cyclic ones
such as circular lists are then excluded.
For instance, none of the following declarations define inductive data types,
and are rejected by CVC4:

DATATYPE
IntStream = s (first:INT, rest: IntStream)
END;

DATATYPE
RationalTree = node1 (child: RationalTree)
| node2 (left_child: RationalTree, right_child:RationalTree)
END;

DATATYPE
T1 = c1 (s1: T2),
T2 = c2 (s2: T1)
END;

In concrete, a declaration of <math>n \geq 1</math> datatypes <math>T_1, \ldots, T_n</math> will be rejected if for any one of the types <math>T_1, \ldots, T_n</math>, it is impossible to build a finite term of that type using only the constructors of <math>T_1, \ldots, T_n</math> and free constants of type other than <math>T_1, \ldots, T_n</math>.

Inductive data types are the only types where the user also chooses names for the built-in operations to:

* construct a value of the type (with the constructors),
* extract components from a value (with the selectors), or
* check if a value was constructed with a certain constructor or not (with the testers).

For all the other types, CVC4 provides predefined names for the built-in operations on the type.

=== Function Types ===

Function (<math>\to</math>) types are created by the mixfix type constructors
<center>
<math>
\begin{array}{l}
\_ \to \_ \\[1ex] (\ \_\ ,\ \_\ ) \to \_
\\[1ex] (\ \_\ ,\ \_\ ,\ \_\ ) \to \_
\\[1ex] \ldots
\end{array}
</math>
</center>
whose arguments can be instantiated by any first-order type.

% Function type declarations

UnaryFunType: TYPE = INT -> REAL;

BinaryFunType: TYPE = (REAL, REAL) -> ARRAY REAL OF REAL;

TernaryFunType: TYPE = (REAL, BITVECTOR(4), INT) -> BOOLEAN;

A function type of the form <math>(T_1, \ldots, T_n) \to T</math> with <math>n > 0</math> is interpreted as the set of all ''total'' functions from the Cartesian product <math>T_1 \times \cdots \times T_n</math> to <math>T</math>.

The example above also shows how to introduce type names.
A name like <code>UnaryFunType</code> above is just an abbreviation for the type <math>\mathrm{INT} \to \mathrm{REAL}</math> and can be used interchangeably with it.

In general, any type defined by a type expression <code>E</code> can be given a name with the declaration:

name : TYPE = E;

=== Type Checking ===

In CVC4, formulas and terms are statically typed at the level of types
(as opposed to subtypes) according to the usual rules of first-order many-sorted logic,
with the main difference that formulas are just terms of type <math>BOOLEAN</math>:

* each variable has one associated first-order type,
* each constant symbol has one or more associated first-order types,
* each function symbol has one or more associated function types,
* the type of a term consisting just of a variable is the type associated to that variable,
* the type of a term consisting just of a constant symbol is the type associated to that constant symbol,
* the term obtained by applying a function symbol <math>f</math> to the terms <math>t_1, \ldots, t_n</math> is <math>T</math> if <math>f</math> has type <math>(T_1, \ldots, T_n) \to T</math> and each <math>t_i</math> has type <math>T_i</math>.

Attempting to enter an ill-typed term will result in an error.

Another significant difference with standard many-sorted logic is that
some built-in symbols are parametrically polymorphic.
For instance, the function symbol for extracting the element of any array has
type <math>(\mathit{ARRAY}\ T_1\ \mathit{OF}\ T_2,\; T_1) \to T_2</math>
for all first-order types <math>T_1, T_2</math>.

==== Type Ascription ====

By the type inference rules above some terms might have more than one type.
This can happen with terms built with polymorphic data type constructors
that have more than one return type for the same input type.
In that case, a type ascription operator (<code>::</code>) must be applied
to the constructor to specify the intended return type.

DATATYPE [X]
List[X] = nil | cons (head: X, tail: List[X])
END;

ASSERT y = cons(1, nil::List[REAL]);

DATATYPE [X, Y]
Union[X, Y] = left(val_l: X) | right(val_r: Y)
END;

ASSERT y = left::Union[BOOLEAN, REAL](TRUE);

The constant symbol <math>\mathrm{nil}</math> declared above has infinitely many types
(<math>\mathrm{List}[\mathrm{REAL}]</math>, <math>\mathrm{List}[\mathrm{BOOLEAN}]</math>,
<math>\mathrm{List}[[\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{List}[\mathrm{List}[\mathrm{REAL}]]</math>, ...)
CVC4's type checker requires the user to indicate explicitly the type
of each occurrence of <code>nil</code> in a term.
Similarly,
the injection operator <code>left</code> has infinitely many return types
for the same input type, for instance:
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{REAL}]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, [\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{List}[\mathrm{REAL}]]</math>,
and so on.
Applications of <code>left</code> need to specify the intended returned typed, as shown above.

== Terms and Formulas ==

In addition to type expressions, CVC4 has expressions for terms and for formulas
(i.e., terms of type <math>\mathrm{BOOLEAN}</math>).
By and large, these are standard first-order terms built out of typed variables,
predefined theory-specific operators, free (i.e., user-defined) function symbols,
and quantifiers.
Extensions include an if-then-else operator, lambda abstractions, and local symbol
declarations, as illustrated below.
Note that these extensions still keep CVC4's language first-order.
In particular, lambda abstractions are restricted to take and return only terms of
a first-order type.
Similarly, variables can only be of a first-order type.

A number of built-in function symbols (for instance, the arithmetic ones) are used
as infix operators. All user-defined symbols are used as prefix ones.

User-defined, i.e., free, function symbols include ''constant symbols'' and
''predicate symbols'', respectively nullary function symbols and function symbols
with a <math>\mathrm{BOOLEAN}</math> return type.
These symbols are introduced with global declarations of the form
<math> f_1, \ldots, f_m: T;</math>
where <math>m > 0</math>, <math>f_i</math> are the names of the symbols and
<math>T</math> is their type:

% integer constants

a, b, c: INT;

% real constants

x, y, z: REAL;

% unary function

f1: REAL -> REAL;

% binary function

f2: (REAL, INT) -> REAL;

% unary function with a tuple argument

f3: [INT, REAL] -> BOOLEAN;

% binary predicate

p: (INT, REAL) -> BOOLEAN;

% Propositional "variables"

P, Q; BOOLEAN;

Like type declarations, function symbol declarations like the above have global scope
and must be unique.
In other words, it is not possible to declare a function symbol globally more than once
in the same lexical scope.
This entails among other things that globally-defined free symbols cannot be overloaded
with different types and that theory symbols cannot be redeclared globally as free symbols.

=== Global symbol definitions ===

As with types, a function symbol can be defined as the name of another term
of the corresponding type.
With constant symbols, this is done with a declaration of the form <math>f:T = t;</math> :

c: INT;

i: INT = 5 + 3*c; % i is effectively a shorthand for 5 + 3*c

j: REAL = 3/4;

t: [REAL, INT] = (2/3, -4);

r: [# key: INT, value: REAL #] = (# key := 4, value := (c + 1)/2 #);

f: BOOLEAN = FORALL (x:INT): x <= 0 OR x > c ;

A restriction on constants of type <math>\mathit{BOOLEAN}</math> is that their value
can only be a closed formula, that is, a formula with no free variables.

A term and its name can be used interchangeably in later expressions.
Named terms are often useful for shared subterms (terms used several times in different places)
since their use can make the input exponentially more concise.
Named terms are processed very efficiently by CVC4.
It is much more efficient to associate a complex term with a name directly rather than
to declare a constant and later assert that it is equal to the same term.
This point is explained in more detail later in section [[Commands | Commands]].

More generally, in CVC4 one can associate a term to function symbols of any arity.
For non-constant function symbols this is done with a declaration of the form

<center>
<math>f:(T_1, \ldots, T_n) \to T = \mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t\;;</math>
</center>

where <math>t</math> is any term of type <math>T</math> with free variables
in <math>\{x_1, \ldots, x_n\}</math>.
The lambda binder has the usual semantics and conforms to the usual lexical scoping rules:
within the term <math>t</math> the declaration of the symbols <math>x_1, \ldots, x_n</math>
as local variables of respective type <math>T_1, \ldots, T_n</math> hides any previous
declarations of those symbols that are in scope.

As a general shorthand, when <math>k</math> consecutive types
<math>T_i, \ldots, T_{i+k-1}</math> in the lambda expression
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t</math> are identical, the syntax
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x_i,\ldots, x_{i+k-1}:T_i,\ldots, x:T_n): t</math>
can also be used.

% Global declaration of x as a unary function symbol

x: REAL -> REAL;

% Local declarations of x as variable (hiding the global one)

f: REAL -> REAL = LAMBDA (x: REAL): 2*x + 3;

p: (INT, INT) -> BOOLEAN = LAMBDA (x,i: INT): i*x - 1 > 0;

g: (REAL, INT) -> [REAL, INT] = LAMBDA (x: REAL, i:INT): (x + 1, i - 3);

Note that lambda definitions are not recursive:
the symbol being defined cannot occur in the body of the lambda term.
They should be understood as macros.
For instance, any occurrence of the term <math>f(t)</math>
where <math>f</math> is as defined above will be treated
as if it was the term <math>(2*t + 3)</math>.

=== Local symbol definitions ===

Constant and function symbols can also be declared locally anywhere within a term
by means of a let binder.
This is done with a declaration of the form

<center>
<math>
\mathrm{LET}\ f = s \ \mathrm{IN}\ t ;
</math>
</center>

where <math>t</math> is a term with no free variables, possibly a lambda term.
Let binders can be nested arbitrarily and follow the usual lexical scoping rules.
The following general form
<center>
<math>
\mathrm{LET}\ f_1 = t_1, f_2 = t_2, \ldots, f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>
can used as a shorthand for
<center>
<math>
\mathrm{LET}\ f_1 = t_1\ \mathrm{IN}\
\mathrm{LET}\ f_2 = t_2\ \mathrm{IN}\
\ldots \
\mathrm{LET}\ f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>

t: REAL =
LET x1 = 42,
g = LAMBDA(x:INT): x + 1,
x2 = 2*x1 + 7/2
IN
(LET x3 = g(x1) IN x3 + x2) / x1;

Note that the same symbol = is used, unambiguously, in the syntax of global declarations,
let declarations, and as a predicate symbol.

'''Note:'''
A <math>\mathrm{LET}</math> term with a multiple symbols defines them sequentially.
A parallel version of the <math>\mathrm{LET}</math> construct will be introduced in a later version.

== Built-in theories and their symbols ==

In addition to user-defined symbols, CVC4 terms can use a number of predefined symbols:
the logical symbols, such as <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, etc.,
as well as theory symbols, function symbols belonging to one of the built-in theories.
They are described next, with the theory symbols grouped by theory.

=== Logical Symbols ===

The logical symbols in CVC4's language include
the equality and disequality predicate symbols, respectively written as = and /=,
the multiarity disequality symbol <math>\mathrm{DISTINCT}</math>,
together with the logical constants <math>\mathrm{TRUE}</math>, <math>\mathrm{FALSE}</math>,
the connectives <math>\mathrm{NOT}</math>, <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, <math>\mathrm{XOR}</math>, <math>\Rightarrow</math>, <math>\Leftrightarrow</math>, and
the first-order quantifiers <math>\mathrm{EXISTS}</math> and <math>\mathrm{FORALL}</math>,
all with the standard many-sorted logic semantics.

The binary connectives have infix syntax and type
<math>(\mathrm{BOOLEAN},\mathrm{BOOLEAN}) \to \mathrm{BOOLEAN}</math>.
The symbols = and /=, which are also infix, are instead parametrically polymorphic,
having type <math>(T,T) \to \mathrm{BOOLEAN}</math>
for every first-order type <math>T</math>.
They are interpreted respectively as the identity relation and its complement.

The DISTINCT symbol is both overloaded and polymorphic.
It has type <math>(T,...,T) \to \mathrm{BOOLEAN}</math>
for every sequence <math>(T,...,T)</math> of length <math>n > 0</math>
and first-order type <math>T</math>.
For each <math>n > 0</math>, it is interpreted as the relation
that holds exactly for tuples of pairwise distinct elements.

The syntax for quantifiers is similar to that of the lambda binder.

Here is an example of a formula built just of these logical symbols and variables:

A, B: TYPE;

q: BOOLEAN = FORALL (x,y: A, i,j,k: B):
i = j AND i /= k => EXISTS (z: A): x /= z OR z /= y;

Binding and scoping of quantified variables follows the same rules as
in let expressions.
In particular, a quantifier will shadow in its scope any constant and function symbols
with the same name as one of the variables it quantifies:

A: TYPE;
i, j: INT;

% The first occurrence of i and of j in f are constant symbols,
% the others are variables.

f: BOOLEAN = i = j AND FORALL (i,j: A): i = j OR i /= j;

Optionally, it is also possible to specify instantiation patterns
for quantified variables.
The general syntax for a quantified formula <math>\psi</math> with patterns is

<center>
<math>
Q\;(x_1:T_1, \ldots, x_k:T_k):\; p_1: \ldots\; p_n:\; \varphi
</math>
</center>

where <math>n \geq 0</math>, <math>Q</math> is
either <math>\mathrm{FORALL}</math> or <math>\mathrm{EXISTS}</math>,
<math>\varphi</math> is a term of type <math>\mathrm{BOOLEAN}</math>,
and each of the <math>p_i</math>'s,
a pattern for the quantifier <math>Q\;(x_1:T_1, \ldots, x_k:T_k)</math>, has the form

<center>
<math>
\mathrm{PATTERN}\; (t_1, \ldots, t_m)
</math>
</center>

where <math>m > 0</math> and <math>t_1, \ldots, t_m</math> are
arbitrary binder-free terms (no lets, no quantifiers).
Those terms can contain (free) variables, typically, but not exclusively,
drawn from <math>x_1, \ldots, x_k</math>.
(Additional variables can occur if <math>\psi</math> occurs in a bigger formula
binding those variables.)

A: TYPE;
b, c: A;
p, q: A -> BOOLEAN;
r: (A, A) -> BOOLEAN;

ASSERT FORALL (x0, x1, x2: A):
PATTERN (r(x0, x1), r(x1, x2)):
(r(x0, x1) AND r(x1, x2)) => r(x0, x2) ;

ASSERT FORALL (x: A):
PATTERN (r(x, b)):
PATTERN (r(x, c)):
p(x) => q(x) ;

ASSERT EXISTS (y: A):
FORALL (x: A):
PATTERN (r(x, y), p(y)):
r(x, y) => q(x) ;

Patterns have no logical meaning:
adding them to a formula does not change its semantics.
Their purpose is purely operational, as explained in
the [[#Instantiation Patterns | Instantiation Patterns]] section.

In addition to these constructs, CVC4 also has a general mixfix conditional operator
of the form

<center>
<math>
\mathrm{IF}\ b\ \mathrm{THEN}\ t\ \mathrm{ELSIF}\ b_1\ \mathrm{THEN}\ t_1\ \ldots\ \mathrm{ELSIF}\ b_n\ \mathrm{THEN}\ t_n\ \mathrm{ELSE}\ t_{n+1}\ \mathrm{ENDIF}
</math>
</center>

with <math>n \geq 0</math> where
<math>b, b_1, \ldots, b_n</math> are terms of type <math>\mathrm{BOOLEAN}</math> and
<math>t, t_1, \ldots, t_n, t_{n+1}</math> are terms of the same first-order type <math>T</math>:

% Conditional term
x, y, z, w: REAL;

t: REAL =
IF x > 0 THEN y
ELSIF x >= 1 THEN z
ELSIF x > 2 THEN w
ELSE 2/3 ENDIF;

=== User-defined Functions and Types ===

The theory of user-defined functions,also know in the SMT literature as
the theory ''Equality over Uninterpreted Functions'', or ''EUF'', is in effect
a family of theories of equality parametrized by the basic types and the free symbols
a user can define during a run of CVC4.

This theory has no built-in symbols (other than the logical ones).
Its types consist of ''all and only'' the user-defined types.
Its function symbols consist of ''all and only'' the user-defined free symbols.

=== Arithmetic ===

The real arithmetic theory has two types:
<math>\mathrm{REAL}</math> and <math>\mathrm{INTEGER}</math>
with the latter a subtype of the first.
Its built-in symbols for the usual arithmetic constants
and operators over the type <math>\mathrm{REAL}</math>, each with the expected type:
all numerals 0, 1, ..., as well as - (both unary and binary), +, *, /, <, >, <=, >=.
Application of the binary symbols are in infix form.
Note that + is only binary, and so an expression such as +4 is ill-formed.

Rational values can be expressed in decimal or fractional format,
e.g., 0.1, 23.243241, 1/2, 3/4, and so on.
A leading 0 is mandatory for decimal numbers smaller than one
(e.g., the syntax .3 cannot be used as a shorthand for 0.3).
However, a trailing 0 is ''not'' required for decimals that are whole numbers
(e.g., 3. is allowed as a shorthand for 3.0).
The size of the numerals used in the representation of natural and rational numbers
is unbounded; more accurately, bounded only by the amount of available memory.

=== Bit vectors ===

=== Arrays ===

The theory of arrays is a parametric theory of (total) unary maps.
It comes equipped with mixfix polymorphic selection and update operators, respectively
<center>
<math>\_[\_]</math> and <math>\_\ \mathrm{WITH}\ [\_]\ := \_</math> .
</center>
The semantics of these operators is the expected one:
for all first-order types <math>T_1</math> and <math>T_2</math>,
if <math>a</math> is of type <math>\mathrm{ARRAY}\ T_1 \mathrm{OF}\ T_2</math>,
<math>i</math> is of type <math>T_1</math>, and
<math>v</math> is of type <math>T_2</math>,
* <math>a[i]</math> denotes the value that <math>a</math> associates to index <math>i</math>,
* <math>a\ \mathrm{WITH}\ [i]\ := v</math> denotes a map that associates <math>v</math> to index <math>i</math> and is otherwise identical to <math>a</math>.
Sequential updates can be chained with the shorthand syntax
<math>\_\ \mathrm{WITH}\ [\_]\ := \_, \ldots, [\_]\ := \_</math>.

A: TYPE = ARRAY INT OF REAL;
a: A;
i: INT = 4;

% selection:

elem: REAL = a[i];

% update

a1: A = a WITH [10] := 1/2;

% sequential update
% (syntactic sugar for (a WITH [10] := 2/3) WITH [42] := 3/2)

a2: A = a WITH [10] := 2/3, [42] := 3/2;

Since arrays are just maps, equality between them is extensional, that is,
for two arrays of the same type to be different they have to map at least one
index to differ values.

=== Data types ===

The theory of inductive data types is in fact a family of theories parametrized
by a data type declaration specifying constructors and selectors
for one or more user-defined data types.

No built-in operators other than equality and disequality are provided
for this family in the native language.
Each user-provided data type declaration, however, generates constructor, selector and tester operators
as described in the [[#Inductive Data Types | Inductive Data Types]] section.

=== Tuples and Records ===

Semantically both records and tuples can be seen as special instances
of inductive data types.
CVC4 implements them internally indeed as data types.
In essence, a record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math>
is encoded as a data type of the form

<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\ \ \mathrm{Record} = \mathit{rec}(l_0:T_0, \ldots, l_n:T_n) \\
\mathrm{END};
\end{array}
</math>
</center>

Tuples of length <math>n</math> are in turn special cases of records whose field names are
the numerals from <math>0</math> to <math>n-1</math>.

Externally, tuples and records have their own syntax for constructor and selector operators.
* Records of type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> have the associated record constructor <math>(\#\ l_0 := \_,\; \ldots,\; l_n := \_\ \#)</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.
* Tuples of type <math>[\ T_0, \ldots, T_n\ ]</math> have the associated tuple constructor <math>(\ \_,\; \ldots,\; \_\ )</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.

The selector operators on records and tuples follows a dot notation syntax.

% Record construction and field selection
Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);
k: INT = x.key;
v: REAL = x.weight;

% Tuple construction and projection
y: [REAL, INT, REAL] = ( 4/5, 9, 11/9 );
first_elem: REAL = y.0;
third_elem: REAL = y.2;

Differently from data types, records and tuples are also provided with built-in update operators similar in syntax and semantics to the update operator for arrays.
More precisely, for each record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .l_i\ := \_
</math>
</center>

The operator maps a record <math>r</math> of that type and a value <math>v</math>
of type <math>T_i</math> to the record that stores <math>v</math> in field <math>l_i</math>
and is otherwise identical to <math>r</math>.
Analogously, for each tuple type <math>[T_0, \ldots, T_n]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .i\ := \_
</math>
</center>

with similar semantics.

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = x WITH .weight := 48;

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = y WITH .1 := 3;

Updates to a nested component can be combined in a single WITH operator:

Cache: TYPE = ARRAY [0..100] OF [# addr: INT, data: REAL #];
State: TYPE = [# pc: INT, cache: Cache #];

s0: State;
s1: State = s0 WITH .cache[10].data := 2/3;

Note that, differently from updates on arrays, tuple and record updates are
just additional syntactic sugar.
For instance, the record <code>x1</code> and tuple <code>y1</code> defined above
could have been equivalently defined as follows:

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = (# key := x.key, weight := 48 #);

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = ( y.0, 3, y.1 );

== Commands ==

In addition to declarations of types and function symbols,
the CVC4 native language contains the following commands:

* <math>\mathrm{ASSERT}\ F</math> -- Add the formula <math>F</math> to the current logical context <math>\Gamma</math>.
* [[#CHECKSAT|<math>\mathrm{CHECKSAT}\ F</math>]] -- Check if the formula <math>F</math> is satisfiable in the current logical context (<math>\Gamma \not\models_T \mathrm{NOT}\ F</math>).
* <math>\mathrm{CONTINUE}</math> -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, search for a counter-example different from the current one.
* [[#COUNTEREXAMPLE|<math>\mathrm{COUNTEREXAMPLE}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print the context that is a witness for invalidity/satisfiability.
* [[#COUNTERMODEL|<math>\mathrm{COUNTERMODEL}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print a model that makes the formula invalid/satisfiable. The model is provided in terms of concrete values for each free symbol.
* <math>\mathrm{OPTION}\ o\ v</math> -- Set the command-line option flag <math>o</math> to value <math>v</math>. The argument <math>o</math> is provide as a string literal enclosed in double-quotes and <math>v</math> as an integer value.
* <math>\mathrm{POP}</math> -- Equivalent to <math>\mathrm{POPTO}\ 1</math>
* [[#POPTO|<math>\mathrm{POPTO}\ n</math>]] -- Restore the system to the state it was in right before the most recent call to <math>\mathrm{PUSH}</math> made from stack level <math>n</math>. Note that the current stack level is printed as part of the output of the <math>\mathrm{WHERE}</math> command.
* <math>\mathrm{PUSH}</math> -- Save (checkpoint) the current state of the system.
* [[#QUERY|<math>\mathrm{QUERY}\ F</math>]] -- Check if the formula <math>F</math> is valid in the current logical context (<math>\Gamma\models_T F</math>).
* [[#RESTART|<math>\mathrm{RESTART}\ F</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, repeat the check but with the additional assumption <math>F</math> in the context.
* <math>\mathrm{PRINT}\ t</math> -- Parse and print back the term <math>t</math>.
* <math>\mathrm{TRANSFORM}\ t</math> -- Simplify the term <math>t</math> and print the result.
* <math>\mathrm{WHERE}</math> -- Print all the formulas in the current logical context <math>\Gamma</math>.

The remaining commands take a single argument, given as a string literal enclosed in double-quotes.

* <math>\mathrm{ECHO}\ s</math> -- Print string <math>s</math>
* <math>\mathrm{INCLUDE}\ f</math> -- Read commands from file <math>f</math>.
* <math>\mathrm{TRACE}\ f</math> -- Turn on tracing for the debug flag <math>f</math>.
* <math>\mathrm{UNTRACE}\ f</math> -- Turn off tracing for the debug flag <math>f</math>.

Here, we explain some of the above commands in more detail.

=== QUERY ===

The command <math>\mathrm{QUERY}\ F</math> invokes the core functionality of CVC4 to check
the validity of the formula <math>F</math> with respect to the assertions made thus far,
which constitute the context <math>\Gamma</math>.
The argument <math>F</math> must be well typed term of type <math>\mathrm{BOOLEAN}</math>,
as described in [[#Terms and Formulas | Terms and Formulas]].

The execution of this command always terminates and produces one of three possible answers:
<code>valid</code>, <code>invalid</code>, and <code>unknown</code>.

* A <code>valid</code> answer indicates that <math>\Gamma \models_T F</math>. After a query returning such an answer, the logical context <math>\Gamma</math> is exactly as it was before the query.
* An <code>invalid</code> answer indicates that <math>\Gamma \not\models_T F</math>, that is, there is a model of the background theory <math>T</math> that satisfies <math>\Gamma \cup \{\mathrm{NOT}\ F\}</math>. When <math>\mathrm{QUERY}\ F</math> returns <code>invalid</code>, the logical context <math>\Gamma</math> is augmented with a set <math>\Delta</math> of ground (i.e., variable-free) literals such that <math>\Gamma\cup\Delta</math> is satisfiable in <math>T</math>, but <math>\Gamma\cup\Delta\models_T \mathrm{NOT}\ F</math>. In fact, in this case <math>\Delta</math> ''propositionally entails'' <math>\mathrm{NOT}\ F</math>, in the sense that, every truth assignment to the literals of <math>\Delta</math> that satisfies <math>\Delta</math> falsifies <math>F</math>. We call the new context <math>\Gamma\cup\Delta</math> a ''counterexample'' for <math>F</math>.
* An <code>unknown</code> answer is similar to an <code>invalid</code> answer in that additional literals are added to the context which propositionally entail <math>\mathrm{NOT}\ F</math>. The difference in this case is that CVC4 cannot guarantee that <math>\Gamma\cup\Delta</math> is actually satisfiable in <math>T</math>.

CVC4 may report <code>unknown</code> when the context or the query contains
non-linear arithmetic terms or quantifiers.
In all other cases, it is expected to be sound and complete,
i.e., to report <code>Valid</code> if <math>\Gamma \models_T F</math>
and <code>Invalid</code> otherwise.

After an <code>invalid</code> (resp. <code>unknown</code>) answer,
counterexamples (resp. possible counterexamples) can be obtained with
a <math>\mathrm{WHERE}</math>, <math>\mathrm{COUNTEREXAMPLE}</math>,
or <math>\mathrm{COUNTERMODEL}</math> command.


Since the <math>\mathrm{QUERY}</math> command may modify
the current context, if one needs to check several formulas in a row
in the same context, it is a good idea to surround every
query by a <math>\mathrm{PUSH}</math> and <math>\mathrm{POP}</math> invocation
in order to preserve the context:

PUSH;
QUERY <formula>;
POP;

=== CHECKSAT ===

The command <math>\mathrm{CHECKSAT}\ F</math> behaves identically
to <math>\mathrm{QUERY}\ \mathrm{NOT}\ F</math>.

=== RESTART ===

The command <math>\mathrm{RESTART}\ F</math> can only be invoked after an invalid query.
For example, in an interactive setting:

QUERY <formula>;

CVC4> invalid

RESTART <formula2>;

Functionally, the behavior of the above command sequence is identical to the following:

PUSH;
QUERY <formula>;
POP;
ASSERT <formula2>;
QUERY <formula>;

The advantage of using the <math>\mathrm{RESTART}</math> command is that
the first command sequence may be executed much more efficiently that the second.
The reason is that with <math>\mathrm{RESTART}</math> CVC4 will re-use
what it has learned while answering the previous query rather than starting
over from scratch.

=== COUNTERMODEL ===

[More]

=== COUNTEREXAMPLE ===

[More]

=== POPTO ===

[More]

== Instantiation Patterns ==

CVC4 processes each universally quantified formula in the current context
by adding instances of the formula obtained by replacing its universal variables
with ground terms.
Patterns restrict the choice of ground terms for the quantified variables,
with the goal of controlling the potential explosion of ground instances.
In essence, adding patterns to a formula is a way for the user to tell CVC4
to focus only on certain instances which, in the user's opinion, will be
most helpful during a proof.

In more detail, patterns have the following effect on formulas that are found
in the logical context or get added to it later while CVC4 is trying to prove
the validity of some formula <math>F</math>.

If a formula in the current context starts with an existential quantifier,
CVC4 ''Skolemizes'' it, that is, replaces it in the context with the formula
obtained by substituting the existentially quantified variables
by fresh constants and dropping the quantifier.
Any patterns for the existential quantifier are simply ignored.

If a formula starts with a universal quantifier
<math>\mathrm{FORALL}\; (x_1:T_1, \ldots, x_n:T_n)</math>,
CVC4 adds to the context a number of instances of the formula,
with the goal of using them to prove the query <math>F</math> valid.
An instance is obtained by replacing each <math>x_i</math> with a ground term
of the same type occurring in one of the formulas in the context,
and dropping the universal quantifier.
If <math>x_i</math> occurs in a pattern
<math>\mathrm{PATTERN}\; (t_1, \ldots, t_m)</math> for the quantifier,
it will be instantiated only with terms obtained by simultaneously matching
all the terms in the pattern against ground terms in the current context
<math>\Gamma</math>.

Specifically, the matching process produces one or more substitutions
<math>\sigma</math> for the variables in <math>(t_1, \ldots, t_m)</math>
which satisfy the following invariant:
for each <math>i = 1, \ldots, m</math>, <math>\sigma(t_i)</math> is
a ground term and there is a ground term <math>s_i</math> in <math>\Gamma</math>
such that <math>\Gamma \models_T \sigma(t_i) = s_i</math>.
The variables of <math>(x_1:T_1, \ldots, x_n:T_n)</math> that occur
in the pattern are instantiated only with those substitutions
(while any remaining variables are instantiated arbitrarily).

The Skolemized version or the added instances of a context formula may themselves
start with a quantifier.
The same instantiation process is applied to them too, recursively.

Note that the matching mechanism is not limited to syntactic matching
but is modulo the equations asserted in the context.
Because of decidability and/or efficiency limitations, the matching process
is not exhaustive.
CVC4 will typically miss some substitutions that satisfy the invariant above.
As a consequence, it might fail to prove the validity of the query formula
<math>F</math>, which makes CVC4 incomplete for contexts containing
quantified formulas.
It should be noted though that exhaustive matching, which can be achieved
simply by not specifying any patterns, does not yield completeness anyway
since the instantiation of universal variables is still restricted
to just the ground terms in the context,
whereas in general additional ground terms might be needed.

CVC4's native language

2012-11-30T23:15:39Z

Tinelli: /* Parametric Data Types */

= CVC4 native input language =

The native input language consists of a sequence of symbol declarations and commands, each followed by a semicolon (<code>;</code>).

Any text after the first occurrence of a percent character and to the end of the current line is a comment:

%%% This is a native language comment

== Type System ==

CVC4's type system includes a set of built-in types which can be expanded with additional user-defined types.

The type system consists of ''first-order'' types, ''subtypes'' of first-order types, and ''higher-order'' types, all of which are interpreted as sets.
For convenience, we will sometimes identify below the interpretation of a type with the type itself.

First-order types consist of basic types and structured types. The basic types are <math>\mathrm{BOOLEAN}</math>, <math>\mathrm{REAL}</math>, <math>\mathrm{BITVECTOR}(n)</math> for all <math>n > 0</math>, as well as user-defined basic types (also called uninterpreted types).
The structured types are array, tuple, record types, and ML-style user-defined (inductive) datatypes.

'''Note:''' Currently, subtypes consist only of the built-in subtype <math>\mathrm{INT}</math> of <math>\mathrm{REAL}</math>.

Support for CVC3-style user-defined subtypes will be added in a later release.

Function types are the only higher-order types.
More precisely, they are just second-order types
since function symbols in CVC4, both built-in and user-defined, can take as argument or return only values of
a first-order type.

=== Basic Types ===

==== The BOOLEAN Type ====

The <math>\mathrm{BOOLEAN}</math> type is interpreted as the two-element set of Boolean values
<math>\{\mathrm{TRUE},\; \mathrm{FALSE}\}</math>.

'''Note:''' CVC4's treatment of this type differs from CVC3's where <math>\mathrm{BOOLEAN}</math> is used only as the type of formulas, but not as value type. CVC3 follows the two-tiered structure of classical first-order logic
which distinguishes between formulas and terms, and allows terms to occur in formulas but not vice versa (with the exception of the IF-THEN-ELSE construct).
CVC4 drops the distinction between terms and formulas and defines the latter just as terms of type <math>\mathrm{BOOLEAN}</math>. As such, formulas can occur as subterms of possibly non-Boolean terms.

Example:

[To do]

==== The REAL Type ====

The <math>\mathrm{REAL}</math> type is interpreted as the set of real numbers.

Note that these are the (infinite precision) mathematical reals,
not the floating point numbers.
Support for floating point types is planned for future versions.

x, y : REAL;
QUERY (( x <= y ) AND ( y <= x )) => ( x = y );

==== The INT Type ====

The <math>\mathrm{INT}</math> type is interpreted as the set of integer numbers
and is considered as a subtype of <math>\mathrm{REAL}</math>.
The latter means in particular that it is possible to mix integer and real terms
in expressions without the need of an explicit ''upcasting'' operator.

Note that these are the (infinite precision) mathematical integers,
not the finite precision machine integers used in most programming languages.
The latter are models by [[ #Bitvectors | bit vector ]] types.

x, y : INT;
QUERY ((2 * x + 4 * y <= 1) AND ( y >= x)) => (x <= 0);
z : REAL;
QUERY (2 * x + z <= 3.5) AND (z >= 1);

==== Bit Vector Types ====

For every positive integer <math>n</math>, the type <math>\mathrm{BITVECTOR}(n)</math> is interpreted as the set of all bit vectors of size <math>n</math>.
A rich set of bit vector operators is supported.

==== User-defined Basic Types ====

Users can define new basic types
(often referred to as ''uninterpreted'' types in the SMT literature).
Each such type is interpreted as a set of unspecified cardinality
but disjoint from any other type.

User-defined basic types are created by declarations like the following:

% User declarations of basic types:

MyBrandNewType: TYPE;

Apples, Oranges: TYPE;

=== Structured Types ===

CVC4's structured types are divided in the following families.

==== Array Types ====

Array types are created by the mixfix type constructors <math>\mathrm{ARRAY}\ \_\ \mathrm{OF}\ \_</math>
whose arguments can be instantiated by any value type.

I : TYPE;

%% Array types:

% Arrays with indices from I and values from REAL
Array1: TYPE = ARRAY I OF REAL;

% Arrays with integer indices and array values
Array2: TYPE = ARRAY INT OF (ARRAY INT OF REAL);

% Arrays with integer pair indices and integer values
IntMatrix: TYPE = ARRAY [INT, INT] OF INT;

An array type of the form <math>\mathrm{ARRAY}\ T_1\ \mathrm{OF}\ T_2</math> is interpreted
as the set of all total maps from <math>T_1</math> to <math>T_2</math>.
The main difference with the function type <math>T_1 \to T_2</math> is that arrays,
contrary to functions, are first-class objects of the language, that is, values of an array
type can be arguments or results of functions.
Furthermore, array types come equipped with an update operation.

==== Tuple Types ====

Tuple types are created by the mixfix type constructors

<center>
<math>
\begin{array}{l} [\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ \ ,\ \_\ ] \\[1ex] \ldots \end{array}
</math>
</center>

whose arguments can be instantiated by any value type.

IntArray: TYPE = ARRAY INT OF INT;

% Tuple type declarations

RealPair: TYPE = [REAL, REAL]

MyTuple: TYPE = [ REAL, IntArray, [INT, INT] ];

A tuple type of the form <math>[T_1, \ldots, T_n]</math> is interpreted
as the Cartesian product <math>T_1 \times \cdots \times T_n</math>.

Note that while the types <math>(T_1, \ldots, T_n) \to T</math> and
<math>[T_1 \times \cdots \times T_n] \to T</math> are semantically equivalent,
they are operationally different in CVC4.
The first is the type of functions that take <math>n</math> arguments
of respective type <math>T_1</math>, <math>\ldots</math>, <math>T_n</math>,
while the second is the type of functions that take one argument of an <math>n</math>-tuple type.

==== Record Types ====

Similar to, but more general than tuple types, record types are created by type constructors of the form

<center>
<math>
[\#\ l_1: \_\ ,\ \ldots\ ,\ l_n: \_\ \#]
</math>
</center>

where <math>n > 0</math>, <math>l_1,\ldots, l_n</math> are field labels,
and the arguments can be instantiated with any first-order types.

MyType: TYPE;

% Record declaration

RecordType: TYPE = [# id: REAL, age: INT, info: MyType #];

The order of the fields in a record type is meaningful:
permuting the field names gives a different type.

Note that record types are non-recursive.
For instance, it is not possible to declare a record type called <code>Person</code> containing
a field of type <code>Person</code>.
Recursive types are provided in CVC4 by the more general inductive data types.
(As a matter of fact, both record and tuple types are implemented internally as inductive data types.)

==== Inductive Data Types ====

Inductive data types in CVC4 are similar to inductive data types of functional languages.
They can be parametric or not.

===== Non-Parametric Data Types =====

Non-parametric data types are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1 & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2 & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types, including any <math>A_i</math>.
Such declarations define the data types <math>A_1, \ldots, A_n</math>.
For each data type <math>A_i</math> they introduce:

* constructor symbols <math>cons</math> of type <math>(T_1, \ldots, T_k) \to \mathit{type\_name}_i</math>,
* selector symbols <math>\mathit{sel}_j</math> of type <math>\mathit{type\_name}_i \to T_j</math>, and
* tester symbols <math>\mathit{is\_cons}</math> of type <math>\mathit{type\_name}_i \to \mathrm{BOOLEAN}</math>.

Note that permitting more than one data type to be defined in the same declarations allows
the definition of mutually recursive types.

% simple enumeration type

% implicitly defined are the testers: is_red, is_yellow and is_blue
% (similarly for the other data types)

DATATYPE
PrimaryColor = red | yellow | blue
END;

% infinite set of pairwise distinct values ..., v(-1), v(0), v(1), ...

DATATYPE
Id = v (id: INT)
END;

% ML-style integer lists

DATATYPE
IntList = nil | ins (head: INT, tail: IntList)
END;

% AST for lamba calculus

DATATYPE
Term = var (index: INT)
| apply (arg_1: Term, arg_2: Term)
| lambda (arg: INT, body: Term)
END;

% Trees

DATATYPE
Tree = tree (value: REAL, children: TreeList),
TreeList = nil_tl
| ins_tl (first_t1: Tree, rest_t1: TreeList)
END;

Constructor, selector and tester symbols defined for a data type have global scope.
So, for example, it is not possible for two different data types to use
the same name for a constructor.

An inductive data type is interpreted as a term algebra constructed by the constructor symbols
over some sets of generators.
For example, the type <code>IntList</code> defined above is interpreted as the set
of all terms constructed with <code>nil</code> and <code>ins</code> over the integers.

===== Parametric Data Types =====

Parametric data types are infinite families of (non-parametric) data types
with each family parametrized by one or more type variables.
They are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1[X_{1,1}, \ldots, X_{1,p_1}] & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2[X_{2,1}, \ldots, X_{2,p_2}] & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n[X_{n,1}, \ldots, X_{n,p_n}] & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name parametrized by the type variables <math>X_{i,1}, \ldots, X_{i,p_i}</math>
and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types,
possibly parametrized by <math>X_1, \ldots, X_p</math>, including any <math>A_i</math>.

% Parametric pairs
DATATYPE
Pair[X, Y] = pair (first: X, second: Y)
END;

% Parametric lists

DATATYPE
List[X] = nil | cons (head: X, tail: List[X])
END;

% Parametric trees using the list type above

DATATYPE
Tree[X] = node (value: X, children: List[Tree[X]]),
END;

The declarations above define infinitely many types of the form
Pair[S,T], List[T] and Tree[T] where S and T are first-order types.
Note that the identifier <code>List</code> above, for example, by itself does not denote a type.
In contrast, the terms <code>List[Real]</code>, <code>List[List[Real]]</code>, <code>List[Tree[INT]]</code>,
and so on do.

===== Restriction to Inductive Types =====

By adopting a term algebra semantics, CVC4 allows only ''inductive'' data types,
that is, data types whose values are essentially (labeled, ordered) finite trees.
Infinite structures such as streams or even finite but cyclic ones
such as circular lists are then excluded.
For instance, none of the following declarations define inductive data types,
and are rejected by CVC4:

DATATYPE
IntStream = s (first:INT, rest: IntStream)
END;

DATATYPE
RationalTree = node1 (child: RationalTree)
| node2 (left_child: RationalTree, right_child:RationalTree)
END;

DATATYPE
T1 = c1 (s1: T2),
T2 = c2 (s2: T1)
END;

In concrete, a declaration of <math>n \geq 1</math> datatypes <math>T_1, \ldots, T_n</math> will be rejected if for any one of the types <math>T_1, \ldots, T_n</math>, it is impossible to build a finite term of that type using only the constructors of <math>T_1, \ldots, T_n</math> and free constants of type other than <math>T_1, \ldots, T_n</math>.

Inductive data types are the only types where the user also chooses names for the built-in operations to:

* construct a value of the type (with the constructors),
* extract components from a value (with the selectors), or
* check if a value was constructed with a certain constructor or not (with the testers).

For all the other types, CVC4 provides predefined names for the built-in operations on the type.

=== Function Types ===

Function (<math>\to</math>) types are created by the mixfix type constructors
<center>
<math>
\begin{array}{l}
\_ \to \_ \\[1ex] (\ \_\ ,\ \_\ ) \to \_
\\[1ex] (\ \_\ ,\ \_\ ,\ \_\ ) \to \_
\\[1ex] \ldots
\end{array}
</math>
</center>
whose arguments can be instantiated by any first-order type.

% Function type declarations

UnaryFunType: TYPE = INT -> REAL;

BinaryFunType: TYPE = (REAL, REAL) -> ARRAY REAL OF REAL;

TernaryFunType: TYPE = (REAL, BITVECTOR(4), INT) -> BOOLEAN;

A function type of the form <math>(T_1, \ldots, T_n) \to T</math> with <math>n > 0</math> is interpreted as the set of all ''total'' functions from the Cartesian product <math>T_1 \times \cdots \times T_n</math> to <math>T</math>.

The example above also shows how to introduce type names.
A name like <code>UnaryFunType</code> above is just an abbreviation for the type <math>\mathrm{INT} \to \mathrm{REAL}</math> and can be used interchangeably with it.

In general, any type defined by a type expression <code>E</code> can be given a name with the declaration:

name : TYPE = E;

=== Type Checking ===

In CVC4, formulas and terms are statically typed at the level of types
(as opposed to subtypes) according to the usual rules of first-order many-sorted logic,
with the main difference that formulas are just terms of type <math>BOOLEAN</math>:

* each variable has one associated first-order type,
* each constant symbol has one or more associated first-order types,
* each function symbol has one or more associated function types,
* the type of a term consisting just of a variable is the type associated to that variable,
* the type of a term consisting just of a constant symbol is the type associated to that constant symbol,
* the term obtained by applying a function symbol <math>f</math> to the terms <math>t_1, \ldots, t_n</math> is <math>T</math> if <math>f</math> has type <math>(T_1, \ldots, T_n) \to T</math> and each <math>t_i</math> has type <math>T_i</math>.

Attempting to enter an ill-typed term will result in an error.

Another significant difference with standard many-sorted logic is that
some built-in symbols are parametrically polymorphic.
For instance, the function symbol for extracting the element of any array has
type <math>(\mathit{ARRAY}\ T_1\ \mathit{OF}\ T_2,\; T_1) \to T_2</math>
for all first-order types <math>T_1, T_2</math>.

==== Type Ascription ====

By the type inference rules above some terms might have more than one type.
This can happen with terms built with polymorphic data type constructors
that have more than one return type for the same input type.
In that case, a type ascription operator (<code>::</code>) must be applied
to the constructor to specify the intended return type.

DATATYPE [X]
List[X] = nil | cons (head: X, tail: List[X])
END;

ASSERT y = cons(1, nil::List[REAL]);

DATATYPE [X, Y]
Union[X, Y] = left(val_l: X) | right(val_r: Y)
END;

ASSERT y = left::Union[BOOLEAN, REAL](TRUE);

The constant symbol <math>\mathrm{nil}</math> declared above has infinitely many types
(<math>\mathrm{List}[\mathrm{REAL}]</math>, <math>\mathrm{List}[\mathrm{BOOLEAN}]</math>,
<math>\mathrm{List}[[\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{List}[\mathrm{List}[\mathrm{REAL}]]</math>, ...)
CVC4's type checker requires the user to indicate explicitly the type
of each occurrence of <code>nil</code> in a term.
Similarly,
the injection operator <code>left</code> has infinitely many return types
for the same input type, for instance:
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{REAL}]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, [\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{List}[\mathrm{REAL}]]</math>,
and so on.
Applications of <code>left</code> need to specify the intended returned typed, as shown above.

== Terms and Formulas ==

In addition to type expressions, CVC4 has expressions for terms and for formulas
(i.e., terms of type <math>\mathrm{BOOLEAN}</math>).
By and large, these are standard first-order terms built out of typed variables,
predefined theory-specific operators, free (i.e., user-defined) function symbols,
and quantifiers.
Extensions include an if-then-else operator, lambda abstractions, and local symbol
declarations, as illustrated below.
Note that these extensions still keep CVC4's language first-order.
In particular, lambda abstractions are restricted to take and return only terms of
a first-order type.
Similarly, variables can only be of a first-order type.

A number of built-in function symbols (for instance, the arithmetic ones) are used
as infix operators. All user-defined symbols are used as prefix ones.

User-defined, i.e., free, function symbols include ''constant symbols'' and
''predicate symbols'', respectively nullary function symbols and function symbols
with a <math>\mathrm{BOOLEAN}</math> return type.
These symbols are introduced with global declarations of the form
<math> f_1, \ldots, f_m: T;</math>
where <math>m > 0</math>, <math>f_i</math> are the names of the symbols and
<math>T</math> is their type:

% integer constants

a, b, c: INT;

% real constants

x, y, z: REAL;

% unary function

f1: REAL -> REAL;

% binary function

f2: (REAL, INT) -> REAL;

% unary function with a tuple argument

f3: [INT, REAL] -> BOOLEAN;

% binary predicate

p: (INT, REAL) -> BOOLEAN;

% Propositional "variables"

P, Q; BOOLEAN;

Like type declarations, function symbol declarations like the above have global scope
and must be unique.
In other words, it is not possible to declare a function symbol globally more than once
in the same lexical scope.
This entails among other things that globally-defined free symbols cannot be overloaded
with different types and that theory symbols cannot be redeclared globally as free symbols.

=== Global symbol definitions ===

As with types, a function symbol can be defined as the name of another term
of the corresponding type.
With constant symbols, this is done with a declaration of the form <math>f:T = t;</math> :

c: INT;

i: INT = 5 + 3*c; % i is effectively a shorthand for 5 + 3*c

j: REAL = 3/4;

t: [REAL, INT] = (2/3, -4);

r: [# key: INT, value: REAL #] = (# key := 4, value := (c + 1)/2 #);

f: BOOLEAN = FORALL (x:INT): x <= 0 OR x > c ;

A restriction on constants of type <math>\mathit{BOOLEAN}</math> is that their value
can only be a closed formula, that is, a formula with no free variables.

A term and its name can be used interchangeably in later expressions.
Named terms are often useful for shared subterms (terms used several times in different places)
since their use can make the input exponentially more concise.
Named terms are processed very efficiently by CVC4.
It is much more efficient to associate a complex term with a name directly rather than
to declare a constant and later assert that it is equal to the same term.
This point is explained in more detail later in section [[Commands | Commands]].

More generally, in CVC4 one can associate a term to function symbols of any arity.
For non-constant function symbols this is done with a declaration of the form

<center>
<math>f:(T_1, \ldots, T_n) \to T = \mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t\;;</math>
</center>

where <math>t</math> is any term of type <math>T</math> with free variables
in <math>\{x_1, \ldots, x_n\}</math>.
The lambda binder has the usual semantics and conforms to the usual lexical scoping rules:
within the term <math>t</math> the declaration of the symbols <math>x_1, \ldots, x_n</math>
as local variables of respective type <math>T_1, \ldots, T_n</math> hides any previous
declarations of those symbols that are in scope.

As a general shorthand, when <math>k</math> consecutive types
<math>T_i, \ldots, T_{i+k-1}</math> in the lambda expression
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t</math> are identical, the syntax
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x_i,\ldots, x_{i+k-1}:T_i,\ldots, x:T_n): t</math>
can also be used.

% Global declaration of x as a unary function symbol

x: REAL -> REAL;

% Local declarations of x as variable (hiding the global one)

f: REAL -> REAL = LAMBDA (x: REAL): 2*x + 3;

p: (INT, INT) -> BOOLEAN = LAMBDA (x,i: INT): i*x - 1 > 0;

g: (REAL, INT) -> [REAL, INT] = LAMBDA (x: REAL, i:INT): (x + 1, i - 3);

Note that lambda definitions are not recursive:
the symbol being defined cannot occur in the body of the lambda term.
They should be understood as macros.
For instance, any occurrence of the term <math>f(t)</math>
where <math>f</math> is as defined above will be treated
as if it was the term <math>(2*t + 3)</math>.

=== Local symbol definitions ===

Constant and function symbols can also be declared locally anywhere within a term
by means of a let binder.
This is done with a declaration of the form

<center>
<math>
\mathrm{LET}\ f = t \ \mathrm{IN}\ t' ;
</math>
</center>

where <math>t</math> is a term with no free variables, possibly a lambda term.
Let binders can be nested arbitrarily and follow the usual lexical scoping rules.
The following general form
<center>
<math>
\mathrm{LET}\ f_1 = t_1, f_2 = t_2, \ldots, f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>
can be use above can used as a shorthand for
<center>
<math>
\mathrm{LET}\ f_1 = t_1\ \mathrm{IN}\
\mathrm{LET}\ f_2 = t_2\ \mathrm{IN}\
\ldots \
\mathrm{LET}\ f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>

t: REAL =
LET x1 = 42,
g = LAMBDA(x:INT): x + 1,
x2 = 2*x1 + 7/2
IN
(LET x3 = g(x1) IN x3 + x2) / x1;

Note that the same symbol = is used, unambiguously, in the syntax of global declarations,
let declarations, and as a predicate symbol.

'''Note:'''
A <math>\mathrm{LET}</math> term with a multiple symbols defines them sequentially.
A parallel version of the <math>\mathrm{LET}</math> construct will be introduced in a later version.

== Built-in theories and their symbols ==

In addition to user-defined symbols, CVC4 terms can use a number of predefined symbols:
the logical symbols, such as <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, etc.,
as well as theory symbols, function symbols belonging to one of the built-in theories.
They are described next, with the theory symbols grouped by theory.

=== Logical Symbols ===

The logical symbols in CVC4's language include
the equality and disequality predicate symbols, respectively written as = and /=,
the multiarity disequality symbol <math>\mathrm{DISTINCT}</math>,
together with the logical constants <math>\mathrm{TRUE}</math>, <math>\mathrm{FALSE}</math>,
the connectives <math>\mathrm{NOT}</math>, <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, <math>\mathrm{XOR}</math>, <math>\Rightarrow</math>, <math>\Leftrightarrow</math>, and
the first-order quantifiers <math>\mathrm{EXISTS}</math> and <math>\mathrm{FORALL}</math>,
all with the standard many-sorted logic semantics.

The binary connectives have infix syntax and type
<math>(\mathrm{BOOLEAN},\mathrm{BOOLEAN}) \to \mathrm{BOOLEAN}</math>.
The symbols = and /=, which are also infix, are instead parametrically polymorphic,
having type <math>(T,T) \to \mathrm{BOOLEAN}</math>
for every first-order type <math>T</math>.
They are interpreted respectively as the identity relation and its complement.

The DISTINCT symbol is both overloaded and polymorphic.
It has type <math>(T,...,T) \to \mathrm{BOOLEAN}</math>
for every sequence <math>(T,...,T)</math> of length <math>n > 0</math>
and first-order type <math>T</math>.
For each <math>n > 0</math>, it is interpreted as the relation
that holds exactly for tuples of pairwise distinct elements.

The syntax for quantifiers is similar to that of the lambda binder.

Here is an example of a formula built just of these logical symbols and variables:

A, B: TYPE;

q: BOOLEAN = FORALL (x,y: A, i,j,k: B):
i = j AND i /= k => EXISTS (z: A): x /= z OR z /= y;

Binding and scoping of quantified variables follows the same rules as
in let expressions.
In particular, a quantifier will shadow in its scope any constant and function symbols
with the same name as one of the variables it quantifies:

A: TYPE;
i, j: INT;

% The first occurrence of i and of j in f are constant symbols,
% the others are variables.

f: BOOLEAN = i = j AND FORALL (i,j: A): i = j OR i /= j;

Optionally, it is also possible to specify instantiation patterns
for quantified variables.
The general syntax for a quantified formula <math>\psi</math> with patterns is

<center>
<math>
Q\;(x_1:T_1, \ldots, x_k:T_k):\; p_1: \ldots\; p_n:\; \varphi
</math>
</center>

where <math>n \geq 0</math>, <math>Q</math> is
either <math>\mathrm{FORALL}</math> or <math>\mathrm{EXISTS}</math>,
<math>\varphi</math> is a term of type <math>\mathrm{BOOLEAN}</math>,
and each of the <math>p_i</math>'s,
a pattern for the quantifier <math>Q\;(x_1:T_1, \ldots, x_k:T_k)</math>, has the form

<center>
<math>
\mathrm{PATTERN}\; (t_1, \ldots, t_m)
</math>
</center>

where <math>m > 0</math> and <math>t_1, \ldots, t_m</math> are
arbitrary binder-free terms (no lets, no quantifiers).
Those terms can contain (free) variables, typically, but not exclusively,
drawn from <math>x_1, \ldots, x_k</math>.
(Additional variables can occur if <math>\psi</math> occurs in a bigger formula
binding those variables.)

A: TYPE;
b, c: A;
p, q: A -> BOOLEAN;
r: (A, A) -> BOOLEAN;

ASSERT FORALL (x0, x1, x2: A):
PATTERN (r(x0, x1), r(x1, x2)):
(r(x0, x1) AND r(x1, x2)) => r(x0, x2) ;

ASSERT FORALL (x: A):
PATTERN (r(x, b)):
PATTERN (r(x, c)):
p(x) => q(x) ;

ASSERT EXISTS (y: A):
FORALL (x: A):
PATTERN (r(x, y), p(y)):
r(x, y) => q(x) ;

Patterns have no logical meaning:
adding them to a formula does not change its semantics.
Their purpose is purely operational, as explained in
the [[#Instantiation Patterns | Instantiation Patterns]] section.

In addition to these constructs, CVC4 also has a general mixfix conditional operator
of the form

<center>
<math>
\mathrm{IF}\ b\ \mathrm{THEN}\ t\ \mathrm{ELSIF}\ b_1\ \mathrm{THEN}\ t_1\ \ldots\ \mathrm{ELSIF}\ b_n\ \mathrm{THEN}\ t_n\ \mathrm{ELSE}\ t_{n+1}\ \mathrm{ENDIF}
</math>
</center>

with <math>n \geq 0</math> where
<math>b, b_1, \ldots, b_n</math> are terms of type <math>\mathrm{BOOLEAN}</math> and
<math>t, t_1, \ldots, t_n, t_{n+1}</math> are terms of the same first-order type <math>T</math>:

% Conditional term
x, y, z, w: REAL;

t: REAL =
IF x > 0 THEN y
ELSIF x >= 1 THEN z
ELSIF x > 2 THEN w
ELSE 2/3 ENDIF;

=== User-defined Functions and Types ===

The theory of user-defined functions,also know in the SMT literature as
the theory ''Equality over Uninterpreted Functions'', or ''EUF'', is in effect
a family of theories of equality parametrized by the basic types and the free symbols
a user can define during a run of CVC4.

This theory has no built-in symbols (other than the logical ones).
Its types consist of ''all and only'' the user-defined types.
Its function symbols consist of ''all and only'' the user-defined free symbols.

=== Arithmetic ===

The real arithmetic theory has two types:
<math>\mathrm{REAL}</math> and <math>\mathrm{INTEGER}</math>
with the latter a subtype of the first.
Its built-in symbols for the usual arithmetic constants
and operators over the type <math>\mathrm{REAL}</math>, each with the expected type:
all numerals 0, 1, ..., as well as - (both unary and binary), +, *, /, <, >, <=, >=.
Application of the binary symbols are in infix form.
Note that + is only binary, and so an expression such as +4 is ill-formed.

Rational values can be expressed in decimal or fractional format,
e.g., 0.1, 23.243241, 1/2, 3/4, and so on.
A leading 0 is mandatory for decimal numbers smaller than one
(e.g., the syntax .3 cannot be used as a shorthand for 0.3).
However, a trailing 0 is ''not'' required for decimals that are whole numbers
(e.g., 3. is allowed as a shorthand for 3.0).
The size of the numerals used in the representation of natural and rational numbers
is unbounded; more accurately, bounded only by the amount of available memory.

=== Bit vectors ===

=== Arrays ===

The theory of arrays is a parametric theory of (total) unary maps.
It comes equipped with mixfix polymorphic selection and update operators, respectively
<center>
<math>\_[\_]</math> and <math>\_\ \mathrm{WITH}\ [\_]\ := \_</math> .
</center>
The semantics of these operators is the expected one:
for all first-order types <math>T_1</math> and <math>T_2</math>,
if <math>a</math> is of type <math>\mathrm{ARRAY}\ T_1 \mathrm{OF}\ T_2</math>,
<math>i</math> is of type <math>T_1</math>, and
<math>v</math> is of type <math>T_2</math>,
* <math>a[i]</math> denotes the value that <math>a</math> associates to index <math>i</math>,
* <math>a\ \mathrm{WITH}\ [i]\ := v</math> denotes a map that associates <math>v</math> to index <math>i</math> and is otherwise identical to <math>a</math>.
Sequential updates can be chained with the shorthand syntax
<math>\_\ \mathrm{WITH}\ [\_]\ := \_, \ldots, [\_]\ := \_</math>.

A: TYPE = ARRAY INT OF REAL;
a: A;
i: INT = 4;

% selection:

elem: REAL = a[i];

% update

a1: A = a WITH [10] := 1/2;

% sequential update
% (syntactic sugar for (a WITH [10] := 2/3) WITH [42] := 3/2)

a2: A = a WITH [10] := 2/3, [42] := 3/2;

Since arrays are just maps, equality between them is extensional, that is,
for two arrays of the same type to be different they have to map at least one
index to differ values.

=== Data types ===

The theory of inductive data types is in fact a family of theories parametrized
by a data type declaration specifying constructors and selectors
for one or more user-defined data types.

No built-in operators other than equality and disequality are provided
for this family in the native language.
Each user-provided data type declaration, however, generates constructor, selector and tester operators
as described in the [[#Inductive Data Types | Inductive Data Types]] section.

=== Tuples and Records ===

Semantically both records and tuples can be seen as special instances
of inductive data types.
CVC4 implements them internally indeed as data types.
In essence, a record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math>
is encoded as a data type of the form

<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\ \ \mathrm{Record} = \mathit{rec}(l_0:T_0, \ldots, l_n:T_n) \\
\mathrm{END};
\end{array}
</math>
</center>

Tuples of length <math>n</math> are in turn special cases of records whose field names are
the numerals from <math>0</math> to <math>n-1</math>.

Externally, tuples and records have their own syntax for constructor and selector operators.
* Records of type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> have the associated record constructor <math>(\#\ l_0 := \_,\; \ldots,\; l_n := \_\ \#)</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.
* Tuples of type <math>[\ T_0, \ldots, T_n\ ]</math> have the associated tuple constructor <math>(\ \_,\; \ldots,\; \_\ )</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.

The selector operators on records and tuples follows a dot notation syntax.

% Record construction and field selection
Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);
k: INT = x.key;
v: REAL = x.weight;

% Tuple construction and projection
y: [REAL, INT, REAL] = ( 4/5, 9, 11/9 );
first_elem: REAL = y.0;
third_elem: REAL = y.2;

Differently from data types, records and tuples are also provided with built-in update operators similar in syntax and semantics to the update operator for arrays.
More precisely, for each record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .l_i\ := \_
</math>
</center>

The operator maps a record <math>r</math> of that type and a value <math>v</math>
of type <math>T_i</math> to the record that stores <math>v</math> in field <math>l_i</math>
and is otherwise identical to <math>r</math>.
Analogously, for each tuple type <math>[T_0, \ldots, T_n]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .i\ := \_
</math>
</center>

with similar semantics.

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = x WITH .weight := 48;

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = y WITH .1 := 3;

Updates to a nested component can be combined in a single WITH operator:

Cache: TYPE = ARRAY [0..100] OF [# addr: INT, data: REAL #];
State: TYPE = [# pc: INT, cache: Cache #];

s0: State;
s1: State = s0 WITH .cache[10].data := 2/3;

Note that, differently from updates on arrays, tuple and record updates are
just additional syntactic sugar.
For instance, the record <code>x1</code> and tuple <code>y1</code> defined above
could have been equivalently defined as follows:

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = (# key := x.key, weight := 48 #);

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = ( y.0, 3, y.1 );

== Commands ==

In addition to declarations of types and function symbols,
the CVC4 native language contains the following commands:

* <math>\mathrm{ASSERT}\ F</math> -- Add the formula <math>F</math> to the current logical context <math>\Gamma</math>.
* [[#CHECKSAT|<math>\mathrm{CHECKSAT}\ F</math>]] -- Check if the formula <math>F</math> is satisfiable in the current logical context (<math>\Gamma \not\models_T \mathrm{NOT}\ F</math>).
* <math>\mathrm{CONTINUE}</math> -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, search for a counter-example different from the current one.
* [[#COUNTEREXAMPLE|<math>\mathrm{COUNTEREXAMPLE}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print the context that is a witness for invalidity/satisfiability.
* [[#COUNTERMODEL|<math>\mathrm{COUNTERMODEL}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print a model that makes the formula invalid/satisfiable. The model is provided in terms of concrete values for each free symbol.
* <math>\mathrm{OPTION}\ o\ v</math> -- Set the command-line option flag <math>o</math> to value <math>v</math>. The argument <math>o</math> is provide as a string literal enclosed in double-quotes and <math>v</math> as an integer value.
* <math>\mathrm{POP}</math> -- Equivalent to <math>\mathrm{POPTO}\ 1</math>
* [[#POPTO|<math>\mathrm{POPTO}\ n</math>]] -- Restore the system to the state it was in right before the most recent call to <math>\mathrm{PUSH}</math> made from stack level <math>n</math>. Note that the current stack level is printed as part of the output of the <math>\mathrm{WHERE}</math> command.
* <math>\mathrm{PUSH}</math> -- Save (checkpoint) the current state of the system.
* [[#QUERY|<math>\mathrm{QUERY}\ F</math>]] -- Check if the formula <math>F</math> is valid in the current logical context (<math>\Gamma\models_T F</math>).
* [[#RESTART|<math>\mathrm{RESTART}\ F</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, repeat the check but with the additional assumption <math>F</math> in the context.
* <math>\mathrm{PRINT}\ t</math> -- Parse and print back the term <math>t</math>.
* <math>\mathrm{TRANSFORM}\ t</math> -- Simplify the term <math>t</math> and print the result.
* <math>\mathrm{WHERE}</math> -- Print all the formulas in the current logical context <math>\Gamma</math>.

The remaining commands take a single argument, given as a string literal enclosed in double-quotes.

* <math>\mathrm{ECHO}\ s</math> -- Print string <math>s</math>
* <math>\mathrm{INCLUDE}\ f</math> -- Read commands from file <math>f</math>.
* <math>\mathrm{TRACE}\ f</math> -- Turn on tracing for the debug flag <math>f</math>.
* <math>\mathrm{UNTRACE}\ f</math> -- Turn off tracing for the debug flag <math>f</math>.

Here, we explain some of the above commands in more detail.

=== QUERY ===

The command <math>\mathrm{QUERY}\ F</math> invokes the core functionality of CVC4 to check
the validity of the formula <math>F</math> with respect to the assertions made thus far,
which constitute the context <math>\Gamma</math>.
The argument <math>F</math> must be well typed term of type <math>\mathrm{BOOLEAN}</math>,
as described in [[#Terms and Formulas | Terms and Formulas]].

The execution of this command always terminates and produces one of three possible answers:
<code>valid</code>, <code>invalid</code>, and <code>unknown</code>.

* A <code>valid</code> answer indicates that <math>\Gamma \models_T F</math>. After a query returning such an answer, the logical context <math>\Gamma</math> is exactly as it was before the query.
* An <code>invalid</code> answer indicates that <math>\Gamma \not\models_T F</math>, that is, there is a model of the background theory <math>T</math> that satisfies <math>\Gamma \cup \{\mathrm{NOT}\ F\}</math>. When <math>\mathrm{QUERY}\ F</math> returns <code>invalid</code>, the logical context <math>\Gamma</math> is augmented with a set <math>\Delta</math> of ground (i.e., variable-free) literals such that <math>\Gamma\cup\Delta</math> is satisfiable in <math>T</math>, but <math>\Gamma\cup\Delta\models_T \mathrm{NOT}\ F</math>. In fact, in this case <math>\Delta</math> ''propositionally entails'' <math>\mathrm{NOT}\ F</math>, in the sense that, every truth assignment to the literals of <math>\Delta</math> that satisfies <math>\Delta</math> falsifies <math>F</math>. We call the new context <math>\Gamma\cup\Delta</math> a ''counterexample'' for <math>F</math>.
* An <code>unknown</code> answer is similar to an <code>invalid</code> answer in that additional literals are added to the context which propositionally entail <math>\mathrm{NOT}\ F</math>. The difference in this case is that CVC4 cannot guarantee that <math>\Gamma\cup\Delta</math> is actually satisfiable in <math>T</math>.

CVC4 may report <code>unknown</code> when the context or the query contains
non-linear arithmetic terms or quantifiers.
In all other cases, it is expected to be sound and complete,
i.e., to report <code>Valid</code> if <math>\Gamma \models_T F</math>
and <code>Invalid</code> otherwise.

After an <code>invalid</code> (resp. <code>unknown</code>) answer,
counterexamples (resp. possible counterexamples) can be obtained with
a <math>\mathrm{WHERE}</math>, <math>\mathrm{COUNTEREXAMPLE}</math>,
or <math>\mathrm{COUNTERMODEL}</math> command.


Since the <math>\mathrm{QUERY}</math> command may modify
the current context, if one needs to check several formulas in a row
in the same context, it is a good idea to surround every
query by a <math>\mathrm{PUSH}</math> and <math>\mathrm{POP}</math> invocation
in order to preserve the context:

PUSH;
QUERY <formula>;
POP;

=== CHECKSAT ===

The command <math>\mathrm{CHECKSAT}\ F</math> behaves identically
to <math>\mathrm{QUERY}\ \mathrm{NOT}\ F</math>.

=== RESTART ===

The command <math>\mathrm{RESTART}\ F</math> can only be invoked after an invalid query.
For example, in an interactive setting:

QUERY <formula>;

CVC4> invalid

RESTART <formula2>;

Functionally, the behavior of the above command sequence is identical to the following:

PUSH;
QUERY <formula>;
POP;
ASSERT <formula2>;
QUERY <formula>;

The advantage of using the <math>\mathrm{RESTART}</math> command is that
the first command sequence may be executed much more efficiently that the second.
The reason is that with <math>\mathrm{RESTART}</math> CVC4 will re-use
what it has learned while answering the previous query rather than starting
over from scratch.

=== COUNTERMODEL ===

[More]

=== COUNTEREXAMPLE ===

[More]

=== POPTO ===

[More]

== Instantiation Patterns ==

CVC4 processes each universally quantified formula in the current context
by adding instances of the formula obtained by replacing its universal variables
with ground terms.
Patterns restrict the choice of ground terms for the quantified variables,
with the goal of controlling the potential explosion of ground instances.
In essence, adding patterns to a formula is a way for the user to tell CVC4
to focus only on certain instances which, in the user's opinion, will be
most helpful during a proof.

In more detail, patterns have the following effect on formulas that are found
in the logical context or get added to it later while CVC4 is trying to prove
the validity of some formula <math>F</math>.

If a formula in the current context starts with an existential quantifier,
CVC4 ''Skolemizes'' it, that is, replaces it in the context with the formula
obtained by substituting the existentially quantified variables
by fresh constants and dropping the quantifier.
Any patterns for the existential quantifier are simply ignored.

If a formula starts with a universal quantifier
<math>\mathrm{FORALL}\; (x_1:T_1, \ldots, x_n:T_n)</math>,
CVC4 adds to the context a number of instances of the formula,
with the goal of using them to prove the query <math>F</math> valid.
An instance is obtained by replacing each <math>x_i</math> with a ground term
of the same type occurring in one of the formulas in the context,
and dropping the universal quantifier.
If <math>x_i</math> occurs in a pattern
<math>\mathrm{PATTERN}\; (t_1, \ldots, t_m)</math> for the quantifier,
it will be instantiated only with terms obtained by simultaneously matching
all the terms in the pattern against ground terms in the current context
<math>\Gamma</math>.

Specifically, the matching process produces one or more substitutions
<math>\sigma</math> for the variables in <math>(t_1, \ldots, t_m)</math>
which satisfy the following invariant:
for each <math>i = 1, \ldots, m</math>, <math>\sigma(t_i)</math> is
a ground term and there is a ground term <math>s_i</math> in <math>\Gamma</math>
such that <math>\Gamma \models_T \sigma(t_i) = s_i</math>.
The variables of <math>(x_1:T_1, \ldots, x_n:T_n)</math> that occur
in the pattern are instantiated only with those substitutions
(while any remaining variables are instantiated arbitrarily).

The Skolemized version or the added instances of a context formula may themselves
start with a quantifier.
The same instantiation process is applied to them too, recursively.

Note that the matching mechanism is not limited to syntactic matching
but is modulo the equations asserted in the context.
Because of decidability and/or efficiency limitations, the matching process
is not exhaustive.
CVC4 will typically miss some substitutions that satisfy the invariant above.
As a consequence, it might fail to prove the validity of the query formula
<math>F</math>, which makes CVC4 incomplete for contexts containing
quantified formulas.
It should be noted though that exhaustive matching, which can be achieved
simply by not specifying any patterns, does not yield completeness anyway
since the instantiation of universal variables is still restricted
to just the ground terms in the context,
whereas in general additional ground terms might be needed.

CVC4's native language

2012-11-30T23:14:58Z

Tinelli:

= CVC4 native input language =

The native input language consists of a sequence of symbol declarations and commands, each followed by a semicolon (<code>;</code>).

Any text after the first occurrence of a percent character and to the end of the current line is a comment:

%%% This is a native language comment

== Type System ==

CVC4's type system includes a set of built-in types which can be expanded with additional user-defined types.

The type system consists of ''first-order'' types, ''subtypes'' of first-order types, and ''higher-order'' types, all of which are interpreted as sets.
For convenience, we will sometimes identify below the interpretation of a type with the type itself.

First-order types consist of basic types and structured types. The basic types are <math>\mathrm{BOOLEAN}</math>, <math>\mathrm{REAL}</math>, <math>\mathrm{BITVECTOR}(n)</math> for all <math>n > 0</math>, as well as user-defined basic types (also called uninterpreted types).
The structured types are array, tuple, record types, and ML-style user-defined (inductive) datatypes.

'''Note:''' Currently, subtypes consist only of the built-in subtype <math>\mathrm{INT}</math> of <math>\mathrm{REAL}</math>.

Support for CVC3-style user-defined subtypes will be added in a later release.

Function types are the only higher-order types.
More precisely, they are just second-order types
since function symbols in CVC4, both built-in and user-defined, can take as argument or return only values of
a first-order type.

=== Basic Types ===

==== The BOOLEAN Type ====

The <math>\mathrm{BOOLEAN}</math> type is interpreted as the two-element set of Boolean values
<math>\{\mathrm{TRUE},\; \mathrm{FALSE}\}</math>.

'''Note:''' CVC4's treatment of this type differs from CVC3's where <math>\mathrm{BOOLEAN}</math> is used only as the type of formulas, but not as value type. CVC3 follows the two-tiered structure of classical first-order logic
which distinguishes between formulas and terms, and allows terms to occur in formulas but not vice versa (with the exception of the IF-THEN-ELSE construct).
CVC4 drops the distinction between terms and formulas and defines the latter just as terms of type <math>\mathrm{BOOLEAN}</math>. As such, formulas can occur as subterms of possibly non-Boolean terms.

Example:

[To do]

==== The REAL Type ====

The <math>\mathrm{REAL}</math> type is interpreted as the set of real numbers.

Note that these are the (infinite precision) mathematical reals,
not the floating point numbers.
Support for floating point types is planned for future versions.

x, y : REAL;
QUERY (( x <= y ) AND ( y <= x )) => ( x = y );

==== The INT Type ====

The <math>\mathrm{INT}</math> type is interpreted as the set of integer numbers
and is considered as a subtype of <math>\mathrm{REAL}</math>.
The latter means in particular that it is possible to mix integer and real terms
in expressions without the need of an explicit ''upcasting'' operator.

Note that these are the (infinite precision) mathematical integers,
not the finite precision machine integers used in most programming languages.
The latter are models by [[ #Bitvectors | bit vector ]] types.

x, y : INT;
QUERY ((2 * x + 4 * y <= 1) AND ( y >= x)) => (x <= 0);
z : REAL;
QUERY (2 * x + z <= 3.5) AND (z >= 1);

==== Bit Vector Types ====

For every positive integer <math>n</math>, the type <math>\mathrm{BITVECTOR}(n)</math> is interpreted as the set of all bit vectors of size <math>n</math>.
A rich set of bit vector operators is supported.

==== User-defined Basic Types ====

Users can define new basic types
(often referred to as ''uninterpreted'' types in the SMT literature).
Each such type is interpreted as a set of unspecified cardinality
but disjoint from any other type.

User-defined basic types are created by declarations like the following:

% User declarations of basic types:

MyBrandNewType: TYPE;

Apples, Oranges: TYPE;

=== Structured Types ===

CVC4's structured types are divided in the following families.

==== Array Types ====

Array types are created by the mixfix type constructors <math>\mathrm{ARRAY}\ \_\ \mathrm{OF}\ \_</math>
whose arguments can be instantiated by any value type.

I : TYPE;

%% Array types:

% Arrays with indices from I and values from REAL
Array1: TYPE = ARRAY I OF REAL;

% Arrays with integer indices and array values
Array2: TYPE = ARRAY INT OF (ARRAY INT OF REAL);

% Arrays with integer pair indices and integer values
IntMatrix: TYPE = ARRAY [INT, INT] OF INT;

An array type of the form <math>\mathrm{ARRAY}\ T_1\ \mathrm{OF}\ T_2</math> is interpreted
as the set of all total maps from <math>T_1</math> to <math>T_2</math>.
The main difference with the function type <math>T_1 \to T_2</math> is that arrays,
contrary to functions, are first-class objects of the language, that is, values of an array
type can be arguments or results of functions.
Furthermore, array types come equipped with an update operation.

==== Tuple Types ====

Tuple types are created by the mixfix type constructors

<center>
<math>
\begin{array}{l} [\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ \ ,\ \_\ ] \\[1ex] \ldots \end{array}
</math>
</center>

whose arguments can be instantiated by any value type.

IntArray: TYPE = ARRAY INT OF INT;

% Tuple type declarations

RealPair: TYPE = [REAL, REAL]

MyTuple: TYPE = [ REAL, IntArray, [INT, INT] ];

A tuple type of the form <math>[T_1, \ldots, T_n]</math> is interpreted
as the Cartesian product <math>T_1 \times \cdots \times T_n</math>.

Note that while the types <math>(T_1, \ldots, T_n) \to T</math> and
<math>[T_1 \times \cdots \times T_n] \to T</math> are semantically equivalent,
they are operationally different in CVC4.
The first is the type of functions that take <math>n</math> arguments
of respective type <math>T_1</math>, <math>\ldots</math>, <math>T_n</math>,
while the second is the type of functions that take one argument of an <math>n</math>-tuple type.

==== Record Types ====

Similar to, but more general than tuple types, record types are created by type constructors of the form

<center>
<math>
[\#\ l_1: \_\ ,\ \ldots\ ,\ l_n: \_\ \#]
</math>
</center>

where <math>n > 0</math>, <math>l_1,\ldots, l_n</math> are field labels,
and the arguments can be instantiated with any first-order types.

MyType: TYPE;

% Record declaration

RecordType: TYPE = [# id: REAL, age: INT, info: MyType #];

The order of the fields in a record type is meaningful:
permuting the field names gives a different type.

Note that record types are non-recursive.
For instance, it is not possible to declare a record type called <code>Person</code> containing
a field of type <code>Person</code>.
Recursive types are provided in CVC4 by the more general inductive data types.
(As a matter of fact, both record and tuple types are implemented internally as inductive data types.)

==== Inductive Data Types ====

Inductive data types in CVC4 are similar to inductive data types of functional languages.
They can be parametric or not.

===== Non-Parametric Data Types =====

Non-parametric data types are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1 & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2 & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types, including any <math>A_i</math>.
Such declarations define the data types <math>A_1, \ldots, A_n</math>.
For each data type <math>A_i</math> they introduce:

* constructor symbols <math>cons</math> of type <math>(T_1, \ldots, T_k) \to \mathit{type\_name}_i</math>,
* selector symbols <math>\mathit{sel}_j</math> of type <math>\mathit{type\_name}_i \to T_j</math>, and
* tester symbols <math>\mathit{is\_cons}</math> of type <math>\mathit{type\_name}_i \to \mathrm{BOOLEAN}</math>.

Note that permitting more than one data type to be defined in the same declarations allows
the definition of mutually recursive types.

% simple enumeration type

% implicitly defined are the testers: is_red, is_yellow and is_blue
% (similarly for the other data types)

DATATYPE
PrimaryColor = red | yellow | blue
END;

% infinite set of pairwise distinct values ..., v(-1), v(0), v(1), ...

DATATYPE
Id = v (id: INT)
END;

% ML-style integer lists

DATATYPE
IntList = nil | ins (head: INT, tail: IntList)
END;

% AST for lamba calculus

DATATYPE
Term = var (index: INT)
| apply (arg_1: Term, arg_2: Term)
| lambda (arg: INT, body: Term)
END;

% Trees

DATATYPE
Tree = tree (value: REAL, children: TreeList),
TreeList = nil_tl
| ins_tl (first_t1: Tree, rest_t1: TreeList)
END;

Constructor, selector and tester symbols defined for a data type have global scope.
So, for example, it is not possible for two different data types to use
the same name for a constructor.

An inductive data type is interpreted as a term algebra constructed by the constructor symbols
over some sets of generators.
For example, the type <code>IntList</code> defined above is interpreted as the set
of all terms constructed with <code>nil</code> and <code>ins</code> over the integers.

===== Parametric Data Types =====

Parametric data types are infinite families of (non-parametric) data types
with each family parametrized by one or more type variables.
They are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1[X_{1,1}, \ldots, X_{1,p_1}] & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2[X_{2,1}, \ldots, X_{2,p_2}] & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n[X_{n,1}, \ldots, X_{n,p_n}] & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name parametrized by the type variables <math>X_{i,1}, \ldots, X_{i,p_i}</math>
and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types,
possibly parametrized by <math>X_1, \ldots, X_p</math>, including any <math>A_i</math>.

% Parametric pairs
DATATYPE [X, Y]
Pair[X, Y] = pair (first: X, second: Y)
END;

% Parametric lists

DATATYPE [X]
List[X] = nil | cons (head: X, tail: List[X])
END;

% Parametric trees using the list type above

DATATYPE [X]
Tree[X] = node (value: X, children: List[Tree[X]]),
END;

The declarations above define infinitely many types of the form
Pair[S,T], List[T] and Tree[T] where S and T are first-order types.
Note that the identifier <code>List</code> above, for example, by itself does not denote a type.
In contrast, the terms <code>List[Real]</code>, <code>List[List[Real]]</code>, <code>List[Tree[INT]]</code>,
and so on do.

===== Restriction to Inductive Types =====

By adopting a term algebra semantics, CVC4 allows only ''inductive'' data types,
that is, data types whose values are essentially (labeled, ordered) finite trees.
Infinite structures such as streams or even finite but cyclic ones
such as circular lists are then excluded.
For instance, none of the following declarations define inductive data types,
and are rejected by CVC4:

DATATYPE
IntStream = s (first:INT, rest: IntStream)
END;

DATATYPE
RationalTree = node1 (child: RationalTree)
| node2 (left_child: RationalTree, right_child:RationalTree)
END;

DATATYPE
T1 = c1 (s1: T2),
T2 = c2 (s2: T1)
END;

In concrete, a declaration of <math>n \geq 1</math> datatypes <math>T_1, \ldots, T_n</math> will be rejected if for any one of the types <math>T_1, \ldots, T_n</math>, it is impossible to build a finite term of that type using only the constructors of <math>T_1, \ldots, T_n</math> and free constants of type other than <math>T_1, \ldots, T_n</math>.

Inductive data types are the only types where the user also chooses names for the built-in operations to:

* construct a value of the type (with the constructors),
* extract components from a value (with the selectors), or
* check if a value was constructed with a certain constructor or not (with the testers).

For all the other types, CVC4 provides predefined names for the built-in operations on the type.

=== Function Types ===

Function (<math>\to</math>) types are created by the mixfix type constructors
<center>
<math>
\begin{array}{l}
\_ \to \_ \\[1ex] (\ \_\ ,\ \_\ ) \to \_
\\[1ex] (\ \_\ ,\ \_\ ,\ \_\ ) \to \_
\\[1ex] \ldots
\end{array}
</math>
</center>
whose arguments can be instantiated by any first-order type.

% Function type declarations

UnaryFunType: TYPE = INT -> REAL;

BinaryFunType: TYPE = (REAL, REAL) -> ARRAY REAL OF REAL;

TernaryFunType: TYPE = (REAL, BITVECTOR(4), INT) -> BOOLEAN;

A function type of the form <math>(T_1, \ldots, T_n) \to T</math> with <math>n > 0</math> is interpreted as the set of all ''total'' functions from the Cartesian product <math>T_1 \times \cdots \times T_n</math> to <math>T</math>.

The example above also shows how to introduce type names.
A name like <code>UnaryFunType</code> above is just an abbreviation for the type <math>\mathrm{INT} \to \mathrm{REAL}</math> and can be used interchangeably with it.

In general, any type defined by a type expression <code>E</code> can be given a name with the declaration:

name : TYPE = E;

=== Type Checking ===

In CVC4, formulas and terms are statically typed at the level of types
(as opposed to subtypes) according to the usual rules of first-order many-sorted logic,
with the main difference that formulas are just terms of type <math>BOOLEAN</math>:

* each variable has one associated first-order type,
* each constant symbol has one or more associated first-order types,
* each function symbol has one or more associated function types,
* the type of a term consisting just of a variable is the type associated to that variable,
* the type of a term consisting just of a constant symbol is the type associated to that constant symbol,
* the term obtained by applying a function symbol <math>f</math> to the terms <math>t_1, \ldots, t_n</math> is <math>T</math> if <math>f</math> has type <math>(T_1, \ldots, T_n) \to T</math> and each <math>t_i</math> has type <math>T_i</math>.

Attempting to enter an ill-typed term will result in an error.

Another significant difference with standard many-sorted logic is that
some built-in symbols are parametrically polymorphic.
For instance, the function symbol for extracting the element of any array has
type <math>(\mathit{ARRAY}\ T_1\ \mathit{OF}\ T_2,\; T_1) \to T_2</math>
for all first-order types <math>T_1, T_2</math>.

==== Type Ascription ====

By the type inference rules above some terms might have more than one type.
This can happen with terms built with polymorphic data type constructors
that have more than one return type for the same input type.
In that case, a type ascription operator (<code>::</code>) must be applied
to the constructor to specify the intended return type.

DATATYPE [X]
List[X] = nil | cons (head: X, tail: List[X])
END;

ASSERT y = cons(1, nil::List[REAL]);

DATATYPE [X, Y]
Union[X, Y] = left(val_l: X) | right(val_r: Y)
END;

ASSERT y = left::Union[BOOLEAN, REAL](TRUE);

The constant symbol <math>\mathrm{nil}</math> declared above has infinitely many types
(<math>\mathrm{List}[\mathrm{REAL}]</math>, <math>\mathrm{List}[\mathrm{BOOLEAN}]</math>,
<math>\mathrm{List}[[\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{List}[\mathrm{List}[\mathrm{REAL}]]</math>, ...)
CVC4's type checker requires the user to indicate explicitly the type
of each occurrence of <code>nil</code> in a term.
Similarly,
the injection operator <code>left</code> has infinitely many return types
for the same input type, for instance:
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{REAL}]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, [\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{List}[\mathrm{REAL}]]</math>,
and so on.
Applications of <code>left</code> need to specify the intended returned typed, as shown above.

== Terms and Formulas ==

In addition to type expressions, CVC4 has expressions for terms and for formulas
(i.e., terms of type <math>\mathrm{BOOLEAN}</math>).
By and large, these are standard first-order terms built out of typed variables,
predefined theory-specific operators, free (i.e., user-defined) function symbols,
and quantifiers.
Extensions include an if-then-else operator, lambda abstractions, and local symbol
declarations, as illustrated below.
Note that these extensions still keep CVC4's language first-order.
In particular, lambda abstractions are restricted to take and return only terms of
a first-order type.
Similarly, variables can only be of a first-order type.

A number of built-in function symbols (for instance, the arithmetic ones) are used
as infix operators. All user-defined symbols are used as prefix ones.

User-defined, i.e., free, function symbols include ''constant symbols'' and
''predicate symbols'', respectively nullary function symbols and function symbols
with a <math>\mathrm{BOOLEAN}</math> return type.
These symbols are introduced with global declarations of the form
<math> f_1, \ldots, f_m: T;</math>
where <math>m > 0</math>, <math>f_i</math> are the names of the symbols and
<math>T</math> is their type:

% integer constants

a, b, c: INT;

% real constants

x, y, z: REAL;

% unary function

f1: REAL -> REAL;

% binary function

f2: (REAL, INT) -> REAL;

% unary function with a tuple argument

f3: [INT, REAL] -> BOOLEAN;

% binary predicate

p: (INT, REAL) -> BOOLEAN;

% Propositional "variables"

P, Q; BOOLEAN;

Like type declarations, function symbol declarations like the above have global scope
and must be unique.
In other words, it is not possible to declare a function symbol globally more than once
in the same lexical scope.
This entails among other things that globally-defined free symbols cannot be overloaded
with different types and that theory symbols cannot be redeclared globally as free symbols.

=== Global symbol definitions ===

As with types, a function symbol can be defined as the name of another term
of the corresponding type.
With constant symbols, this is done with a declaration of the form <math>f:T = t;</math> :

c: INT;

i: INT = 5 + 3*c; % i is effectively a shorthand for 5 + 3*c

j: REAL = 3/4;

t: [REAL, INT] = (2/3, -4);

r: [# key: INT, value: REAL #] = (# key := 4, value := (c + 1)/2 #);

f: BOOLEAN = FORALL (x:INT): x <= 0 OR x > c ;

A restriction on constants of type <math>\mathit{BOOLEAN}</math> is that their value
can only be a closed formula, that is, a formula with no free variables.

A term and its name can be used interchangeably in later expressions.
Named terms are often useful for shared subterms (terms used several times in different places)
since their use can make the input exponentially more concise.
Named terms are processed very efficiently by CVC4.
It is much more efficient to associate a complex term with a name directly rather than
to declare a constant and later assert that it is equal to the same term.
This point is explained in more detail later in section [[Commands | Commands]].

More generally, in CVC4 one can associate a term to function symbols of any arity.
For non-constant function symbols this is done with a declaration of the form

<center>
<math>f:(T_1, \ldots, T_n) \to T = \mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t\;;</math>
</center>

where <math>t</math> is any term of type <math>T</math> with free variables
in <math>\{x_1, \ldots, x_n\}</math>.
The lambda binder has the usual semantics and conforms to the usual lexical scoping rules:
within the term <math>t</math> the declaration of the symbols <math>x_1, \ldots, x_n</math>
as local variables of respective type <math>T_1, \ldots, T_n</math> hides any previous
declarations of those symbols that are in scope.

As a general shorthand, when <math>k</math> consecutive types
<math>T_i, \ldots, T_{i+k-1}</math> in the lambda expression
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t</math> are identical, the syntax
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x_i,\ldots, x_{i+k-1}:T_i,\ldots, x:T_n): t</math>
can also be used.

% Global declaration of x as a unary function symbol

x: REAL -> REAL;

% Local declarations of x as variable (hiding the global one)

f: REAL -> REAL = LAMBDA (x: REAL): 2*x + 3;

p: (INT, INT) -> BOOLEAN = LAMBDA (x,i: INT): i*x - 1 > 0;

g: (REAL, INT) -> [REAL, INT] = LAMBDA (x: REAL, i:INT): (x + 1, i - 3);

Note that lambda definitions are not recursive:
the symbol being defined cannot occur in the body of the lambda term.
They should be understood as macros.
For instance, any occurrence of the term <math>f(t)</math>
where <math>f</math> is as defined above will be treated
as if it was the term <math>(2*t + 3)</math>.

=== Local symbol definitions ===

Constant and function symbols can also be declared locally anywhere within a term
by means of a let binder.
This is done with a declaration of the form

<center>
<math>
\mathrm{LET}\ f = t \ \mathrm{IN}\ t' ;
</math>
</center>

where <math>t</math> is a term with no free variables, possibly a lambda term.
Let binders can be nested arbitrarily and follow the usual lexical scoping rules.
The following general form
<center>
<math>
\mathrm{LET}\ f_1 = t_1, f_2 = t_2, \ldots, f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>
can be use above can used as a shorthand for
<center>
<math>
\mathrm{LET}\ f_1 = t_1\ \mathrm{IN}\
\mathrm{LET}\ f_2 = t_2\ \mathrm{IN}\
\ldots \
\mathrm{LET}\ f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>

t: REAL =
LET x1 = 42,
g = LAMBDA(x:INT): x + 1,
x2 = 2*x1 + 7/2
IN
(LET x3 = g(x1) IN x3 + x2) / x1;

Note that the same symbol = is used, unambiguously, in the syntax of global declarations,
let declarations, and as a predicate symbol.

'''Note:'''
A <math>\mathrm{LET}</math> term with a multiple symbols defines them sequentially.
A parallel version of the <math>\mathrm{LET}</math> construct will be introduced in a later version.

== Built-in theories and their symbols ==

In addition to user-defined symbols, CVC4 terms can use a number of predefined symbols:
the logical symbols, such as <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, etc.,
as well as theory symbols, function symbols belonging to one of the built-in theories.
They are described next, with the theory symbols grouped by theory.

=== Logical Symbols ===

The logical symbols in CVC4's language include
the equality and disequality predicate symbols, respectively written as = and /=,
the multiarity disequality symbol <math>\mathrm{DISTINCT}</math>,
together with the logical constants <math>\mathrm{TRUE}</math>, <math>\mathrm{FALSE}</math>,
the connectives <math>\mathrm{NOT}</math>, <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, <math>\mathrm{XOR}</math>, <math>\Rightarrow</math>, <math>\Leftrightarrow</math>, and
the first-order quantifiers <math>\mathrm{EXISTS}</math> and <math>\mathrm{FORALL}</math>,
all with the standard many-sorted logic semantics.

The binary connectives have infix syntax and type
<math>(\mathrm{BOOLEAN},\mathrm{BOOLEAN}) \to \mathrm{BOOLEAN}</math>.
The symbols = and /=, which are also infix, are instead parametrically polymorphic,
having type <math>(T,T) \to \mathrm{BOOLEAN}</math>
for every first-order type <math>T</math>.
They are interpreted respectively as the identity relation and its complement.

The DISTINCT symbol is both overloaded and polymorphic.
It has type <math>(T,...,T) \to \mathrm{BOOLEAN}</math>
for every sequence <math>(T,...,T)</math> of length <math>n > 0</math>
and first-order type <math>T</math>.
For each <math>n > 0</math>, it is interpreted as the relation
that holds exactly for tuples of pairwise distinct elements.

The syntax for quantifiers is similar to that of the lambda binder.

Here is an example of a formula built just of these logical symbols and variables:

A, B: TYPE;

q: BOOLEAN = FORALL (x,y: A, i,j,k: B):
i = j AND i /= k => EXISTS (z: A): x /= z OR z /= y;

Binding and scoping of quantified variables follows the same rules as
in let expressions.
In particular, a quantifier will shadow in its scope any constant and function symbols
with the same name as one of the variables it quantifies:

A: TYPE;
i, j: INT;

% The first occurrence of i and of j in f are constant symbols,
% the others are variables.

f: BOOLEAN = i = j AND FORALL (i,j: A): i = j OR i /= j;

Optionally, it is also possible to specify instantiation patterns
for quantified variables.
The general syntax for a quantified formula <math>\psi</math> with patterns is

<center>
<math>
Q\;(x_1:T_1, \ldots, x_k:T_k):\; p_1: \ldots\; p_n:\; \varphi
</math>
</center>

where <math>n \geq 0</math>, <math>Q</math> is
either <math>\mathrm{FORALL}</math> or <math>\mathrm{EXISTS}</math>,
<math>\varphi</math> is a term of type <math>\mathrm{BOOLEAN}</math>,
and each of the <math>p_i</math>'s,
a pattern for the quantifier <math>Q\;(x_1:T_1, \ldots, x_k:T_k)</math>, has the form

<center>
<math>
\mathrm{PATTERN}\; (t_1, \ldots, t_m)
</math>
</center>

where <math>m > 0</math> and <math>t_1, \ldots, t_m</math> are
arbitrary binder-free terms (no lets, no quantifiers).
Those terms can contain (free) variables, typically, but not exclusively,
drawn from <math>x_1, \ldots, x_k</math>.
(Additional variables can occur if <math>\psi</math> occurs in a bigger formula
binding those variables.)

A: TYPE;
b, c: A;
p, q: A -> BOOLEAN;
r: (A, A) -> BOOLEAN;

ASSERT FORALL (x0, x1, x2: A):
PATTERN (r(x0, x1), r(x1, x2)):
(r(x0, x1) AND r(x1, x2)) => r(x0, x2) ;

ASSERT FORALL (x: A):
PATTERN (r(x, b)):
PATTERN (r(x, c)):
p(x) => q(x) ;

ASSERT EXISTS (y: A):
FORALL (x: A):
PATTERN (r(x, y), p(y)):
r(x, y) => q(x) ;

Patterns have no logical meaning:
adding them to a formula does not change its semantics.
Their purpose is purely operational, as explained in
the [[#Instantiation Patterns | Instantiation Patterns]] section.

In addition to these constructs, CVC4 also has a general mixfix conditional operator
of the form

<center>
<math>
\mathrm{IF}\ b\ \mathrm{THEN}\ t\ \mathrm{ELSIF}\ b_1\ \mathrm{THEN}\ t_1\ \ldots\ \mathrm{ELSIF}\ b_n\ \mathrm{THEN}\ t_n\ \mathrm{ELSE}\ t_{n+1}\ \mathrm{ENDIF}
</math>
</center>

with <math>n \geq 0</math> where
<math>b, b_1, \ldots, b_n</math> are terms of type <math>\mathrm{BOOLEAN}</math> and
<math>t, t_1, \ldots, t_n, t_{n+1}</math> are terms of the same first-order type <math>T</math>:

% Conditional term
x, y, z, w: REAL;

t: REAL =
IF x > 0 THEN y
ELSIF x >= 1 THEN z
ELSIF x > 2 THEN w
ELSE 2/3 ENDIF;

=== User-defined Functions and Types ===

The theory of user-defined functions,also know in the SMT literature as
the theory ''Equality over Uninterpreted Functions'', or ''EUF'', is in effect
a family of theories of equality parametrized by the basic types and the free symbols
a user can define during a run of CVC4.

This theory has no built-in symbols (other than the logical ones).
Its types consist of ''all and only'' the user-defined types.
Its function symbols consist of ''all and only'' the user-defined free symbols.

=== Arithmetic ===

The real arithmetic theory has two types:
<math>\mathrm{REAL}</math> and <math>\mathrm{INTEGER}</math>
with the latter a subtype of the first.
Its built-in symbols for the usual arithmetic constants
and operators over the type <math>\mathrm{REAL}</math>, each with the expected type:
all numerals 0, 1, ..., as well as - (both unary and binary), +, *, /, <, >, <=, >=.
Application of the binary symbols are in infix form.
Note that + is only binary, and so an expression such as +4 is ill-formed.

Rational values can be expressed in decimal or fractional format,
e.g., 0.1, 23.243241, 1/2, 3/4, and so on.
A leading 0 is mandatory for decimal numbers smaller than one
(e.g., the syntax .3 cannot be used as a shorthand for 0.3).
However, a trailing 0 is ''not'' required for decimals that are whole numbers
(e.g., 3. is allowed as a shorthand for 3.0).
The size of the numerals used in the representation of natural and rational numbers
is unbounded; more accurately, bounded only by the amount of available memory.

=== Bit vectors ===

=== Arrays ===

The theory of arrays is a parametric theory of (total) unary maps.
It comes equipped with mixfix polymorphic selection and update operators, respectively
<center>
<math>\_[\_]</math> and <math>\_\ \mathrm{WITH}\ [\_]\ := \_</math> .
</center>
The semantics of these operators is the expected one:
for all first-order types <math>T_1</math> and <math>T_2</math>,
if <math>a</math> is of type <math>\mathrm{ARRAY}\ T_1 \mathrm{OF}\ T_2</math>,
<math>i</math> is of type <math>T_1</math>, and
<math>v</math> is of type <math>T_2</math>,
* <math>a[i]</math> denotes the value that <math>a</math> associates to index <math>i</math>,
* <math>a\ \mathrm{WITH}\ [i]\ := v</math> denotes a map that associates <math>v</math> to index <math>i</math> and is otherwise identical to <math>a</math>.
Sequential updates can be chained with the shorthand syntax
<math>\_\ \mathrm{WITH}\ [\_]\ := \_, \ldots, [\_]\ := \_</math>.

A: TYPE = ARRAY INT OF REAL;
a: A;
i: INT = 4;

% selection:

elem: REAL = a[i];

% update

a1: A = a WITH [10] := 1/2;

% sequential update
% (syntactic sugar for (a WITH [10] := 2/3) WITH [42] := 3/2)

a2: A = a WITH [10] := 2/3, [42] := 3/2;

Since arrays are just maps, equality between them is extensional, that is,
for two arrays of the same type to be different they have to map at least one
index to differ values.

=== Data types ===

The theory of inductive data types is in fact a family of theories parametrized
by a data type declaration specifying constructors and selectors
for one or more user-defined data types.

No built-in operators other than equality and disequality are provided
for this family in the native language.
Each user-provided data type declaration, however, generates constructor, selector and tester operators
as described in the [[#Inductive Data Types | Inductive Data Types]] section.

=== Tuples and Records ===

Semantically both records and tuples can be seen as special instances
of inductive data types.
CVC4 implements them internally indeed as data types.
In essence, a record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math>
is encoded as a data type of the form

<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\ \ \mathrm{Record} = \mathit{rec}(l_0:T_0, \ldots, l_n:T_n) \\
\mathrm{END};
\end{array}
</math>
</center>

Tuples of length <math>n</math> are in turn special cases of records whose field names are
the numerals from <math>0</math> to <math>n-1</math>.

Externally, tuples and records have their own syntax for constructor and selector operators.
* Records of type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> have the associated record constructor <math>(\#\ l_0 := \_,\; \ldots,\; l_n := \_\ \#)</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.
* Tuples of type <math>[\ T_0, \ldots, T_n\ ]</math> have the associated tuple constructor <math>(\ \_,\; \ldots,\; \_\ )</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.

The selector operators on records and tuples follows a dot notation syntax.

% Record construction and field selection
Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);
k: INT = x.key;
v: REAL = x.weight;

% Tuple construction and projection
y: [REAL, INT, REAL] = ( 4/5, 9, 11/9 );
first_elem: REAL = y.0;
third_elem: REAL = y.2;

Differently from data types, records and tuples are also provided with built-in update operators similar in syntax and semantics to the update operator for arrays.
More precisely, for each record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .l_i\ := \_
</math>
</center>

The operator maps a record <math>r</math> of that type and a value <math>v</math>
of type <math>T_i</math> to the record that stores <math>v</math> in field <math>l_i</math>
and is otherwise identical to <math>r</math>.
Analogously, for each tuple type <math>[T_0, \ldots, T_n]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .i\ := \_
</math>
</center>

with similar semantics.

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = x WITH .weight := 48;

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = y WITH .1 := 3;

Updates to a nested component can be combined in a single WITH operator:

Cache: TYPE = ARRAY [0..100] OF [# addr: INT, data: REAL #];
State: TYPE = [# pc: INT, cache: Cache #];

s0: State;
s1: State = s0 WITH .cache[10].data := 2/3;

Note that, differently from updates on arrays, tuple and record updates are
just additional syntactic sugar.
For instance, the record <code>x1</code> and tuple <code>y1</code> defined above
could have been equivalently defined as follows:

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = (# key := x.key, weight := 48 #);

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = ( y.0, 3, y.1 );

== Commands ==

In addition to declarations of types and function symbols,
the CVC4 native language contains the following commands:

* <math>\mathrm{ASSERT}\ F</math> -- Add the formula <math>F</math> to the current logical context <math>\Gamma</math>.
* [[#CHECKSAT|<math>\mathrm{CHECKSAT}\ F</math>]] -- Check if the formula <math>F</math> is satisfiable in the current logical context (<math>\Gamma \not\models_T \mathrm{NOT}\ F</math>).
* <math>\mathrm{CONTINUE}</math> -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, search for a counter-example different from the current one.
* [[#COUNTEREXAMPLE|<math>\mathrm{COUNTEREXAMPLE}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print the context that is a witness for invalidity/satisfiability.
* [[#COUNTERMODEL|<math>\mathrm{COUNTERMODEL}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print a model that makes the formula invalid/satisfiable. The model is provided in terms of concrete values for each free symbol.
* <math>\mathrm{OPTION}\ o\ v</math> -- Set the command-line option flag <math>o</math> to value <math>v</math>. The argument <math>o</math> is provide as a string literal enclosed in double-quotes and <math>v</math> as an integer value.
* <math>\mathrm{POP}</math> -- Equivalent to <math>\mathrm{POPTO}\ 1</math>
* [[#POPTO|<math>\mathrm{POPTO}\ n</math>]] -- Restore the system to the state it was in right before the most recent call to <math>\mathrm{PUSH}</math> made from stack level <math>n</math>. Note that the current stack level is printed as part of the output of the <math>\mathrm{WHERE}</math> command.
* <math>\mathrm{PUSH}</math> -- Save (checkpoint) the current state of the system.
* [[#QUERY|<math>\mathrm{QUERY}\ F</math>]] -- Check if the formula <math>F</math> is valid in the current logical context (<math>\Gamma\models_T F</math>).
* [[#RESTART|<math>\mathrm{RESTART}\ F</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, repeat the check but with the additional assumption <math>F</math> in the context.
* <math>\mathrm{PRINT}\ t</math> -- Parse and print back the term <math>t</math>.
* <math>\mathrm{TRANSFORM}\ t</math> -- Simplify the term <math>t</math> and print the result.
* <math>\mathrm{WHERE}</math> -- Print all the formulas in the current logical context <math>\Gamma</math>.

The remaining commands take a single argument, given as a string literal enclosed in double-quotes.

* <math>\mathrm{ECHO}\ s</math> -- Print string <math>s</math>
* <math>\mathrm{INCLUDE}\ f</math> -- Read commands from file <math>f</math>.
* <math>\mathrm{TRACE}\ f</math> -- Turn on tracing for the debug flag <math>f</math>.
* <math>\mathrm{UNTRACE}\ f</math> -- Turn off tracing for the debug flag <math>f</math>.

Here, we explain some of the above commands in more detail.

=== QUERY ===

The command <math>\mathrm{QUERY}\ F</math> invokes the core functionality of CVC4 to check
the validity of the formula <math>F</math> with respect to the assertions made thus far,
which constitute the context <math>\Gamma</math>.
The argument <math>F</math> must be well typed term of type <math>\mathrm{BOOLEAN}</math>,
as described in [[#Terms and Formulas | Terms and Formulas]].

The execution of this command always terminates and produces one of three possible answers:
<code>valid</code>, <code>invalid</code>, and <code>unknown</code>.

* A <code>valid</code> answer indicates that <math>\Gamma \models_T F</math>. After a query returning such an answer, the logical context <math>\Gamma</math> is exactly as it was before the query.
* An <code>invalid</code> answer indicates that <math>\Gamma \not\models_T F</math>, that is, there is a model of the background theory <math>T</math> that satisfies <math>\Gamma \cup \{\mathrm{NOT}\ F\}</math>. When <math>\mathrm{QUERY}\ F</math> returns <code>invalid</code>, the logical context <math>\Gamma</math> is augmented with a set <math>\Delta</math> of ground (i.e., variable-free) literals such that <math>\Gamma\cup\Delta</math> is satisfiable in <math>T</math>, but <math>\Gamma\cup\Delta\models_T \mathrm{NOT}\ F</math>. In fact, in this case <math>\Delta</math> ''propositionally entails'' <math>\mathrm{NOT}\ F</math>, in the sense that, every truth assignment to the literals of <math>\Delta</math> that satisfies <math>\Delta</math> falsifies <math>F</math>. We call the new context <math>\Gamma\cup\Delta</math> a ''counterexample'' for <math>F</math>.
* An <code>unknown</code> answer is similar to an <code>invalid</code> answer in that additional literals are added to the context which propositionally entail <math>\mathrm{NOT}\ F</math>. The difference in this case is that CVC4 cannot guarantee that <math>\Gamma\cup\Delta</math> is actually satisfiable in <math>T</math>.

CVC4 may report <code>unknown</code> when the context or the query contains
non-linear arithmetic terms or quantifiers.
In all other cases, it is expected to be sound and complete,
i.e., to report <code>Valid</code> if <math>\Gamma \models_T F</math>
and <code>Invalid</code> otherwise.

After an <code>invalid</code> (resp. <code>unknown</code>) answer,
counterexamples (resp. possible counterexamples) can be obtained with
a <math>\mathrm{WHERE}</math>, <math>\mathrm{COUNTEREXAMPLE}</math>,
or <math>\mathrm{COUNTERMODEL}</math> command.


Since the <math>\mathrm{QUERY}</math> command may modify
the current context, if one needs to check several formulas in a row
in the same context, it is a good idea to surround every
query by a <math>\mathrm{PUSH}</math> and <math>\mathrm{POP}</math> invocation
in order to preserve the context:

PUSH;
QUERY <formula>;
POP;

=== CHECKSAT ===

The command <math>\mathrm{CHECKSAT}\ F</math> behaves identically
to <math>\mathrm{QUERY}\ \mathrm{NOT}\ F</math>.

=== RESTART ===

The command <math>\mathrm{RESTART}\ F</math> can only be invoked after an invalid query.
For example, in an interactive setting:

QUERY <formula>;

CVC4> invalid

RESTART <formula2>;

Functionally, the behavior of the above command sequence is identical to the following:

PUSH;
QUERY <formula>;
POP;
ASSERT <formula2>;
QUERY <formula>;

The advantage of using the <math>\mathrm{RESTART}</math> command is that
the first command sequence may be executed much more efficiently that the second.
The reason is that with <math>\mathrm{RESTART}</math> CVC4 will re-use
what it has learned while answering the previous query rather than starting
over from scratch.

=== COUNTERMODEL ===

[More]

=== COUNTEREXAMPLE ===

[More]

=== POPTO ===

[More]

== Instantiation Patterns ==

CVC4 processes each universally quantified formula in the current context
by adding instances of the formula obtained by replacing its universal variables
with ground terms.
Patterns restrict the choice of ground terms for the quantified variables,
with the goal of controlling the potential explosion of ground instances.
In essence, adding patterns to a formula is a way for the user to tell CVC4
to focus only on certain instances which, in the user's opinion, will be
most helpful during a proof.

In more detail, patterns have the following effect on formulas that are found
in the logical context or get added to it later while CVC4 is trying to prove
the validity of some formula <math>F</math>.

If a formula in the current context starts with an existential quantifier,
CVC4 ''Skolemizes'' it, that is, replaces it in the context with the formula
obtained by substituting the existentially quantified variables
by fresh constants and dropping the quantifier.
Any patterns for the existential quantifier are simply ignored.

If a formula starts with a universal quantifier
<math>\mathrm{FORALL}\; (x_1:T_1, \ldots, x_n:T_n)</math>,
CVC4 adds to the context a number of instances of the formula,
with the goal of using them to prove the query <math>F</math> valid.
An instance is obtained by replacing each <math>x_i</math> with a ground term
of the same type occurring in one of the formulas in the context,
and dropping the universal quantifier.
If <math>x_i</math> occurs in a pattern
<math>\mathrm{PATTERN}\; (t_1, \ldots, t_m)</math> for the quantifier,
it will be instantiated only with terms obtained by simultaneously matching
all the terms in the pattern against ground terms in the current context
<math>\Gamma</math>.

Specifically, the matching process produces one or more substitutions
<math>\sigma</math> for the variables in <math>(t_1, \ldots, t_m)</math>
which satisfy the following invariant:
for each <math>i = 1, \ldots, m</math>, <math>\sigma(t_i)</math> is
a ground term and there is a ground term <math>s_i</math> in <math>\Gamma</math>
such that <math>\Gamma \models_T \sigma(t_i) = s_i</math>.
The variables of <math>(x_1:T_1, \ldots, x_n:T_n)</math> that occur
in the pattern are instantiated only with those substitutions
(while any remaining variables are instantiated arbitrarily).

The Skolemized version or the added instances of a context formula may themselves
start with a quantifier.
The same instantiation process is applied to them too, recursively.

Note that the matching mechanism is not limited to syntactic matching
but is modulo the equations asserted in the context.
Because of decidability and/or efficiency limitations, the matching process
is not exhaustive.
CVC4 will typically miss some substitutions that satisfy the invariant above.
As a consequence, it might fail to prove the validity of the query formula
<math>F</math>, which makes CVC4 incomplete for contexts containing
quantified formulas.
It should be noted though that exhaustive matching, which can be achieved
simply by not specifying any patterns, does not yield completeness anyway
since the instantiation of universal variables is still restricted
to just the ground terms in the context,
whereas in general additional ground terms might be needed.

User Manual

2012-11-30T23:13:45Z

Tinelli: /* CVC4's input languages */

This manual includes information on installing and using CVC4. It is a work in progress.

=Getting CVC4=

Both pre-compiled binaries and the source code for CVC4 are available for download from [http://cvc4.cs.nyu.edu/builds/ http://cvc4.cs.nyu.edu/builds/].

==Getting CVC4 binaries==
The most recent binaries can be downloaded from our Nightly Builds pages:
* [http://cvc4.cs.nyu.edu/builds/x86_64-linux-opt/ Optimized] binaries (statically linked)
* [http://cvc4.cs.nyu.edu/builds/x86_64-linux-dbg/ Debug] binaries (statically linked)
* [http://cvc4.cs.nyu.edu/builds/debian/unstable Debian] packages

To install CVC4 on an Ubuntu Machine follow the instructions below. First add the CVC4 respository to /etc/apt/source.list by inserting the following two lines at the end of the file:
# CVC4 repository
deb http://cvc4.cs.nyu.edu/debian/ unstable/
deb-src http://cvc4.cs.nyu.edu/debian/ unstable/

To run CVC4 as a binary you only need the first line but to use the library API you will also need the source package.
Make sure to update the respository list by running:

sudo apt-get update

Now you can simply install CVC4 as you would any other piece of sofware using the command:
sudo apt-get install cvc4

If you want to use CVC4 as a library also install the following packages: libcvc4-dev, and libcvc4-parser-dev.

==Building CVC4 from source==
[http://cvc4.cs.nyu.edu/builds/src/ Sources are available] from the same site as the binaries. The source-code is also available in the [http://cvc4.cs.nyu.edu/builds/src/ CVC4 source repository] which is currently hosted by [http://cims.nyu.edu/ CIMS] and therefore requires a CIMS account. Please contact a member of the development team for access.

To build CVC4 from source the following steps are required. After downloading the source files first install antlr by running the following script in the CVC4 contrib directory:
cd contrib
./get-antlr-3.4

The next step is to configure CVC4:
cd ..
./configure --with-antlr-dir=`pwd`/antlr-3.4 ANTLR=`pwd`/antlr-3.4/bin/antlr3

And then finally compile it:
make
make check [recommended]
make install [optional]

For a comprehensive list of dependencies and more detailed build instructions see [[Building CVC4 from source]].

=Using the CVC4 binary=

Once installed, the CVC4 driver binary ("cvc4") can be executed to directly enter into interactive mode:

$ cvc4
cvc4 1.0 assertions:off
CVC4>

You can then enter commands into CVC4 interactively:

CVC4> OPTION "incremental";
CVC4> OPTION "produce-models";
CVC4> TRANSFORM 25*25;
625
CVC4> x, y : INT;
CVC4> QUERY x = y;
invalid
CVC4> COUNTERMODEL;
x : INT = -1;
y : INT = 0;
CVC4> ASSERT x >= 0;
CVC4> QUERY x = y;
invalid
CVC4> COUNTERMODEL;
x : INT = 0;
y : INT = 1;
CVC4>

The above example shows two useful options, ''incremental'' and ''produce-models.''

* The ''incremental'' option allows you to issue multiple QUERY (or CHECKSAT) commands, and allows the use of the PUSH and POP commands. Without this option, CVC4 optimizes itself for a single QUERY or CHECKSAT command (though you may issue any number of ASSERT commands). The ''incremental'' option may also be given by passing the ''-i'' command line option to CVC4.
* The ''produce-models'' option allows you to query the model (here, with the COUNTERMODEL command) after an "invalid" QUERY (or "satisfiable" CHECK-SAT). Without it, CVC4 doesn't do the bookkeeping necessary to support model generation. The ''produce-models'' option may also be given by passing the ''-m'' command line option to CVC4.

So, if you invoke CVC4 with ''-im'', you don't need to pass those options at all:

$ cvc4 -im
cvc4 1.0 assertions:off
CVC4> x, y : INT;
CVC4> QUERY x = y;
invalid
CVC4> COUNTERMODEL;
x : INT = -1;
y : INT = 0;
CVC4> ASSERT x >= 0;
CVC4> QUERY x = y;
invalid
CVC4> COUNTERMODEL;
x : INT = 0;
y : INT = 1;
CVC4>

By default, CVC4 operates in [[#CVC4's native input language|CVC-language mode]]. If you enter something that looks like SMT-LIB, it will suggest that you use the "''--lang smt''" command-line option for SMT-LIB mode:

CVC4> (declare-fun x () Int)
Parse Error: <shell>:1.7: In CVC4 presentation language mode, but SMT-LIB format detected. Use --lang smt for SMT-LIB support.
CVC4>

==Verbosity==

CVC4 has various levels of verbosity. By default, CVC4 is pretty quiet, only reporting serious warnings and notices. If you're curious about what it's doing, you can pass CVC4 the ''-v'' option:

$ cvc4 -v file.smt2
Invoking: (set-logic AUFLIRA)
Invoking: (set-info :smt-lib-version 2.000000)
Invoking: (set-info :category "crafted")
Invoking: (set-info :status unsat)
Invoking: (declare-fun x () Real)
''etc...''

For even more verbosity, you can pass CVC4 an ''additional'' ''-v'':

$ cvc4 -vv file.smt2
Invoking: (set-logic AUFLIRA)
Invoking: (set-info :smt-lib-version 2.000000)
Invoking: (set-info :category "crafted")
Invoking: (set-info :status unsat)
Invoking: (declare-fun x () Real)
''etc...''
expanding definitions...
constraining subtypes...
applying substitutions...
simplifying assertions...
doing static learning...
''etc...''

Internally, verbosity is just an integer value. It starts at 0, and with every ''-v'' on the command line it is incremented; with every ''-q'', decremented. It can also be set directly. From CVC language:

CVC4> OPTION "verbosity" 2;

Or from SMT-LIB language:

CVC4> (set-option :verbosity 2)

==Getting statistics==

Statistics can be dumped on exit (both normal and abnormal exits) with the ''--statistics'' command line option.

$ cvc4 --statistics foo.smt2
sat
sat::decisions, 0
sat::propagations, 3
sat::starts, 1
theory::uf::TheoryUF::functionTermsCount, 2
theory::uf::TheoryUF::mergesCount, 2
theory::uf::TheoryUF::termsCount, 6
theory<THEORY_UF>::propagations, 1
driver::filename, foo.smt2
driver::sat/unsat, sat
driver::totalTime, 0.02015373
''[many others]''

Many statistics name-value pairs follow, one comma-separated pair per line.

==Exit status==

The exit status of CVC4 depends on the ''last'' QUERY or CHECK-SAT. If you wish to call CVC4 from a program (e.g., a shell script) and care only about the satisfiability or validity of a single formula, you can pass the ''-q'' option (as described [[#Verbosity|above, under verbosity]]) and check the exit code. With ''-q'', CVC4 should not produce any output unless it encounters a fatal error.

QUERY asks a validity question, and CHECK-SAT a satisfiability question, and these are dual problems; hence the terminology is different, but really "sat" and "invalid" are the same internally, as are "unsat" and "valid":

<table border="1">
<tr><th>Solver's last result</th><th>Exit code</th><th>Notes</th></tr>
<tr><td>'''sat''' or '''invalid'''</td><td>10</td></tr>
<tr><td>'''unsat''' or '''valid'''</td><td>20</td></tr>
<tr><td>'''unknown'''</td><td>0</td><td>could be for any reason: time limit exceeded, no memory, incompleteness..</td></tr>
<tr><td>''no result''</td><td>0</td><td>no query or check-sat command issued</td></tr>
<tr><td>parse errors</td><td>0 (in interactive mode)<br/>1 (otherwise)</td><td>see below</td></tr>
<tr><td>other errors</td><td>1 (usually)</td><td>see below</td></tr>
</table>

Most "normal errors" return a 1 as the exit code, but out of memory conditions, and others, can produce different exit codes. In interactive mode, parse errors are ignored and the next line read; so in interactive mode, you may see an exit code of 0 even in the presence of such an error.

In SMT-LIB mode, an SMT-LIB command script that sets its status via "set-info :status" also affects the exit code. So, for instance, the following SMT-LIB script returns an exit code of 10 even though it contains no "check-sat" command:

(set-logic QF_UF)
(set-info :status sat)
(exit)

Without the "set-info," it would have returned an exit code of 0.

=CVC4's input languages=

When not used in interactive mode, CVC4 can read its input from an external file. It accepts the following input languages:

* [[CVC4's native language | CVC4's native language]]
* SMT-LIB 2.0 (see [http://www.grammatech.com/resources/smt/SMTLIBTutorial.pdf David Cok's SMT-LIB tutorial])
* SMT-LIB 1.0

CVC4 tries to automatically recognize the input language based on the file's extension: .cvc for CVC4's native language, .smt2 for SMT-LIB 2.0 and .smt for SMT-LIB 1.0. If the file extension does not match one of the previously mentioned ones you can specify the input language via the command line flag --lang. To see all language options type:
$ cvc4 --lang help

Every effort has been made to make CVC4 compliant with the SMT-LIB 2.0
standard (http://smtlib.org/). However, when parsing SMT-LIB input,
certain default settings don't match what is stated in the official
standard. To make CVC4 adhere more strictly to the standard, use the
"--smtlib" command-line option. Even with this setting, CVC4 is
somewhat lenient; some non-conforming input may still be parsed and
processed.

=The CVC4 library interface (API)=
==Using CVC4 in a C++ project==
==Using CVC4 from Java==
==The compatibility interface==

=Upgrading from CVC3 to CVC4=

==Features not supported by CVC4 (yet)==

===Type Correctness Conditions (TCCs)===

Type Correctness Conditions (TCCs), and the checking of such, are not
supported by CVC4 1.0. Thus, a function defined only on integers can be
applied to REAL (as INT is a subtype of REAL), and CVC4 will not complain,
but may produce strange results. For example:

f : INT -> INT;
ASSERT f(1/3) = 0;
ASSERT f(2/3) = 1;
CHECKSAT;
% sat
COUNTEREXAMPLE;
% f : (INT) -> INT = LAMBDA(x1:INT) : 0;

CVC3 can be used to produce TCCs for this input (with the +dump-tcc option).
The TCC can be checked by CVC3 or another solver. (CVC3 can also check
TCCs while solving with +tcc.)

==If you were using the text interfaces of CVC3==

The native language of all solvers in the CVC family, referred to as the
"presentation language," has undergone some revisions for CVC4. The
most notable is that CVC4 does _not_ add counterexample assertions to
the current assertion set after a SAT/INVALID result. For example:

x, y : INT;
ASSERT x = 1 OR x = 2;
ASSERT y = 1 OR y = 2;
ASSERT x /= y;
CHECKSAT;
% sat
QUERY x = 1;
% invalid
QUERY x = 2;
% invalid

Here, CVC4 responds "invalid" to the second and third queries, because
each has a counterexample (x=2 is a counterexample to the first, and
x=1 is a counterexample to the second). However, CVC3 will respond
with "valid" to one of these two, as the first query (the CHECKSAT)
had the side-effect of locking CVC3 into one of the two cases; the
later queries are effectively querying the counterexample that was
found by the first. CVC4 removes this side-effect of the CHECKSAT and
QUERY commands.

CVC4 supports rational literals (of type REAL) in decimal; CVC3 did not
support decimals.

CVC4 does not have support for the IS_INTEGER predicate.

==If you were using the library ("in-memory") interface of CVC3==
===If you were using CVC3 from C===
===If you were using CVC3 from Java===

=Advanced features=

This section describes some features of CVC4 of interest to developers and advanced users.

==Resource limits==

CVC4 can be made to self-timeout after a given number of milliseconds.
Use the --tlimit command line option to limit the entire run of
CVC4, or use --tlimit-per to limit each individual query separately.
Preprocessing time is not counted by the time limit, so for some large
inputs which require aggressive preprocessing, you may notice that
--tlimit does not work very well. If you suspect this might be the
case, you can use "-vv" (double verbosity) to see what CVC4 is doing.

Time-limited runs are not deterministic; two consecutive runs with the
same time limit might produce different results (i.e., one may time out
and responds with "unknown", while the other completes and provides an
answer). To ensure that results are reproducible, use --rlimit or
--rlimit-per. These options take a "resource count" (presently, based on
the number of SAT conflicts) that limits the search time. A word of
caution, though: there is no guarantee that runs of different versions of
CVC4 or of different builds of CVC4 (e.g., two CVC4 binaries with different
features enabled, or for different architectures) will interpret the resource
count in the same manner.

CVC4 does not presently have a way to limit its memory use; you may opt
to run it from a shell after using "ulimit" to limit the size of the
heap.

==Dumping API calls or preprocessed output==

[to do]

==Changing the output language==

[to do]

==Proof support==

CVC4 1.0 has limited support for proofs, and they are disabled by default.
(Run the configure script with --enable-proof to enable proofs). Proofs
are exported in LFSC format and are limited to the propositional backbone
of the discovered proof (theory lemmas are stated without proof in this
release).

==Parallel solving==

The most recent binaries with support for parallel solving can be downloaded from our Nightly Builds pages:
* [http://cvc4.cs.nyu.edu/cvc4-builds/portfolio-x86_64-linux-opt/ Optimized] binaries (statically linked)
* [http://cvc4.cs.nyu.edu/cvc4-builds/portfolio-x86_64-linux-dbg/ Debug] binaries (statically linked)

If enabled at configure-time (./configure --with-portfolio), a second
CVC4 binary will be produced ("pcvc4"). This binary has support for
running multiple instances of CVC4 in different threads. Use --threads=N
to specify the number of threads, and use --thread0="options for thread 0"
--thread1="options for thread 1", etc., to specify a configuration for the
threads. Lemmas are *not* shared between the threads by default; to adjust
this, use the --filter-lemma-length=N option to share lemmas of N literals
(or smaller). (Some lemmas are ineligible for sharing because they include
literals that are "local" to one thread.)

Currently, the portfolio **does not work** with the theory of inductive
datatypes. This limitation will be addressed in a future release.

See more details and examples in the [[Tutorials#Parallel_Solving|tutorial]].

==Emacs support==

For a suggestion of editing CVC4 source code with emacs, see the file
contrib/editing-with-emacs. For a CVC language mode (the native input
language for CVC4), see contrib/cvc-mode.el.

User Manual

2012-11-26T04:38:44Z

Tinelli: /* Parametric Data Types */

This manual includes lots of information about how to use CVC4.

It is a work in-progress.

= What is CVC4? =

CVC4 is the last of a long line of SMT solvers that started with SVC and includes CVC, CVC-Lite and CVC3.
Technically, it is an automated validity checker for a many-sorted (i.e., typed) first-order logic with built-in theories.
The current built-in theories are the theories of:

* equality over free (aka uninterpreted) function and predicate symbols,
* real and integer linear arithmetic (with some support for non-linear arithmetic),
* bit vectors,
* arrays,
* tuples,
* records,
* user-defined inductive data types.

CVC4 checks whether a given formula <math>\phi</math> is valid in the built-in theories under a given set <math>\Gamma</math> of assumptions, a ''context''.
More precisely, it checks whether

<center>
<math>\Gamma\models_T \phi</math>
</center>

that is, whether <math>\phi</math> is a logical consequence in <math>T</math> of the set of formulas <math>\Gamma</math>, where <math>T</math> is the union of CVC4's built-in theories.

Roughly speaking, when <math>\phi</math> is a universal formula and <math>\Gamma</math> is a set of existential formulas (i.e., when <math>\phi</math> and <math>\Gamma</math> contain at most universal, respectively existential, quantifiers), CVC4 is a decision procedure:
it is guaranteed (modulo bugs and memory limits) to return a correct "valid" or "invalid" answer eventually.
In all other cases, CVC4 is deductively sound but incomplete:
it will never say that an invalid formula is valid,
but it may either never return or give up and return "unknown" for some formulas.

Currently, when CVC4 returns "valid" for a query formula <math>\phi</math> under a context <math>\Gamma</math>
it provides no evidence to back its claim.
Future versions will also return a ''proof certificate'',
a formal proof that <math>\Gamma'\models_T \phi</math> for some subset <math>\Gamma'</math> of <math>\Gamma</math>.

When CVC4 returns "invalid" it can return
both a ''counter-example'' to <math>\phi</math>'s validity under the context <math>\Gamma</math> and a ''counter-model''.
Both a counter-example and a counter-model are a set <math>\Delta</math> of additional formulas consistent with <math>\Gamma</math> in <math>T</math>, but entailing the negation of <math>\phi</math>.
Formally:

<center>
<math>\Gamma \cup \Delta \not\models_T \mathit{false}</math>
and
<math>\Gamma \cup \Delta \models_T \lnot \phi</math>.
</center>

The difference is that a counter-model is given as a set of equations providing a concrete assignment of values for the free symbols in <math>\Gamma</math> and <math>\phi</math>
(see the section on [[#CVC4's native input language|CVC4's native input language]] for more details).

=Obtaining and compiling CVC4=

CVC4 is distributed in the following ways:
* [[#Obtaining_binary_packages|Binary packages]]
* [[#Obtaining_source_packages|Source packages]]
* [[#Source_repository|Source repository checkout]]

==Obtaining binary packages==

[http://cvc4.cs.nyu.edu/builds/ Binary packages are available] for CVC4.
Nightly builds:
* [http://cvc4.cs.nyu.edu/builds/debian/unstable Debian] packages
* [http://cvc4.cs.nyu.edu/builds/x86_64-linux-opt/ Optimized] binaries (statically linked)
* [http://cvc4.cs.nyu.edu/builds/x86_64-linux-dbg/ Debug] binaries (statically linked)

==Obtaining source packages==

[http://cvc4.cs.nyu.edu/builds/src/ Sources are available] from the same site as the binaries.

==Source repository==
The [http://cvc4.cs.nyu.edu/builds/src/ CVC4 source repository] is currently hosted by [http://cims.nyu.edu/ CIMS] and requires a CIMS account. Please contact a member of the development team for access. Please see the additional instructions for [[#Building_CVC4 from_a_repository_checkout]] here.

==Building from source==

===Quick-start instructions===
To compile from a source package:
# Install antlr
# Configure cvc4
# Compile cvc4
# Install cvc4 [optional]
cd contrib
./get-antlr-3.4
cd ..
./configure --with-antlr-dir=`pwd`/antlr-3.4 ANTLR=`pwd`/antlr-3.4/bin/antlr3
make
make check [recommended]
make install [optional]

(To build from a repository checkout, see [[#Building_CVC4_from_a_repository_checkout|below]].)

===Common make Options===
* "''make install''" will install into the "--prefix" option you gave to
the configure script (''/usr/local'' by default).
./configure --prefix=~/install_targets/cvc4 ...
make install
* '''You should run "''make check''"''' before installation to ensure that CVC4 has been
built correctly. In particular, GCC version 4.5.1 seems to have a
bug in the optimizer that results in incorrect behavior (and wrong
results) in many builds. This is a known problem for Minisat, and
since Minisat is at the core of CVC4, a problem for CVC4. "''make check''"
easily detects this problem (by showing a number of FAILed test cases).
It is ok if the unit tests aren't run as part of "''make check''", but all
system tests and regression tests should pass without incident.
* To build API documentation, use "''make doc''". Documentation is produced
under ''builds/doc/'' but is not installed by "''make install''".

Examples and tutorials are not installed with "''make install''." See [[#Examples_and_tutorials_are_not_built_or_installed|below]].

For more information about the build system itself (probably not
necessary for casual users), see the [[#Appendix:_Build_architecture|Appendix]] at the bottom of this
file.

===Common configure Options===
*'''--prefix=PREFIX''' install architecture-independent files in PREFIX (by default /usr/local)
*'''--with-build={production,debug,default,competition}'''
*'''--with-antlr-dir=PATH'''
*'''--with-cln'''/'''--with-gmp''' selects the numbers package to use by default ([[#Optional requirements]])
*'''--enable-static-binary''' build a fully statically-linked binary. (This is recommended for Mac OS X users that want to be able to use gdb.)
*'''ANTLR=PATH''' location of the antlr3 script
*'''--with-boost=DIR''' installation location of the boost libraries (most users will not need this)

See '''./configure --help''' for more.

===Build dependencies===

The following tools and libraries are required to run CVC4. Versions
given are minimum versions; more recent versions should be compatible.

*'''GNU C and C++''' (gcc and g++), reasonably recent versions
*'''GNU Make'''
*'''GNU Bash'''
*'''GMP v4.2''' (GNU Multi-Precision arithmetic library)
*'''libantlr3c v3.2 or v3.4''' (ANTLR parser generator C support library)
*'''The Boost C++ base libraries'''
*'''MacPorts''' [highly recommended if on a Mac; see [[#MacPorts]]]

The hardest to obtain and install is the libantlr3c requirement, and
is explained [[#Installing libantlr3c: ANTLR parser generator C support library|next]].

If "make" is non-GNU on your system, make sure to invoke "gmake" (or
whatever GNU Make is installed as). If your usual shell is not Bash,
the configure script should auto-correct this. If it does not, you'll
see strange shell syntax errors, and you may need to explicitly set
SHELL or CONFIG_SHELL to the location of bash on your system.

====Installing libantlr3c: ANTLR parser generator C support library====

For libantlr3c, you can use the convenience script in
''contrib/get-antlr-3.4'' in the source distribution---this will download, patch, compile and install
libantlr3c into your cvc4 directory as ''cvc4/antlr-3.4/''.
cd contrib
./get-antlr-3.4

CVC4 must be configured with the antlr library installation directory, '''--with-antlr-dir''', and an antlr executable script file, '''ANTLR'''. If libantlr3c was installed via get-antlr-3.4, the following configure line should suffice for CVC44
./configure --with-antlr-dir=`pwd`/antlr-3.4 ANTLR=`pwd`/antlr-3.4/bin/antlr3

For 64 bit machines, libantlr3c needs to be configured with 64 bit explicitly
./configure --enable-64bit ...
The get-antlr-3.4 script makes a guess at whether the machine is 64 bit and adds the appropriate flag.
To force the script to compile 32 bit:
MACHINE_TYPE="x86" ./get-antlr3.4
To force the script to compile 64 bit:
MACHINE_TYPE="x86_64" ./get-antlr3.4

For a longer discussion, instructions for manual installation, and more in depth troubleshooting, see [[Developer's Guide#ANTLR3]].

====MacPorts====

On a Mac, it is '''highly''' recommended that you use MacPorts (see
http://www.macports.org/). Doing so is easy. Then, simply run the
script ''contrib/mac-build'', which installs a few ports from the MacPorts
repository, then compiles and installs antlr3c using the ''get-antlr-3.4''
script. The mac-build script should set you up
with all requirements, and will tell you how to configure CVC4 when it
completes successfully.

====Installing the Boost C++ base libraries====

A Boost package is available on most Linux distributions; check yours
for a package named something like libboost-dev or boost-devel. There
are a number of additional Boost packages in some distributions, but
this "basic" one should be sufficient for building CVC4.

Should you want to install Boost manually, or to learn more about the
Boost project, please visit http://www.boost.org/.

===Optional requirements===

None of these is required, but can improve CVC4 as described below:

*'''Optional: SWIG 2.0.x''' (Simplified Wrapper and Interface Generator)
*'''Optional: CLN v1.3 or newer''' (Class Library for Numbers)
*'''Optional: CUDD v2.4.2 or newer''' (Colorado University Decision Diagram package)
*'''Optional: GNU Readline library''' (for an improved interactive experience)
*'''Optional: The Boost C++ threading library''' (libboost_thread)
*'''Optional: CxxTest unit testing framework'''

SWIG is necessary to build the Java API (and of course a JDK is
necessary, too). SWIG 1.x won't work; you'll need 2.0, and the more
recent the better. On Mac, we've seen SWIG segfault when generating
CVC4 language bindings; version 2.0.8 or higher is recommended to
avoid this. See [[#Language_bindings|Language bindings]] below for build instructions.

CLN is an alternative multiprecision arithmetic package that can offer
better performance and memory footprint than GMP. CLN is covered by
the GNU General Public License, version 3; so if you choose to use
CVC4 with CLN support, you are licensing CVC4 under that same license.
(Usually CVC4's license is more permissive than GPL is; see the file
COPYING in the CVC4 source distribution for details.) Please visit
http://www.ginac.de/CLN/ for more details about CLN.

CUDD is a decision diagram package that changes the behavior of the
CVC4 arithmetic solver in some cases; it may or may not improve the
arithmetic solver's performance. See [[#Building_with_CUDD_(optional)|below]] for instructions on
obtaining and building CUDD.

The GNU Readline library is optionally used to provide command
editing, tab completion, and history functionality at the CVC prompt
(when running in interactive mode). Check your distribution for a
package named "libreadline-dev" or "readline-devel" or similar.

The Boost C++ threading library (often packaged independently of the
Boost base library) is needed to run CVC4 in "portfolio"
(multithreaded) mode. Check your distribution for a package named
"libboost-thread-dev" or similar.

CxxTest is necessary to run CVC4's unit tests (included with the
distribution). Running these is not really required for users of
CVC4; "make check" will skip unit tests if CxxTest isn't available,
and go on to run the extensive system- and regression-tests in the
source tree. However, if you're interested, you can download CxxTest
at http://cxxtest.com/ .

====Building with CUDD (optional)====

CUDD, if desired, must be installed delicately. The CVC4 configure
script attempts to auto-detect the locations and names of CUDD headers
and libraries the way that the Fedora RPMs install them, the way that
our NYU-provided Debian packages install them, and the way they exist
when you download and build the CUDD sources directly. If you install
from Fedora RPMs or our Debian packages, the process should be
completely automatic, since the libraries and headers are installed in
a standard location. If you download the sources yourself, you need
to build them in a special way. Fortunately, the
"contrib/build-cudd-2.4.2-with-libtool.sh" script in the CVC4 source
tree does exactly what you need: it patches the CUDD makefiles to use
libtool, builds the libtool libraries, then reverses the patch to
leave the makefiles as they were. Once you run this script on an
unpacked CUDD 2.4.2 source distribution, then CVC4's configure script
should pick up the libraries if you provide
--with-cudd-dir=/PATH/TO/CUDD/SOURCES.

If you want to force linking to CUDD, provide --with-cudd to the
configure script; this makes it a hard requirement rather than an
optional add-on.

The NYU-provided Debian packaging of CUDD 2.4.2 and CUDD 2.5.0 are
here (along with the CVC4 Debian packages):

deb http://cvc4.cs.nyu.edu/debian/ unstable/

On Debian (and Debian-derived distributions like Ubuntu), you only
need to drop that one line in your /etc/apt/sources.list file, then install with your favorite package manager.

The Debian source package "cudd", available from the same repository,
includes a diff of all changes made to cudd makefiles.

===Language bindings===

There are several options available for using CVC4 from the API.

First, CVC4 offers a complete and flexible API for manipulating
expressions, maintaining a stack of assertions, and checking
satisfiability, and related things. The C++ libraries (libcvc4.so and
libcvc4parser.so) and required headers are installed normally via a
"make install". This API is also available from Java (via CVC4.jar
and libcvc4jni.so) by configuring with --enable-language-bindings=java.
You'll also need SWIG 2.0 installed (and you might need to help
configure find it if you installed it in a nonstandard place with
--with-swig-dir=/path/to/swig/installation). You may also need to
give the configure script the path to your Java headers (in
particular, jni.h). You might do so with (for example):

./configure --enable-language-bindings=java \
JAVA_CPPFLAGS=-I/usr/lib/jvm/java-6-openjdk-amd64/include

There is also a "C++ compatibility API" (''#include <cvc4/cvc3_compat.h>''
and link against libcvc4compat.so) that attempts to maintain
source-level backwards-compatibility with the CVC3 C++ API. The
compatibility library is built by default, and
''--enable-language-bindings=java'' enables the Java compatibility library
(CVC4compat.jar and libcvc4compatjni.so).
''--enable-language-bindings=c'' enables the C compatibility library
(''#include <cvc4/bindings/compat/c/c_interface.h>'' and link against
libcvc4bindings_c_compat.so), and if you want both C and Java
bindings, use ''--enable-language-bindings=c,java''. These compatibility
language bindings do NOT require SWIG.

The ''examples/'' directory in the source distribution includes some basic examples (the "simple vc"
and "simple vc compat" family of examples) of all these interfaces.

In principle, since we use SWIG to generate the native Java API, we
could support other languages as well. However, using CVC4 from other
languages is not supported, nor expected to work, at this time. If
you're interested in helping to develop, maintain, and test a language
binding, please contact us via the users' mailing list at
cvc-users@cs.nyu.edu.

===Building CVC4 from a repository checkout===

The following tools and libraries are additionally required to build
CVC4 from from a repository checkout rather than from a prepared
source tarball.

*'''Automake v1.11'''
*'''Autoconf v2.61'''
*'''Libtool v2.2'''
*'''ANTLR3 v3.2 or v3.4'''
*'''Java Development Kit''' ([http://www.antlr.org/wiki/pages/viewpage.action?pageId=728 required for ANTLR3])

First, use "''./autogen.sh''" to create the configure script. Then
proceed as normal for any distribution tarball. The parsers are
pre-generated for the tarballs, but don't exist in the repository; hence the extra ANTLR3 and JDK requirements to
generate the source code for the parsers, when building from the
repository.

===Examples and tutorials are not built or installed===

Examples are not built by "''make''" or "''make install''". See
''examples/README'' in the source distribution for information on what to find in the ''examples/''
directory, as well as information about building and installing them.

===Appendix: Build architecture===

The build system is generated by automake, libtool, and autoconf. It
is somewhat nonstandard, though, which (for one thing) requires that
GNU Make be used. If you ./configure in the top-level source
directory, the objects will actually all appear in
builds/${arch}/${build_id}. This is to allow multiple, separate
builds in the same place (e.g., an assertions-enabled debugging build
alongside a production build), without changing directories at the
shell. The "current" build is maintained, and you can still use
(e.g.) "make -C src/main" to rebuild objects in just one subdirectory.

You can also create your own build directory inside or outside of the
source tree and configure from there. All objects will then be built
in that directory, and you'll ultimately find the "cvc4" binary in
src/main/, and the libraries under src/ and src/parser/.

=Using the CVC4 binary=

The CVC4 driver binary ("cvc4"), once installed, can be executed directly to enter into interactive mode:

$ cvc4
cvc4 1.0 assertions:off
CVC4>

You can then enter commands into CVC4 interactively:

CVC4> OPTION "incremental";
CVC4> OPTION "produce-models";
CVC4> TRANSFORM 25*25;
625
CVC4> x, y : INT;
CVC4> QUERY x = y;
invalid
CVC4> COUNTERMODEL;
x : INT = -1;
y : INT = 0;
CVC4> ASSERT x >= 0;
CVC4> QUERY x = y;
invalid
CVC4> COUNTERMODEL;
x : INT = 0;
y : INT = 1;
CVC4>

The above example shows two useful options, ''incremental'' and ''produce-models.''

* The ''incremental'' option allows you to issue multiple QUERY (or CHECKSAT) commands, and allows the use of the PUSH and POP commands. Without this option, CVC4 optimizes itself for a single QUERY or CHECKSAT command (though you may issue any number of ASSERT commands). The ''incremental'' option may also be given by passing the ''-i'' command line option to CVC4.
* The ''produce-models'' option allows you to query the model (here, with the COUNTERMODEL command) after an "invalid" QUERY (or "satisfiable" CHECK-SAT). Without it, CVC4 doesn't do the bookkeeping necessary to support model generation. The ''produce-models'' option may also be given by passing the ''-m'' command line option to CVC4.

So, if you invoke CVC4 with ''-im'', you don't need to pass those options at all:

$ cvc4 -im
cvc4 1.0 assertions:off
CVC4> x, y : INT;
CVC4> QUERY x = y;
invalid
CVC4> COUNTERMODEL;
x : INT = -1;
y : INT = 0;
CVC4> ASSERT x >= 0;
CVC4> QUERY x = y;
invalid
CVC4> COUNTERMODEL;
x : INT = 0;
y : INT = 1;
CVC4>

By default, CVC4 operates in [[#CVC4's native input language|CVC-language mode]]. If you enter something that looks like SMT-LIB, it will suggest that you use the "''--lang smt''" command-line option for SMT-LIB mode:

CVC4> (declare-fun x () Int)
Parse Error: <shell>:1.7: In CVC4 presentation language mode, but SMT-LIB format detected. Use --lang smt for SMT-LIB support.
CVC4>

==Verbosity==

CVC4 has various levels of verbosity. By default, CVC4 is pretty quiet, only reporting serious warnings and notices. If you're curious about what it's doing, you can pass CVC4 the ''-v'' option:

$ cvc4 -v file.smt2
Invoking: (set-logic AUFLIRA)
Invoking: (set-info :smt-lib-version 2.000000)
Invoking: (set-info :category "crafted")
Invoking: (set-info :status unsat)
Invoking: (declare-fun x () Real)
''etc...''

For even more verbosity, you can pass CVC4 an ''additional'' ''-v'':

$ cvc4 -vv file.smt2
Invoking: (set-logic AUFLIRA)
Invoking: (set-info :smt-lib-version 2.000000)
Invoking: (set-info :category "crafted")
Invoking: (set-info :status unsat)
Invoking: (declare-fun x () Real)
''etc...''
expanding definitions...
constraining subtypes...
applying substitutions...
simplifying assertions...
doing static learning...
''etc...''

Internally, verbosity is just an integer value. It starts at 0, and with every ''-v'' on the command line it is incremented; with every ''-q'', decremented. It can also be set directly. From CVC language:

CVC4> OPTION "verbosity" 2;

Or from SMT-LIB language:

CVC4> (set-option :verbosity 2)

==Getting statistics==

Statistics can be dumped on exit (both normal and abnormal exits) with the ''--statistics'' command line option.

$ cvc4 --statistics foo.smt2
sat
sat::decisions, 0
sat::propagations, 3
sat::starts, 1
theory::uf::TheoryUF::functionTermsCount, 2
theory::uf::TheoryUF::mergesCount, 2
theory::uf::TheoryUF::termsCount, 6
theory<THEORY_UF>::propagations, 1
driver::filename, foo.smt2
driver::sat/unsat, sat
driver::totalTime, 0.02015373
''[many others]''

Many statistics name-value pairs follow, one comma-separated pair per line.

==Exit status==

The exit status of CVC4 depends on the ''last'' QUERY or CHECK-SAT. If you wish to call CVC4 from a program (e.g., a shell script) and care only about the satisfiability or validity of a single formula, you can pass the ''-q'' option (as described [[#Verbosity|above, under verbosity]]) and check the exit code. With ''-q'', CVC4 should not produce any output unless it encounters a fatal error.

QUERY asks a validity question, and CHECK-SAT a satisfiability question, and these are dual problems; hence the terminology is different, but really "sat" and "invalid" are the same internally, as are "unsat" and "valid":

<table border="1">
<tr><th>Solver's last result</th><th>Exit code</th><th>Notes</th></tr>
<tr><td>'''sat''' or '''invalid'''</td><td>10</td></tr>
<tr><td>'''unsat''' or '''valid'''</td><td>20</td></tr>
<tr><td>'''unknown'''</td><td>0</td><td>could be for any reason: time limit exceeded, no memory, incompleteness..</td></tr>
<tr><td>''no result''</td><td>0</td><td>no query or check-sat command issued</td></tr>
<tr><td>parse errors</td><td>0 (in interactive mode)<br/>1 (otherwise)</td><td>see below</td></tr>
<tr><td>other errors</td><td>1 (usually)</td><td>see below</td></tr>
</table>

Most "normal errors" return a 1 as the exit code, but out of memory conditions, and others, can produce different exit codes. In interactive mode, parse errors are ignored and the next line read; so in interactive mode, you may see an exit code of 0 even in the presence of such an error.

In SMT-LIB mode, an SMT-LIB command script that sets its status via "set-info :status" also affects the exit code. So, for instance, the following SMT-LIB script returns an exit code of 10 even though it contains no "check-sat" command:

(set-logic QF_UF)
(set-info :status sat)
(exit)

Without the "set-info," it would have returned an exit code of 0.

=CVC4's native input language=

The native input language consists of a sequence of symbol declarations and commands, each followed by a semicolon (<code>;</code>).

Any text after the first occurrence of a percent character and to the end of the current line is a comment:

%%% This is a native language comment

== Type System ==

CVC4's type system includes a set of built-in types which can be expanded with additional user-defined types.

The type system consists of ''first-order'' types, ''subtypes'' of first-order types, and ''higher-order'' types, all of which are interpreted as sets.
For convenience, we will sometimes identify below the interpretation of a type with the type itself.

First-order types consist of basic types and structured types. The basic types are <math>\mathrm{BOOLEAN}</math>, <math>\mathrm{REAL}</math>, <math>\mathrm{BITVECTOR}(n)</math> for all <math>n > 0</math>, as well as user-defined basic types (also called uninterpreted types).
The structured types are array, tuple, record types, and ML-style user-defined (inductive) datatypes.

'''Note:''' Currently, subtypes consist only of the built-in subtype <math>\mathrm{INT}</math> of <math>\mathrm{REAL}</math>.

Support for CVC3-style user-defined subtypes will be added in a later release.

Function types are the only higher-order types.
More precisely, they are just second-order types
since function symbols in CVC4, both built-in and user-defined, can take as argument or return only values of
a first-order type.

=== Basic Types ===

==== The BOOLEAN Type ====

The <math>\mathrm{BOOLEAN}</math> type is interpreted as the two-element set of Boolean values
<math>\{\mathrm{TRUE},\; \mathrm{FALSE}\}</math>.

'''Note:''' CVC4's treatment of this type differs from CVC3's where <math>\mathrm{BOOLEAN}</math> is used only as the type of formulas, but not as value type. CVC3 follows the two-tiered structure of classical first-order logic
which distinguishes between formulas and terms, and allows terms to occur in formulas but not vice versa (with the exception of the IF-THEN-ELSE construct).
CVC4 drops the distinction between terms and formulas and defines the latter just as terms of type <math>\mathrm{BOOLEAN}</math>. As such, formulas can occur as subterms of possibly non-Boolean terms.

Example:

[To do]

==== The REAL Type ====

The <math>\mathrm{REAL}</math> type is interpreted as the set of real numbers.

Note that these are the (infinite precision) mathematical reals,
not the floating point numbers.
Support for floating point types is planned for future versions.

x, y : REAL;
QUERY (( x <= y ) AND ( y <= x )) => ( x = y );

==== The INT Type ====

The <math>\mathrm{INT}</math> type is interpreted as the set of integer numbers
and is considered as a subtype of <math>\mathrm{REAL}</math>.
The latter means in particular that it is possible to mix integer and real terms
in expressions without the need of an explicit ''upcasting'' operator.

Note that these are the (infinite precision) mathematical integers,
not the finite precision machine integers used in most programming languages.
The latter are models by [[ #Bitvectors | bit vector ]] types.

x, y : INT;
QUERY ((2 * x + 4 * y <= 1) AND ( y >= x)) => (x <= 0);
z : REAL;
QUERY (2 * x + z <= 3.5) AND (z >= 1);

==== Bit Vector Types ====

For every positive integer <math>n</math>, the type <math>\mathrm{BITVECTOR}(n)</math> is interpreted as the set of all bit vectors of size <math>n</math>.
A rich set of bit vector operators is supported.

==== User-defined Basic Types ====

Users can define new basic types
(often referred to as ''uninterpreted'' types in the SMT literature).
Each such type is interpreted as a set of unspecified cardinality
but disjoint from any other type.

User-defined basic types are created by declarations like the following:

% User declarations of basic types:

MyBrandNewType: TYPE;

Apples, Oranges: TYPE;

=== Structured Types ===

CVC4's structured types are divided in the following families.

==== Array Types ====

Array types are created by the mixfix type constructors <math>\mathrm{ARRAY}\ \_\ \mathrm{OF}\ \_</math>
whose arguments can be instantiated by any value type.

I : TYPE;

%% Array types:

% Arrays with indices from I and values from REAL
Array1: TYPE = ARRAY I OF REAL;

% Arrays with integer indices and array values
Array2: TYPE = ARRAY INT OF (ARRAY INT OF REAL);

% Arrays with integer pair indices and integer values
IntMatrix: TYPE = ARRAY [INT, INT] OF INT;

An array type of the form <math>\mathrm{ARRAY}\ T_1\ \mathrm{OF}\ T_2</math> is interpreted
as the set of all total maps from <math>T_1</math> to <math>T_2</math>.
The main difference with the function type <math>T_1 \to T_2</math> is that arrays,
contrary to functions, are first-class objects of the language, that is, values of an array
type can be arguments or results of functions.
Furthermore, array types come equipped with an update operation.

==== Tuple Types ====

Tuple types are created by the mixfix type constructors

<center>
<math>
\begin{array}{l} [\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ \ ,\ \_\ ] \\[1ex] \ldots \end{array}
</math>
</center>

whose arguments can be instantiated by any value type.

IntArray: TYPE = ARRAY INT OF INT;

% Tuple type declarations

RealPair: TYPE = [REAL, REAL]

MyTuple: TYPE = [ REAL, IntArray, [INT, INT] ];

A tuple type of the form <math>[T_1, \ldots, T_n]</math> is interpreted
as the Cartesian product <math>T_1 \times \cdots \times T_n</math>.

Note that while the types <math>(T_1, \ldots, T_n) \to T</math> and
<math>[T_1 \times \cdots \times T_n] \to T</math> are semantically equivalent,
they are operationally different in CVC4.
The first is the type of functions that take <math>n</math> arguments
of respective type <math>T_1</math>, <math>\ldots</math>, <math>T_n</math>,
while the second is the type of functions that take one argument of an <math>n</math>-tuple type.

==== Record Types ====

Similar to, but more general than tuple types, record types are created by type constructors of the form

<center>
<math>
[\#\ l_1: \_\ ,\ \ldots\ ,\ l_n: \_\ \#]
</math>
</center>

where <math>n > 0</math>, <math>l_1,\ldots, l_n</math> are field labels,
and the arguments can be instantiated with any first-order types.

MyType: TYPE;

% Record declaration

RecordType: TYPE = [# id: REAL, age: INT, info: MyType #];

The order of the fields in a record type is meaningful:
permuting the field names gives a different type.

Note that record types are non-recursive.
For instance, it is not possible to declare a record type called <code>Person</code> containing
a field of type <code>Person</code>.
Recursive types are provided in CVC4 by the more general inductive data types.
(As a matter of fact, both record and tuple types are implemented internally as inductive data types.)

==== Inductive Data Types ====

Inductive data types in CVC4 are similar to inductive data types of functional languages.
They can be parametric or not.

===== Non-Parametric Data Types =====

Non-parametric data types are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1 & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2 & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types, including any <math>A_i</math>.
Such declarations define the data types <math>A_1, \ldots, A_n</math>.
For each data type <math>A_i</math> they introduce:

* constructor symbols <math>cons</math> of type <math>(T_1, \ldots, T_k) \to \mathit{type\_name}_i</math>,
* selector symbols <math>\mathit{sel}_j</math> of type <math>\mathit{type\_name}_i \to T_j</math>, and
* tester symbols <math>\mathit{is\_cons}</math> of type <math>\mathit{type\_name}_i \to \mathrm{BOOLEAN}</math>.

Note that permitting more than one data type to be defined in the same declarations allows
the definition of mutually recursive types.

% simple enumeration type

% implicitly defined are the testers: is_red, is_yellow and is_blue
% (similarly for the other data types)

DATATYPE
PrimaryColor = red | yellow | blue
END;

% infinite set of pairwise distinct values ..., v(-1), v(0), v(1), ...

DATATYPE
Id = v (id: INT)
END;

% ML-style integer lists

DATATYPE
IntList = nil | ins (head: INT, tail: IntList)
END;

% AST for lamba calculus

DATATYPE
Term = var (index: INT)
| apply (arg_1: Term, arg_2: Term)
| lambda (arg: INT, body: Term)
END;

% Trees

DATATYPE
Tree = tree (value: REAL, children: TreeList),
TreeList = nil_tl
| ins_tl (first_t1: Tree, rest_t1: TreeList)
END;

Constructor, selector and tester symbols defined for a data type have global scope.
So, for example, it is not possible for two different data types to use
the same name for a constructor.

An inductive data type is interpreted as a term algebra constructed by the constructor symbols
over some sets of generators.
For example, the type <code>IntList</code> defined above is interpreted as the set
of all terms constructed with <code>nil</code> and <code>ins</code> over the integers.

===== Parametric Data Types =====

Parametric data types are infinite families of (non-parametric) data types
with each family parametrized by one or more type variables.
They are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1[X_{1,1}, \ldots, X_{1,p_1}] & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2[X_{2,1}, \ldots, X_{2,p_2}] & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n[X_{n,1}, \ldots, X_{n,p_n}] & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name parametrized by the type variables <math>X_{i,1}, \ldots, X_{i,p_i}</math>
and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types,
possibly parametrized by <math>X_1, \ldots, X_p</math>, including any <math>A_i</math>.

% Parametric pairs
DATATYPE [X, Y]
Pair[X, Y] = pair (first: X, second: Y)
END;

% Parametric lists

DATATYPE [X]
List[X] = nil | cons (head: X, tail: List[X])
END;

% Parametric trees using the list type above

DATATYPE [X]
Tree[X] = node (value: X, children: List[Tree[X]]),
END;

The declarations above define infinitely many types of the form
Pair[S,T], List[T] and Tree[T] where S and T are first-order types.
Note that the identifier <code>List</code> above, for example, by itself does not denote a type.
In contrast, the terms <code>List[Real]</code>, <code>List[List[Real]]</code>, <code>List[Tree[INT]]</code>,
and so on do.

===== Restriction to Inductive Types =====

By adopting a term algebra semantics, CVC4 allows only ''inductive'' data types,
that is, data types whose values are essentially (labeled, ordered) finite trees.
Infinite structures such as streams or even finite but cyclic ones
such as circular lists are then excluded.
For instance, none of the following declarations define inductive data types,
and are rejected by CVC4:

DATATYPE
IntStream = s (first:INT, rest: IntStream)
END;

DATATYPE
RationalTree = node1 (child: RationalTree)
| node2 (left_child: RationalTree, right_child:RationalTree)
END;

DATATYPE
T1 = c1 (s1: T2),
T2 = c2 (s2: T1)
END;

In concrete, a declaration of <math>n \geq 1</math> datatypes <math>T_1, \ldots, T_n</math> will be rejected if for any one of the types <math>T_1, \ldots, T_n</math>, it is impossible to build a finite term of that type using only the constructors of <math>T_1, \ldots, T_n</math> and free constants of type other than <math>T_1, \ldots, T_n</math>.

Inductive data types are the only types where the user also chooses names for the built-in operations to:

* construct a value of the type (with the constructors),
* extract components from a value (with the selectors), or
* check if a value was constructed with a certain constructor or not (with the testers).

For all the other types, CVC4 provides predefined names for the built-in operations on the type.

=== Function Types ===

Function (<math>\to</math>) types are created by the mixfix type constructors
<center>
<math>
\begin{array}{l}
\_ \to \_ \\[1ex] (\ \_\ ,\ \_\ ) \to \_
\\[1ex] (\ \_\ ,\ \_\ ,\ \_\ ) \to \_
\\[1ex] \ldots
\end{array}
</math>
</center>
whose arguments can be instantiated by any first-order type.

% Function type declarations

UnaryFunType: TYPE = INT -> REAL;

BinaryFunType: TYPE = (REAL, REAL) -> ARRAY REAL OF REAL;

TernaryFunType: TYPE = (REAL, BITVECTOR(4), INT) -> BOOLEAN;

A function type of the form <math>(T_1, \ldots, T_n) \to T</math> with <math>n > 0</math> is interpreted as the set of all ''total'' functions from the Cartesian product <math>T_1 \times \cdots \times T_n</math> to <math>T</math>.

The example above also shows how to introduce type names.
A name like <code>UnaryFunType</code> above is just an abbreviation for the type <math>\mathrm{INT} \to \mathrm{REAL}</math> and can be used interchangeably with it.

In general, any type defined by a type expression <code>E</code> can be given a name with the declaration:

name : TYPE = E;

=== Type Checking ===

In CVC4, formulas and terms are statically typed at the level of types
(as opposed to subtypes) according to the usual rules of first-order many-sorted logic,
with the main difference that formulas are just terms of type <math>BOOLEAN</math>:

* each variable has one associated first-order type,
* each constant symbol has one or more associated first-order types,
* each function symbol has one or more associated function types,
* the type of a term consisting just of a variable is the type associated to that variable,
* the type of a term consisting just of a constant symbol is the type associated to that constant symbol,
* the term obtained by applying a function symbol <math>f</math> to the terms <math>t_1, \ldots, t_n</math> is <math>T</math> if <math>f</math> has type <math>(T_1, \ldots, T_n) \to T</math> and each <math>t_i</math> has type <math>T_i</math>.

Attempting to enter an ill-typed term will result in an error.

Another significant difference with standard many-sorted logic is that
some built-in symbols are parametrically polymorphic.
For instance, the function symbol for extracting the element of any array has
type <math>(\mathit{ARRAY}\ T_1\ \mathit{OF}\ T_2,\; T_1) \to T_2</math>
for all first-order types <math>T_1, T_2</math>.

==== Type Ascription ====

By the type inference rules above some terms might have more than one type.
This can happen with terms built with polymorphic data type constructors
that have more than one return type for the same input type.
In that case, a type ascription operator (<code>::</code>) must be applied
to the constructor to specify the intended return type.

DATATYPE [X]
List[X] = nil | cons (head: X, tail: List[X])
END;

ASSERT y = cons(1, nil::List[REAL]);

DATATYPE [X, Y]
Union[X, Y] = left(val_l: X) | right(val_r: Y)
END;

ASSERT y = left::Union[BOOLEAN, REAL](TRUE);

The constant symbol <math>\mathrm{nil}</math> declared above has infinitely many types
(<math>\mathrm{List}[\mathrm{REAL}]</math>, <math>\mathrm{List}[\mathrm{BOOLEAN}]</math>,
<math>\mathrm{List}[[\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{List}[\mathrm{List}[\mathrm{REAL}]]</math>, ...)
CVC4's type checker requires the user to indicate explicitly the type
of each occurrence of <code>nil</code> in a term.
Similarly,
the injection operator <code>left</code> has infinitely many return types
for the same input type, for instance:
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{REAL}]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, [\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{List}[\mathrm{REAL}]]</math>,
and so on.
Applications of <code>left</code> need to specify the intended returned typed, as shown above.

== Terms and Formulas ==

In addition to type expressions, CVC4 has expressions for terms and for formulas
(i.e., terms of type <math>\mathrm{BOOLEAN}</math>).
By and large, these are standard first-order terms built out of typed variables,
predefined theory-specific operators, free (i.e., user-defined) function symbols,
and quantifiers.
Extensions include an if-then-else operator, lambda abstractions, and local symbol
declarations, as illustrated below.
Note that these extensions still keep CVC4's language first-order.
In particular, lambda abstractions are restricted to take and return only terms of
a first-order type.
Similarly, variables can only be of a first-order type.

A number of built-in function symbols (for instance, the arithmetic ones) are used
as infix operators. All user-defined symbols are used as prefix ones.

User-defined, i.e., free, function symbols include ''constant symbols'' and
''predicate symbols'', respectively nullary function symbols and function symbols
with a <math>\mathrm{BOOLEAN}</math> return type.
These symbols are introduced with global declarations of the form
<math> f_1, \ldots, f_m: T;</math>
where <math>m > 0</math>, <math>f_i</math> are the names of the symbols and
<math>T</math> is their type:

% integer constants

a, b, c: INT;

% real constants

x, y, z: REAL;

% unary function

f1: REAL -> REAL;

% binary function

f2: (REAL, INT) -> REAL;

% unary function with a tuple argument

f3: [INT, REAL] -> BOOLEAN;

% binary predicate

p: (INT, REAL) -> BOOLEAN;

% Propositional "variables"

P, Q; BOOLEAN;

Like type declarations, function symbol declarations like the above have global scope
and must be unique.
In other words, it is not possible to declare a function symbol globally more than once
in the same lexical scope.
This entails among other things that globally-defined free symbols cannot be overloaded
with different types and that theory symbols cannot be redeclared globally as free symbols.

=== Global symbol definitions ===

As with types, a function symbol can be defined as the name of another term
of the corresponding type.
With constant symbols, this is done with a declaration of the form <math>f:T = t;</math> :

c: INT;

i: INT = 5 + 3*c; % i is effectively a shorthand for 5 + 3*c

j: REAL = 3/4;

t: [REAL, INT] = (2/3, -4);

r: [# key: INT, value: REAL #] = (# key := 4, value := (c + 1)/2 #);

f: BOOLEAN = FORALL (x:INT): x <= 0 OR x > c ;

A restriction on constants of type <math>\mathit{BOOLEAN}</math> is that their value
can only be a closed formula, that is, a formula with no free variables.

A term and its name can be used interchangeably in later expressions.
Named terms are often useful for shared subterms (terms used several times in different places)
since their use can make the input exponentially more concise.
Named terms are processed very efficiently by CVC4.
It is much more efficient to associate a complex term with a name directly rather than
to declare a constant and later assert that it is equal to the same term.
This point is explained in more detail later in section [[Commands | Commands]].

More generally, in CVC4 one can associate a term to function symbols of any arity.
For non-constant function symbols this is done with a declaration of the form

<center>
<math>f:(T_1, \ldots, T_n) \to T = \mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t\;;</math>
</center>

where <math>t</math> is any term of type <math>T</math> with free variables
in <math>\{x_1, \ldots, x_n\}</math>.
The lambda binder has the usual semantics and conforms to the usual lexical scoping rules:
within the term <math>t</math> the declaration of the symbols <math>x_1, \ldots, x_n</math>
as local variables of respective type <math>T_1, \ldots, T_n</math> hides any previous
declarations of those symbols that are in scope.

As a general shorthand, when <math>k</math> consecutive types
<math>T_i, \ldots, T_{i+k-1}</math> in the lambda expression
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t</math> are identical, the syntax
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x_i,\ldots, x_{i+k-1}:T_i,\ldots, x:T_n): t</math>
can also be used.

% Global declaration of x as a unary function symbol

x: REAL -> REAL;

% Local declarations of x as variable (hiding the global one)

f: REAL -> REAL = LAMBDA (x: REAL): 2*x + 3;

p: (INT, INT) -> BOOLEAN = LAMBDA (x,i: INT): i*x - 1 > 0;

g: (REAL, INT) -> [REAL, INT] = LAMBDA (x: REAL, i:INT): (x + 1, i - 3);

Note that lambda definitions are not recursive:
the symbol being defined cannot occur in the body of the lambda term.
They should be understood as macros.
For instance, any occurrence of the term <math>f(t)</math>
where <math>f</math> is as defined above will be treated
as if it was the term <math>(2*t + 3)</math>.

=== Local symbol definitions ===

Constant and function symbols can also be declared locally anywhere within a term
by means of a let binder.
This is done with a declaration of the form

<center>
<math>
\mathrm{LET}\ f = t \ \mathrm{IN}\ t' ;
</math>
</center>

where <math>t</math> is a term with no free variables, possibly a lambda term.
Let binders can be nested arbitrarily and follow the usual lexical scoping rules.
The following general form
<center>
<math>
\mathrm{LET}\ f_1 = t_1, f_2 = t_2, \ldots, f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>
can be use above can used as a shorthand for
<center>
<math>
\mathrm{LET}\ f_1 = t_1\ \mathrm{IN}\
\mathrm{LET}\ f_2 = t_2\ \mathrm{IN}\
\ldots \
\mathrm{LET}\ f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>

t: REAL =
LET x1 = 42,
g = LAMBDA(x:INT): x + 1,
x2 = 2*x1 + 7/2
IN
(LET x3 = g(x1) IN x3 + x2) / x1;

Note that the same symbol = is used, unambiguously, in the syntax of global declarations,
let declarations, and as a predicate symbol.

'''Note:'''
A <math>\mathrm{LET}</math> term with a multiple symbols defines them sequentially.
A parallel version of the <math>\mathrm{LET}</math> construct will be introduced in a later version.

== Built-in theories and their symbols ==

In addition to user-defined symbols, CVC4 terms can use a number of predefined symbols:
the logical symbols, such as <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, etc.,
as well as theory symbols, function symbols belonging to one of the built-in theories.
They are described next, with the theory symbols grouped by theory.

=== Logical Symbols ===

The logical symbols in CVC4's language include
the equality and disequality predicate symbols, respectively written as = and /=,
the multiarity disequality symbol <math>\mathrm{DISTINCT}</math>,
together with the logical constants <math>\mathrm{TRUE}</math>, <math>\mathrm{FALSE}</math>,
the connectives <math>\mathrm{NOT}</math>, <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, <math>\mathrm{XOR}</math>, <math>\Rightarrow</math>, <math>\Leftrightarrow</math>, and
the first-order quantifiers <math>\mathrm{EXISTS}</math> and <math>\mathrm{FORALL}</math>,
all with the standard many-sorted logic semantics.

The binary connectives have infix syntax and type
<math>(\mathrm{BOOLEAN},\mathrm{BOOLEAN}) \to \mathrm{BOOLEAN}</math>.
The symbols = and /=, which are also infix, are instead parametrically polymorphic,
having type <math>(T,T) \to \mathrm{BOOLEAN}</math>
for every first-order type <math>T</math>.
They are interpreted respectively as the identity relation and its complement.

The DISTINCT symbol is both overloaded and polymorphic.
It has type <math>(T,...,T) \to \mathrm{BOOLEAN}</math>
for every sequence <math>(T,...,T)</math> of length <math>n > 0</math>
and first-order type <math>T</math>.
For each <math>n > 0</math>, it is interpreted as the relation
that holds exactly for tuples of pairwise distinct elements.

The syntax for quantifiers is similar to that of the lambda binder.

Here is an example of a formula built just of these logical symbols and variables:

A, B: TYPE;

q: BOOLEAN = FORALL (x,y: A, i,j,k: B):
i = j AND i /= k => EXISTS (z: A): x /= z OR z /= y;

Binding and scoping of quantified variables follows the same rules as
in let expressions.
In particular, a quantifier will shadow in its scope any constant and function symbols
with the same name as one of the variables it quantifies:

A: TYPE;
i, j: INT;

% The first occurrence of i and of j in f are constant symbols,
% the others are variables.

f: BOOLEAN = i = j AND FORALL (i,j: A): i = j OR i /= j;

Optionally, it is also possible to specify instantiation patterns
for quantified variables.
The general syntax for a quantified formula <math>\psi</math> with patterns is

<center>
<math>
Q\;(x_1:T_1, \ldots, x_k:T_k):\; p_1: \ldots\; p_n:\; \varphi
</math>
</center>

where <math>n \geq 0</math>, <math>Q</math> is
either <math>\mathrm{FORALL}</math> or <math>\mathrm{EXISTS}</math>,
<math>\varphi</math> is a term of type <math>\mathrm{BOOLEAN}</math>,
and each of the <math>p_i</math>'s,
a pattern for the quantifier <math>Q\;(x_1:T_1, \ldots, x_k:T_k)</math>, has the form

<center>
<math>
\mathrm{PATTERN}\; (t_1, \ldots, t_m)
</math>
</center>

where <math>m > 0</math> and <math>t_1, \ldots, t_m</math> are
arbitrary binder-free terms (no lets, no quantifiers).
Those terms can contain (free) variables, typically, but not exclusively,
drawn from <math>x_1, \ldots, x_k</math>.
(Additional variables can occur if <math>\psi</math> occurs in a bigger formula
binding those variables.)

A: TYPE;
b, c: A;
p, q: A -> BOOLEAN;
r: (A, A) -> BOOLEAN;

ASSERT FORALL (x0, x1, x2: A):
PATTERN (r(x0, x1), r(x1, x2)):
(r(x0, x1) AND r(x1, x2)) => r(x0, x2) ;

ASSERT FORALL (x: A):
PATTERN (r(x, b)):
PATTERN (r(x, c)):
p(x) => q(x) ;

ASSERT EXISTS (y: A):
FORALL (x: A):
PATTERN (r(x, y), p(y)):
r(x, y) => q(x) ;

Patterns have no logical meaning:
adding them to a formula does not change its semantics.
Their purpose is purely operational, as explained in
the [[#Instantiation Patterns | Instantiation Patterns]] section.

In addition to these constructs, CVC4 also has a general mixfix conditional operator
of the form

<center>
<math>
\mathrm{IF}\ b\ \mathrm{THEN}\ t\ \mathrm{ELSIF}\ b_1\ \mathrm{THEN}\ t_1\ \ldots\ \mathrm{ELSIF}\ b_n\ \mathrm{THEN}\ t_n\ \mathrm{ELSE}\ t_{n+1}\ \mathrm{ENDIF}
</math>
</center>

with <math>n \geq 0</math> where
<math>b, b_1, \ldots, b_n</math> are terms of type <math>\mathrm{BOOLEAN}</math> and
<math>t, t_1, \ldots, t_n, t_{n+1}</math> are terms of the same first-order type <math>T</math>:

% Conditional term
x, y, z, w: REAL;

t: REAL =
IF x > 0 THEN y
ELSIF x >= 1 THEN z
ELSIF x > 2 THEN w
ELSE 2/3 ENDIF;

=== User-defined Functions and Types ===

The theory of user-defined functions,also know in the SMT literature as
the theory ''Equality over Uninterpreted Functions'', or ''EUF'', is in effect
a family of theories of equality parametrized by the basic types and the free symbols
a user can define during a run of CVC4.

This theory has no built-in symbols (other than the logical ones).
Its types consist of ''all and only'' the user-defined types.
Its function symbols consist of ''all and only'' the user-defined free symbols.

=== Arithmetic ===

The real arithmetic theory has two types:
<math>\mathrm{REAL}</math> and <math>\mathrm{INTEGER}</math>
with the latter a subtype of the first.
Its built-in symbols for the usual arithmetic constants
and operators over the type <math>\mathrm{REAL}</math>, each with the expected type:
all numerals 0, 1, ..., as well as - (both unary and binary), +, *, /, <, >, <=, >=.
Application of the binary symbols are in infix form.
Note that + is only binary, and so an expression such as +4 is ill-formed.

Rational values can be expressed in decimal or fractional format,
e.g., 0.1, 23.243241, 1/2, 3/4, and so on.
A leading 0 is mandatory for decimal numbers smaller than one
(e.g., the syntax .3 cannot be used as a shorthand for 0.3).
However, a trailing 0 is ''not'' required for decimals that are whole numbers
(e.g., 3. is allowed as a shorthand for 3.0).
The size of the numerals used in the representation of natural and rational numbers
is unbounded; more accurately, bounded only by the amount of available memory.

=== Bit vectors ===

=== Arrays ===

The theory of arrays is a parametric theory of (total) unary maps.
It comes equipped with mixfix polymorphic selection and update operators, respectively
<center>
<math>\_[\_]</math> and <math>\_\ \mathrm{WITH}\ [\_]\ := \_</math> .
</center>
The semantics of these operators is the expected one:
for all first-order types <math>T_1</math> and <math>T_2</math>,
if <math>a</math> is of type <math>\mathrm{ARRAY}\ T_1 \mathrm{OF}\ T_2</math>,
<math>i</math> is of type <math>T_1</math>, and
<math>v</math> is of type <math>T_2</math>,
* <math>a[i]</math> denotes the value that <math>a</math> associates to index <math>i</math>,
* <math>a\ \mathrm{WITH}\ [i]\ := v</math> denotes a map that associates <math>v</math> to index <math>i</math> and is otherwise identical to <math>a</math>.
Sequential updates can be chained with the shorthand syntax
<math>\_\ \mathrm{WITH}\ [\_]\ := \_, \ldots, [\_]\ := \_</math>.

A: TYPE = ARRAY INT OF REAL;
a: A;
i: INT = 4;

% selection:

elem: REAL = a[i];

% update

a1: A = a WITH [10] := 1/2;

% sequential update
% (syntactic sugar for (a WITH [10] := 2/3) WITH [42] := 3/2)

a2: A = a WITH [10] := 2/3, [42] := 3/2;

Since arrays are just maps, equality between them is extensional, that is,
for two arrays of the same type to be different they have to map at least one
index to differ values.

=== Data types ===

The theory of inductive data types is in fact a family of theories parametrized
by a data type declaration specifying constructors and selectors
for one or more user-defined data types.

No built-in operators other than equality and disequality are provided
for this family in the native language.
Each user-provided data type declaration, however, generates constructor, selector and tester operators
as described in the [[#Inductive Data Types | Inductive Data Types]] section.

=== Tuples and Records ===

Semantically both records and tuples can be seen as special instances
of inductive data types.
CVC4 implements them internally indeed as data types.
In essence, a record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math>
is encoded as a data type of the form

<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\ \ \mathrm{Record} = \mathit{rec}(l_0:T_0, \ldots, l_n:T_n) \\
\mathrm{END};
\end{array}
</math>
</center>

Tuples of length <math>n</math> are in turn special cases of records whose field names are
the numerals from <math>0</math> to <math>n-1</math>.

Externally, tuples and records have their own syntax for constructor and selector operators.
* Records of type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> have the associated record constructor <math>(\#\ l_0 := \_,\; \ldots,\; l_n := \_\ \#)</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.
* Tuples of type <math>[\ T_0, \ldots, T_n\ ]</math> have the associated tuple constructor <math>(\ \_,\; \ldots,\; \_\ )</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.

The selector operators on records and tuples follows a dot notation syntax.

% Record construction and field selection
Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);
k: INT = x.key;
v: REAL = x.weight;

% Tuple construction and projection
y: [REAL, INT, REAL] = ( 4/5, 9, 11/9 );
first_elem: REAL = y.0;
third_elem: REAL = y.2;

Differently from data types, records and tuples are also provided with built-in update operators similar in syntax and semantics to the update operator for arrays.
More precisely, for each record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .l_i\ := \_
</math>
</center>

The operator maps a record <math>r</math> of that type and a value <math>v</math>
of type <math>T_i</math> to the record that stores <math>v</math> in field <math>l_i</math>
and is otherwise identical to <math>r</math>.
Analogously, for each tuple type <math>[T_0, \ldots, T_n]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .i\ := \_
</math>
</center>

with similar semantics.

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = x WITH .weight := 48;

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = y WITH .1 := 3;

Updates to a nested component can be combined in a single WITH operator:

Cache: TYPE = ARRAY [0..100] OF [# addr: INT, data: REAL #];
State: TYPE = [# pc: INT, cache: Cache #];

s0: State;
s1: State = s0 WITH .cache[10].data := 2/3;

Note that, differently from updates on arrays, tuple and record updates are
just additional syntactic sugar.
For instance, the record <code>x1</code> and tuple <code>y1</code> defined above
could have been equivalently defined as follows:

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = (# key := x.key, weight := 48 #);

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = ( y.0, 3, y.1 );

== Commands ==

In addition to declarations of types and function symbols,
the CVC4 native language contains the following commands:

* <math>\mathrm{ASSERT}\ F</math> -- Add the formula <math>F</math> to the current logical context <math>\Gamma</math>.
* [[#CHECKSAT|<math>\mathrm{CHECKSAT}\ F</math>]] -- Check if the formula <math>F</math> is satisfiable in the current logical context (<math>\Gamma \not\models_T \mathrm{NOT}\ F</math>).
* <math>\mathrm{CONTINUE}</math> -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, search for a counter-example different from the current one.
* [[#COUNTEREXAMPLE|<math>\mathrm{COUNTEREXAMPLE}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print the context that is a witness for invalidity/satisfiability.
* [[#COUNTERMODEL|<math>\mathrm{COUNTERMODEL}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print a model that makes the formula invalid/satisfiable. The model is provided in terms of concrete values for each free symbol.
* <math>\mathrm{OPTION}\ o\ v</math> -- Set the command-line option flag <math>o</math> to value <math>v</math>. The argument <math>o</math> is provide as a string literal enclosed in double-quotes and <math>v</math> as an integer value.
* <math>\mathrm{POP}</math> -- Equivalent to <math>\mathrm{POPTO}\ 1</math>
* [[#POPTO|<math>\mathrm{POPTO}\ n</math>]] -- Restore the system to the state it was in right before the most recent call to <math>\mathrm{PUSH}</math> made from stack level <math>n</math>. Note that the current stack level is printed as part of the output of the <math>\mathrm{WHERE}</math> command.
* <math>\mathrm{PUSH}</math> -- Save (checkpoint) the current state of the system.
* [[#QUERY|<math>\mathrm{QUERY}\ F</math>]] -- Check if the formula <math>F</math> is valid in the current logical context (<math>\Gamma\models_T F</math>).
* [[#RESTART|<math>\mathrm{RESTART}\ F</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, repeat the check but with the additional assumption <math>F</math> in the context.
* <math>\mathrm{PRINT}\ t</math> -- Parse and print back the term <math>t</math>.
* <math>\mathrm{TRANSFORM}\ t</math> -- Simplify the term <math>t</math> and print the result.
* <math>\mathrm{WHERE}</math> -- Print all the formulas in the current logical context <math>\Gamma</math>.

The remaining commands take a single argument, given as a string literal enclosed in double-quotes.

* <math>\mathrm{ECHO}\ s</math> -- Print string <math>s</math>
* <math>\mathrm{INCLUDE}\ f</math> -- Read commands from file <math>f</math>.
* <math>\mathrm{TRACE}\ f</math> -- Turn on tracing for the debug flag <math>f</math>.
* <math>\mathrm{UNTRACE}\ f</math> -- Turn off tracing for the debug flag <math>f</math>.

Here, we explain some of the above commands in more detail.

=== QUERY ===

The command <math>\mathrm{QUERY}\ F</math> invokes the core functionality of CVC4 to check
the validity of the formula <math>F</math> with respect to the assertions made thus far,
which constitute the context <math>\Gamma</math>.
The argument <math>F</math> must be well typed term of type <math>\mathrm{BOOLEAN}</math>,
as described in [[#Terms and Formulas | Terms and Formulas]].

The execution of this command always terminates and produces one of three possible answers:
<code>valid</code>, <code>invalid</code>, and <code>unknown</code>.

* A <code>valid</code> answer indicates that <math>\Gamma \models_T F</math>. After a query returning such an answer, the logical context <math>\Gamma</math> is exactly as it was before the query.
* An <code>invalid</code> answer indicates that <math>\Gamma \not\models_T F</math>, that is, there is a model of the background theory <math>T</math> that satisfies <math>\Gamma \cup \{\mathrm{NOT}\ F\}</math>. When <math>\mathrm{QUERY}\ F</math> returns <code>invalid</code>, the logical context <math>\Gamma</math> is augmented with a set <math>\Delta</math> of ground (i.e., variable-free) literals such that <math>\Gamma\cup\Delta</math> is satisfiable in <math>T</math>, but <math>\Gamma\cup\Delta\models_T \mathrm{NOT}\ F</math>. In fact, in this case <math>\Delta</math> ''propositionally entails'' <math>\mathrm{NOT}\ F</math>, in the sense that, every truth assignment to the literals of <math>\Delta</math> that satisfies <math>\Delta</math> falsifies <math>F</math>. We call the new context <math>\Gamma\cup\Delta</math> a ''counterexample'' for <math>F</math>.
* An <code>unknown</code> answer is similar to an <code>invalid</code> answer in that additional literals are added to the context which propositionally entail <math>\mathrm{NOT}\ F</math>. The difference in this case is that CVC4 cannot guarantee that <math>\Gamma\cup\Delta</math> is actually satisfiable in <math>T</math>.

CVC4 may report <code>unknown</code> when the context or the query contains
non-linear arithmetic terms or quantifiers.
In all other cases, it is expected to be sound and complete,
i.e., to report <code>Valid</code> if <math>\Gamma \models_T F</math>
and <code>Invalid</code> otherwise.

After an <code>invalid</code> (resp. <code>unknown</code>) answer,
counterexamples (resp. possible counterexamples) can be obtained with
a <math>\mathrm{WHERE}</math>, <math>\mathrm{COUNTEREXAMPLE}</math>,
or <math>\mathrm{COUNTERMODEL}</math> command.


Since the <math>\mathrm{QUERY}</math> command may modify
the current context, if one needs to check several formulas in a row
in the same context, it is a good idea to surround every
query by a <math>\mathrm{PUSH}</math> and <math>\mathrm{POP}</math> invocation
in order to preserve the context:

PUSH;
QUERY <formula>;
POP;

=== CHECKSAT ===

The command <math>\mathrm{CHECKSAT}\ F</math> behaves identically
to <math>\mathrm{QUERY}\ \mathrm{NOT}\ F</math>.

=== RESTART ===

The command <math>\mathrm{RESTART}\ F</math> can only be invoked after an invalid query.
For example, in an interactive setting:

QUERY <formula>;

CVC4> invalid

RESTART <formula2>;

Functionally, the behavior of the above command sequence is identical to the following:

PUSH;
QUERY <formula>;
POP;
ASSERT <formula2>;
QUERY <formula>;

The advantage of using the <math>\mathrm{RESTART}</math> command is that
the first command sequence may be executed much more efficiently that the second.
The reason is that with <math>\mathrm{RESTART}</math> CVC4 will re-use
what it has learned while answering the previous query rather than starting
over from scratch.

=== COUNTERMODEL ===

[More]

=== COUNTEREXAMPLE ===

[More]

=== POPTO ===

[More]

== Instantiation Patterns ==

CVC4 processes each universally quantified formula in the current context
by adding instances of the formula obtained by replacing its universal variables
with ground terms.
Patterns restrict the choice of ground terms for the quantified variables,
with the goal of controlling the potential explosion of ground instances.
In essence, adding patterns to a formula is a way for the user to tell CVC4
to focus only on certain instances which, in the user's opinion, will be
most helpful during a proof.

In more detail, patterns have the following effect on formulas that are found
in the logical context or get added to it later while CVC4 is trying to prove
the validity of some formula <math>F</math>.

If a formula in the current context starts with an existential quantifier,
CVC4 ''Skolemizes'' it, that is, replaces it in the context with the formula
obtained by substituting the existentially quantified variables
by fresh constants and dropping the quantifier.
Any patterns for the existential quantifier are simply ignored.

If a formula starts with a universal quantifier
<math>\mathrm{FORALL}\; (x_1:T_1, \ldots, x_n:T_n)</math>,
CVC4 adds to the context a number of instances of the formula,
with the goal of using them to prove the query <math>F</math> valid.
An instance is obtained by replacing each <math>x_i</math> with a ground term
of the same type occurring in one of the formulas in the context,
and dropping the universal quantifier.
If <math>x_i</math> occurs in a pattern
<math>\mathrm{PATTERN}\; (t_1, \ldots, t_m)</math> for the quantifier,
it will be instantiated only with terms obtained by simultaneously matching
all the terms in the pattern against ground terms in the current context
<math>\Gamma</math>.

Specifically, the matching process produces one or more substitutions
<math>\sigma</math> for the variables in <math>(t_1, \ldots, t_m)</math>
which satisfy the following invariant:
for each <math>i = 1, \ldots, m</math>, <math>\sigma(t_i)</math> is
a ground term and there is a ground term <math>s_i</math> in <math>\Gamma</math>
such that <math>\Gamma \models_T \sigma(t_i) = s_i</math>.
The variables of <math>(x_1:T_1, \ldots, x_n:T_n)</math> that occur
in the pattern are instantiated only with those substitutions
(while any remaining variables are instantiated arbitrarily).

The Skolemized version or the added instances of a context formula may themselves
start with a quantifier.
The same instantiation process is applied to them too, recursively.

Note that the matching mechanism is not limited to syntactic matching
but is modulo the equations asserted in the context.
Because of decidability and/or efficiency limitations, the matching process
is not exhaustive.
CVC4 will typically miss some substitutions that satisfy the invariant above.
As a consequence, it might fail to prove the validity of the query formula
<math>F</math>, which makes CVC4 incomplete for contexts containing
quantified formulas.
It should be noted though that exhaustive matching, which can be achieved
simply by not specifying any patterns, does not yield completeness anyway
since the instantiation of universal variables is still restricted
to just the ground terms in the context,
whereas in general additional ground terms might be needed.



=CVC4's support for the SMT-LIB language=

==SMT-LIB compliance==

Every effort has been made to make CVC4 compliant with the SMT-LIB 2.0
standard (http://smtlib.org/). However, when parsing SMT-LIB input,
certain default settings don't match what is stated in the official
standard. To make CVC4 adhere more strictly to the standard, use the
"--smtlib" command-line option. Even with this setting, CVC4 is
somewhat lenient; some non-conforming input may still be parsed and
processed.

=The CVC4 library interface (API)=
==Using CVC4 in a C++ project==
==Using CVC4 from Java==
==The compatibility interface==

=Upgrading from CVC3 to CVC4=

==Features not supported by CVC4 (yet)==

===Type Correctness Conditions (TCCs)===

Type Correctness Conditions (TCCs), and the checking of such, are not
supported by CVC4 1.0. Thus, a function defined only on integers can be
applied to REAL (as INT is a subtype of REAL), and CVC4 will not complain,
but may produce strange results. For example:

f : INT -> INT;
ASSERT f(1/3) = 0;
ASSERT f(2/3) = 1;
CHECKSAT;
% sat
COUNTEREXAMPLE;
% f : (INT) -> INT = LAMBDA(x1:INT) : 0;

CVC3 can be used to produce TCCs for this input (with the +dump-tcc option).
The TCC can be checked by CVC3 or another solver. (CVC3 can also check
TCCs while solving with +tcc.)

==If you were using the text interfaces of CVC3==

The native language of all solvers in the CVC family, referred to as the
"presentation language," has undergone some revisions for CVC4. The
most notable is that CVC4 does _not_ add counterexample assertions to
the current assertion set after a SAT/INVALID result. For example:

x, y : INT;
ASSERT x = 1 OR x = 2;
ASSERT y = 1 OR y = 2;
ASSERT x /= y;
CHECKSAT;
% sat
QUERY x = 1;
% invalid
QUERY x = 2;
% invalid

Here, CVC4 responds "invalid" to the second and third queries, because
each has a counterexample (x=2 is a counterexample to the first, and
x=1 is a counterexample to the second). However, CVC3 will respond
with "valid" to one of these two, as the first query (the CHECKSAT)
had the side-effect of locking CVC3 into one of the two cases; the
later queries are effectively querying the counterexample that was
found by the first. CVC4 removes this side-effect of the CHECKSAT and
QUERY commands.

CVC4 supports rational literals (of type REAL) in decimal; CVC3 did not
support decimals.

CVC4 does not have support for the IS_INTEGER predicate.

==If you were using the library ("in-memory") interface of CVC3==
===If you were using CVC3 from C===
===If you were using CVC3 from Java===

=Useful command-line options=

==Statistics==

Statistics can be dumped on exit (both normal and abnormal exits) with
the --statistics command line option.

==Time and resource limits==

CVC4 can be made to self-timeout after a given number of milliseconds.
Use the --tlimit command line option to limit the entire run of
CVC4, or use --tlimit-per to limit each individual query separately.
Preprocessing time is not counted by the time limit, so for some large
inputs which require aggressive preprocessing, you may notice that
--tlimit does not work very well. If you suspect this might be the
case, you can use "-vv" (double verbosity) to see what CVC4 is doing.

Time-limited runs are not deterministic; two consecutive runs with the
same time limit might produce different results (i.e., one may time out
and responds with "unknown", while the other completes and provides an
answer). To ensure that results are reproducible, use --rlimit or
--rlimit-per. These options take a "resource count" (presently, based on
the number of SAT conflicts) that limits the search time. A word of
caution, though: there is no guarantee that runs of different versions of
CVC4 or of different builds of CVC4 (e.g., two CVC4 binaries with different
features enabled, or for different architectures) will interpret the resource
count in the same manner.

CVC4 does not presently have a way to limit its memory use; you may opt
to run it from a shell after using "ulimit" to limit the size of the
heap.

=Dumping API calls or preprocessed output=

=Changing the output language=

=Proof support=

CVC4 1.0 has limited support for proofs, and they are disabled by default.
(Run the configure script with --enable-proof to enable proofs). Proofs
are exported in LFSC format and are limited to the propositional backbone
of the discovered proof (theory lemmas are stated without proof in this
release).

=Portfolio solving=

If enabled at configure-time (./configure --with-portfolio), a second
CVC4 binary will be produced ("pcvc4"). This binary has support for
running multiple instances of CVC4 in different threads. Use --threads=N
to specify the number of threads, and use --thread0="options for thread 0"
--thread1="options for thread 1", etc., to specify a configuration for the
threads. Lemmas are *not* shared between the threads by default; to adjust
this, use the --filter-lemma-length=N option to share lemmas of N literals
(or smaller). (Some lemmas are ineligible for sharing because they include
literals that are "local" to one thread.)

Currently, the portfolio **does not work** with quantifiers or with
the theory of inductive datatypes. These limitations will be addressed
in a future release.

=Emacs support=

For a suggestion of editing CVC4 source code with emacs, see the file
contrib/editing-with-emacs. For a CVC language mode (the native input
language for CVC4), see contrib/cvc-mode.el.

User Manual

2012-11-26T04:31:25Z

Tinelli: /* Arithmetic */

This manual includes lots of information about how to use CVC4.

It is a work in-progress.

= What is CVC4? =

CVC4 is the last of a long line of SMT solvers that started with SVC and includes CVC, CVC-Lite and CVC3.
Technically, it is an automated validity checker for a many-sorted (i.e., typed) first-order logic with built-in theories.
The current built-in theories are the theories of:

* equality over free (aka uninterpreted) function and predicate symbols,
* real and integer linear arithmetic (with some support for non-linear arithmetic),
* bit vectors,
* arrays,
* tuples,
* records,
* user-defined inductive data types.

CVC4 checks whether a given formula <math>\phi</math> is valid in the built-in theories under a given set <math>\Gamma</math> of assumptions, a ''context''.
More precisely, it checks whether

<center>
<math>\Gamma\models_T \phi</math>
</center>

that is, whether <math>\phi</math> is a logical consequence in <math>T</math> of the set of formulas <math>\Gamma</math>, where <math>T</math> is the union of CVC4's built-in theories.

Roughly speaking, when <math>\phi</math> is a universal formula and <math>\Gamma</math> is a set of existential formulas (i.e., when <math>\phi</math> and <math>\Gamma</math> contain at most universal, respectively existential, quantifiers), CVC4 is a decision procedure:
it is guaranteed (modulo bugs and memory limits) to return a correct "valid" or "invalid" answer eventually.
In all other cases, CVC4 is deductively sound but incomplete:
it will never say that an invalid formula is valid,
but it may either never return or give up and return "unknown" for some formulas.

Currently, when CVC4 returns "valid" for a query formula <math>\phi</math> under a context <math>\Gamma</math>
it provides no evidence to back its claim.
Future versions will also return a ''proof certificate'',
a formal proof that <math>\Gamma'\models_T \phi</math> for some subset <math>\Gamma'</math> of <math>\Gamma</math>.

When CVC4 returns "invalid" it can return
both a ''counter-example'' to <math>\phi</math>'s validity under the context <math>\Gamma</math> and a ''counter-model''.
Both a counter-example and a counter-model are a set <math>\Delta</math> of additional formulas consistent with <math>\Gamma</math> in <math>T</math>, but entailing the negation of <math>\phi</math>.
Formally:

<center>
<math>\Gamma \cup \Delta \not\models_T \mathit{false}</math>
and
<math>\Gamma \cup \Delta \models_T \lnot \phi</math>.
</center>

The difference is that a counter-model is given as a set of equations providing a concrete assignment of values for the free symbols in <math>\Gamma</math> and <math>\phi</math>
(see the section on [[#CVC4's native input language|CVC4's native input language]] for more details).

=Obtaining and compiling CVC4=

CVC4 is distributed in the following ways:
* [[#Obtaining_binary_packages|Binary packages]]
* [[#Obtaining_source_packages|Source packages]]
* [[#Source_repository|Source repository checkout]]

==Obtaining binary packages==

[http://cvc4.cs.nyu.edu/builds/ Binary packages are available] for CVC4.
Nightly builds:
* [http://cvc4.cs.nyu.edu/builds/debian/unstable Debian] packages
* [http://cvc4.cs.nyu.edu/builds/x86_64-linux-opt/ Optimized] binaries (statically linked)
* [http://cvc4.cs.nyu.edu/builds/x86_64-linux-dbg/ Debug] binaries (statically linked)

==Obtaining source packages==

[http://cvc4.cs.nyu.edu/builds/src/ Sources are available] from the same site as the binaries.

==Source repository==
The [http://cvc4.cs.nyu.edu/builds/src/ CVC4 source repository] is currently hosted by [http://cims.nyu.edu/ CIMS] and requires a CIMS account. Please contact a member of the development team for access. Please see the additional instructions for [[#Building_CVC4 from_a_repository_checkout]] here.

==Building from source==

===Quick-start instructions===
To compile from a source package:
# Install antlr
# Configure cvc4
# Compile cvc4
# Install cvc4 [optional]
cd contrib
./get-antlr-3.4
cd ..
./configure --with-antlr-dir=`pwd`/antlr-3.4 ANTLR=`pwd`/antlr-3.4/bin/antlr3
make
make check [recommended]
make install [optional]

(To build from a repository checkout, see [[#Building_CVC4_from_a_repository_checkout|below]].)

===Common make Options===
* "''make install''" will install into the "--prefix" option you gave to
the configure script (''/usr/local'' by default).
./configure --prefix=~/install_targets/cvc4 ...
make install
* '''You should run "''make check''"''' before installation to ensure that CVC4 has been
built correctly. In particular, GCC version 4.5.1 seems to have a
bug in the optimizer that results in incorrect behavior (and wrong
results) in many builds. This is a known problem for Minisat, and
since Minisat is at the core of CVC4, a problem for CVC4. "''make check''"
easily detects this problem (by showing a number of FAILed test cases).
It is ok if the unit tests aren't run as part of "''make check''", but all
system tests and regression tests should pass without incident.
* To build API documentation, use "''make doc''". Documentation is produced
under ''builds/doc/'' but is not installed by "''make install''".

Examples and tutorials are not installed with "''make install''." See [[#Examples_and_tutorials_are_not_built_or_installed|below]].

For more information about the build system itself (probably not
necessary for casual users), see the [[#Appendix:_Build_architecture|Appendix]] at the bottom of this
file.

===Common configure Options===
*'''--prefix=PREFIX''' install architecture-independent files in PREFIX (by default /usr/local)
*'''--with-build={production,debug,default,competition}'''
*'''--with-antlr-dir=PATH'''
*'''--with-cln'''/'''--with-gmp''' selects the numbers package to use by default ([[#Optional requirements]])
*'''--enable-static-binary''' build a fully statically-linked binary. (This is recommended for Mac OS X users that want to be able to use gdb.)
*'''ANTLR=PATH''' location of the antlr3 script
*'''--with-boost=DIR''' installation location of the boost libraries (most users will not need this)

See '''./configure --help''' for more.

===Build dependencies===

The following tools and libraries are required to run CVC4. Versions
given are minimum versions; more recent versions should be compatible.

*'''GNU C and C++''' (gcc and g++), reasonably recent versions
*'''GNU Make'''
*'''GNU Bash'''
*'''GMP v4.2''' (GNU Multi-Precision arithmetic library)
*'''libantlr3c v3.2 or v3.4''' (ANTLR parser generator C support library)
*'''The Boost C++ base libraries'''
*'''MacPorts''' [highly recommended if on a Mac; see [[#MacPorts]]]

The hardest to obtain and install is the libantlr3c requirement, and
is explained [[#Installing libantlr3c: ANTLR parser generator C support library|next]].

If "make" is non-GNU on your system, make sure to invoke "gmake" (or
whatever GNU Make is installed as). If your usual shell is not Bash,
the configure script should auto-correct this. If it does not, you'll
see strange shell syntax errors, and you may need to explicitly set
SHELL or CONFIG_SHELL to the location of bash on your system.

====Installing libantlr3c: ANTLR parser generator C support library====

For libantlr3c, you can use the convenience script in
''contrib/get-antlr-3.4'' in the source distribution---this will download, patch, compile and install
libantlr3c into your cvc4 directory as ''cvc4/antlr-3.4/''.
cd contrib
./get-antlr-3.4

CVC4 must be configured with the antlr library installation directory, '''--with-antlr-dir''', and an antlr executable script file, '''ANTLR'''. If libantlr3c was installed via get-antlr-3.4, the following configure line should suffice for CVC44
./configure --with-antlr-dir=`pwd`/antlr-3.4 ANTLR=`pwd`/antlr-3.4/bin/antlr3

For 64 bit machines, libantlr3c needs to be configured with 64 bit explicitly
./configure --enable-64bit ...
The get-antlr-3.4 script makes a guess at whether the machine is 64 bit and adds the appropriate flag.
To force the script to compile 32 bit:
MACHINE_TYPE="x86" ./get-antlr3.4
To force the script to compile 64 bit:
MACHINE_TYPE="x86_64" ./get-antlr3.4

For a longer discussion, instructions for manual installation, and more in depth troubleshooting, see [[Developer's Guide#ANTLR3]].

====MacPorts====

On a Mac, it is '''highly''' recommended that you use MacPorts (see
http://www.macports.org/). Doing so is easy. Then, simply run the
script ''contrib/mac-build'', which installs a few ports from the MacPorts
repository, then compiles and installs antlr3c using the ''get-antlr-3.4''
script. The mac-build script should set you up
with all requirements, and will tell you how to configure CVC4 when it
completes successfully.

====Installing the Boost C++ base libraries====

A Boost package is available on most Linux distributions; check yours
for a package named something like libboost-dev or boost-devel. There
are a number of additional Boost packages in some distributions, but
this "basic" one should be sufficient for building CVC4.

Should you want to install Boost manually, or to learn more about the
Boost project, please visit http://www.boost.org/.

===Optional requirements===

None of these is required, but can improve CVC4 as described below:

*'''Optional: SWIG 2.0.x''' (Simplified Wrapper and Interface Generator)
*'''Optional: CLN v1.3 or newer''' (Class Library for Numbers)
*'''Optional: CUDD v2.4.2 or newer''' (Colorado University Decision Diagram package)
*'''Optional: GNU Readline library''' (for an improved interactive experience)
*'''Optional: The Boost C++ threading library''' (libboost_thread)
*'''Optional: CxxTest unit testing framework'''

SWIG is necessary to build the Java API (and of course a JDK is
necessary, too). SWIG 1.x won't work; you'll need 2.0, and the more
recent the better. On Mac, we've seen SWIG segfault when generating
CVC4 language bindings; version 2.0.8 or higher is recommended to
avoid this. See [[#Language_bindings|Language bindings]] below for build instructions.

CLN is an alternative multiprecision arithmetic package that can offer
better performance and memory footprint than GMP. CLN is covered by
the GNU General Public License, version 3; so if you choose to use
CVC4 with CLN support, you are licensing CVC4 under that same license.
(Usually CVC4's license is more permissive than GPL is; see the file
COPYING in the CVC4 source distribution for details.) Please visit
http://www.ginac.de/CLN/ for more details about CLN.

CUDD is a decision diagram package that changes the behavior of the
CVC4 arithmetic solver in some cases; it may or may not improve the
arithmetic solver's performance. See [[#Building_with_CUDD_(optional)|below]] for instructions on
obtaining and building CUDD.

The GNU Readline library is optionally used to provide command
editing, tab completion, and history functionality at the CVC prompt
(when running in interactive mode). Check your distribution for a
package named "libreadline-dev" or "readline-devel" or similar.

The Boost C++ threading library (often packaged independently of the
Boost base library) is needed to run CVC4 in "portfolio"
(multithreaded) mode. Check your distribution for a package named
"libboost-thread-dev" or similar.

CxxTest is necessary to run CVC4's unit tests (included with the
distribution). Running these is not really required for users of
CVC4; "make check" will skip unit tests if CxxTest isn't available,
and go on to run the extensive system- and regression-tests in the
source tree. However, if you're interested, you can download CxxTest
at http://cxxtest.com/ .

====Building with CUDD (optional)====

CUDD, if desired, must be installed delicately. The CVC4 configure
script attempts to auto-detect the locations and names of CUDD headers
and libraries the way that the Fedora RPMs install them, the way that
our NYU-provided Debian packages install them, and the way they exist
when you download and build the CUDD sources directly. If you install
from Fedora RPMs or our Debian packages, the process should be
completely automatic, since the libraries and headers are installed in
a standard location. If you download the sources yourself, you need
to build them in a special way. Fortunately, the
"contrib/build-cudd-2.4.2-with-libtool.sh" script in the CVC4 source
tree does exactly what you need: it patches the CUDD makefiles to use
libtool, builds the libtool libraries, then reverses the patch to
leave the makefiles as they were. Once you run this script on an
unpacked CUDD 2.4.2 source distribution, then CVC4's configure script
should pick up the libraries if you provide
--with-cudd-dir=/PATH/TO/CUDD/SOURCES.

If you want to force linking to CUDD, provide --with-cudd to the
configure script; this makes it a hard requirement rather than an
optional add-on.

The NYU-provided Debian packaging of CUDD 2.4.2 and CUDD 2.5.0 are
here (along with the CVC4 Debian packages):

deb http://cvc4.cs.nyu.edu/debian/ unstable/

On Debian (and Debian-derived distributions like Ubuntu), you only
need to drop that one line in your /etc/apt/sources.list file, then install with your favorite package manager.

The Debian source package "cudd", available from the same repository,
includes a diff of all changes made to cudd makefiles.

===Language bindings===

There are several options available for using CVC4 from the API.

First, CVC4 offers a complete and flexible API for manipulating
expressions, maintaining a stack of assertions, and checking
satisfiability, and related things. The C++ libraries (libcvc4.so and
libcvc4parser.so) and required headers are installed normally via a
"make install". This API is also available from Java (via CVC4.jar
and libcvc4jni.so) by configuring with --enable-language-bindings=java.
You'll also need SWIG 2.0 installed (and you might need to help
configure find it if you installed it in a nonstandard place with
--with-swig-dir=/path/to/swig/installation). You may also need to
give the configure script the path to your Java headers (in
particular, jni.h). You might do so with (for example):

./configure --enable-language-bindings=java \
JAVA_CPPFLAGS=-I/usr/lib/jvm/java-6-openjdk-amd64/include

There is also a "C++ compatibility API" (''#include <cvc4/cvc3_compat.h>''
and link against libcvc4compat.so) that attempts to maintain
source-level backwards-compatibility with the CVC3 C++ API. The
compatibility library is built by default, and
''--enable-language-bindings=java'' enables the Java compatibility library
(CVC4compat.jar and libcvc4compatjni.so).
''--enable-language-bindings=c'' enables the C compatibility library
(''#include <cvc4/bindings/compat/c/c_interface.h>'' and link against
libcvc4bindings_c_compat.so), and if you want both C and Java
bindings, use ''--enable-language-bindings=c,java''. These compatibility
language bindings do NOT require SWIG.

The ''examples/'' directory in the source distribution includes some basic examples (the "simple vc"
and "simple vc compat" family of examples) of all these interfaces.

In principle, since we use SWIG to generate the native Java API, we
could support other languages as well. However, using CVC4 from other
languages is not supported, nor expected to work, at this time. If
you're interested in helping to develop, maintain, and test a language
binding, please contact us via the users' mailing list at
cvc-users@cs.nyu.edu.

===Building CVC4 from a repository checkout===

The following tools and libraries are additionally required to build
CVC4 from from a repository checkout rather than from a prepared
source tarball.

*'''Automake v1.11'''
*'''Autoconf v2.61'''
*'''Libtool v2.2'''
*'''ANTLR3 v3.2 or v3.4'''
*'''Java Development Kit''' ([http://www.antlr.org/wiki/pages/viewpage.action?pageId=728 required for ANTLR3])

First, use "''./autogen.sh''" to create the configure script. Then
proceed as normal for any distribution tarball. The parsers are
pre-generated for the tarballs, but don't exist in the repository; hence the extra ANTLR3 and JDK requirements to
generate the source code for the parsers, when building from the
repository.

===Examples and tutorials are not built or installed===

Examples are not built by "''make''" or "''make install''". See
''examples/README'' in the source distribution for information on what to find in the ''examples/''
directory, as well as information about building and installing them.

===Appendix: Build architecture===

The build system is generated by automake, libtool, and autoconf. It
is somewhat nonstandard, though, which (for one thing) requires that
GNU Make be used. If you ./configure in the top-level source
directory, the objects will actually all appear in
builds/${arch}/${build_id}. This is to allow multiple, separate
builds in the same place (e.g., an assertions-enabled debugging build
alongside a production build), without changing directories at the
shell. The "current" build is maintained, and you can still use
(e.g.) "make -C src/main" to rebuild objects in just one subdirectory.

You can also create your own build directory inside or outside of the
source tree and configure from there. All objects will then be built
in that directory, and you'll ultimately find the "cvc4" binary in
src/main/, and the libraries under src/ and src/parser/.

=Using the CVC4 binary=

The CVC4 driver binary ("cvc4"), once installed, can be executed directly to enter into interactive mode:

$ cvc4
cvc4 1.0 assertions:off
CVC4>

You can then enter commands into CVC4 interactively:

CVC4> OPTION "incremental";
CVC4> OPTION "produce-models";
CVC4> TRANSFORM 25*25;
625
CVC4> x, y : INT;
CVC4> QUERY x = y;
invalid
CVC4> COUNTERMODEL;
x : INT = -1;
y : INT = 0;
CVC4> ASSERT x >= 0;
CVC4> QUERY x = y;
invalid
CVC4> COUNTERMODEL;
x : INT = 0;
y : INT = 1;
CVC4>

The above example shows two useful options, ''incremental'' and ''produce-models.''

* The ''incremental'' option allows you to issue multiple QUERY (or CHECKSAT) commands, and allows the use of the PUSH and POP commands. Without this option, CVC4 optimizes itself for a single QUERY or CHECKSAT command (though you may issue any number of ASSERT commands). The ''incremental'' option may also be given by passing the ''-i'' command line option to CVC4.
* The ''produce-models'' option allows you to query the model (here, with the COUNTERMODEL command) after an "invalid" QUERY (or "satisfiable" CHECK-SAT). Without it, CVC4 doesn't do the bookkeeping necessary to support model generation. The ''produce-models'' option may also be given by passing the ''-m'' command line option to CVC4.

So, if you invoke CVC4 with ''-im'', you don't need to pass those options at all:

$ cvc4 -im
cvc4 1.0 assertions:off
CVC4> x, y : INT;
CVC4> QUERY x = y;
invalid
CVC4> COUNTERMODEL;
x : INT = -1;
y : INT = 0;
CVC4> ASSERT x >= 0;
CVC4> QUERY x = y;
invalid
CVC4> COUNTERMODEL;
x : INT = 0;
y : INT = 1;
CVC4>

By default, CVC4 operates in [[#CVC4's native input language|CVC-language mode]]. If you enter something that looks like SMT-LIB, it will suggest that you use the "''--lang smt''" command-line option for SMT-LIB mode:

CVC4> (declare-fun x () Int)
Parse Error: <shell>:1.7: In CVC4 presentation language mode, but SMT-LIB format detected. Use --lang smt for SMT-LIB support.
CVC4>

==Verbosity==

CVC4 has various levels of verbosity. By default, CVC4 is pretty quiet, only reporting serious warnings and notices. If you're curious about what it's doing, you can pass CVC4 the ''-v'' option:

$ cvc4 -v file.smt2
Invoking: (set-logic AUFLIRA)
Invoking: (set-info :smt-lib-version 2.000000)
Invoking: (set-info :category "crafted")
Invoking: (set-info :status unsat)
Invoking: (declare-fun x () Real)
''etc...''

For even more verbosity, you can pass CVC4 an ''additional'' ''-v'':

$ cvc4 -vv file.smt2
Invoking: (set-logic AUFLIRA)
Invoking: (set-info :smt-lib-version 2.000000)
Invoking: (set-info :category "crafted")
Invoking: (set-info :status unsat)
Invoking: (declare-fun x () Real)
''etc...''
expanding definitions...
constraining subtypes...
applying substitutions...
simplifying assertions...
doing static learning...
''etc...''

Internally, verbosity is just an integer value. It starts at 0, and with every ''-v'' on the command line it is incremented; with every ''-q'', decremented. It can also be set directly. From CVC language:

CVC4> OPTION "verbosity" 2;

Or from SMT-LIB language:

CVC4> (set-option :verbosity 2)

==Getting statistics==

Statistics can be dumped on exit (both normal and abnormal exits) with the ''--statistics'' command line option.

$ cvc4 --statistics foo.smt2
sat
sat::decisions, 0
sat::propagations, 3
sat::starts, 1
theory::uf::TheoryUF::functionTermsCount, 2
theory::uf::TheoryUF::mergesCount, 2
theory::uf::TheoryUF::termsCount, 6
theory<THEORY_UF>::propagations, 1
driver::filename, foo.smt2
driver::sat/unsat, sat
driver::totalTime, 0.02015373
''[many others]''

Many statistics name-value pairs follow, one comma-separated pair per line.

==Exit status==

The exit status of CVC4 depends on the ''last'' QUERY or CHECK-SAT. If you wish to call CVC4 from a program (e.g., a shell script) and care only about the satisfiability or validity of a single formula, you can pass the ''-q'' option (as described [[#Verbosity|above, under verbosity]]) and check the exit code. With ''-q'', CVC4 should not produce any output unless it encounters a fatal error.

QUERY asks a validity question, and CHECK-SAT a satisfiability question, and these are dual problems; hence the terminology is different, but really "sat" and "invalid" are the same internally, as are "unsat" and "valid":

<table border="1">
<tr><th>Solver's last result</th><th>Exit code</th><th>Notes</th></tr>
<tr><td>'''sat''' or '''invalid'''</td><td>10</td></tr>
<tr><td>'''unsat''' or '''valid'''</td><td>20</td></tr>
<tr><td>'''unknown'''</td><td>0</td><td>could be for any reason: time limit exceeded, no memory, incompleteness..</td></tr>
<tr><td>''no result''</td><td>0</td><td>no query or check-sat command issued</td></tr>
<tr><td>parse errors</td><td>0 (in interactive mode)<br/>1 (otherwise)</td><td>see below</td></tr>
<tr><td>other errors</td><td>1 (usually)</td><td>see below</td></tr>
</table>

Most "normal errors" return a 1 as the exit code, but out of memory conditions, and others, can produce different exit codes. In interactive mode, parse errors are ignored and the next line read; so in interactive mode, you may see an exit code of 0 even in the presence of such an error.

In SMT-LIB mode, an SMT-LIB command script that sets its status via "set-info :status" also affects the exit code. So, for instance, the following SMT-LIB script returns an exit code of 10 even though it contains no "check-sat" command:

(set-logic QF_UF)
(set-info :status sat)
(exit)

Without the "set-info," it would have returned an exit code of 0.

=CVC4's native input language=

The native input language consists of a sequence of symbol declarations and commands, each followed by a semicolon (<code>;</code>).

Any text after the first occurrence of a percent character and to the end of the current line is a comment:

%%% This is a native language comment

== Type System ==

CVC4's type system includes a set of built-in types which can be expanded with additional user-defined types.

The type system consists of ''first-order'' types, ''subtypes'' of first-order types, and ''higher-order'' types, all of which are interpreted as sets.
For convenience, we will sometimes identify below the interpretation of a type with the type itself.

First-order types consist of basic types and structured types. The basic types are <math>\mathrm{BOOLEAN}</math>, <math>\mathrm{REAL}</math>, <math>\mathrm{BITVECTOR}(n)</math> for all <math>n > 0</math>, as well as user-defined basic types (also called uninterpreted types).
The structured types are array, tuple, record types, and ML-style user-defined (inductive) datatypes.

'''Note:''' Currently, subtypes consist only of the built-in subtype <math>\mathrm{INT}</math> of <math>\mathrm{REAL}</math>.

Support for CVC3-style user-defined subtypes will be added in a later release.

Function types are the only higher-order types.
More precisely, they are just second-order types
since function symbols in CVC4, both built-in and user-defined, can take as argument or return only values of
a first-order type.

=== Basic Types ===

==== The BOOLEAN Type ====

The <math>\mathrm{BOOLEAN}</math> type is interpreted as the two-element set of Boolean values
<math>\{\mathrm{TRUE},\; \mathrm{FALSE}\}</math>.

'''Note:''' CVC4's treatment of this type differs from CVC3's where <math>\mathrm{BOOLEAN}</math> is used only as the type of formulas, but not as value type. CVC3 follows the two-tiered structure of classical first-order logic
which distinguishes between formulas and terms, and allows terms to occur in formulas but not vice versa (with the exception of the IF-THEN-ELSE construct).
CVC4 drops the distinction between terms and formulas and defines the latter just as terms of type <math>\mathrm{BOOLEAN}</math>. As such, formulas can occur as subterms of possibly non-Boolean terms.

Example:

[To do]

==== The REAL Type ====

The <math>\mathrm{REAL}</math> type is interpreted as the set of real numbers.

Note that these are the (infinite precision) mathematical reals,
not the floating point numbers.
Support for floating point types is planned for future versions.

x, y : REAL;
QUERY (( x <= y ) AND ( y <= x )) => ( x = y );

==== The INT Type ====

The <math>\mathrm{INT}</math> type is interpreted as the set of integer numbers
and is considered as a subtype of <math>\mathrm{REAL}</math>.
The latter means in particular that it is possible to mix integer and real terms
in expressions without the need of an explicit ''upcasting'' operator.

Note that these are the (infinite precision) mathematical integers,
not the finite precision machine integers used in most programming languages.
The latter are models by [[ #Bitvectors | bit vector ]] types.

x, y : INT;
QUERY ((2 * x + 4 * y <= 1) AND ( y >= x)) => (x <= 0);
z : REAL;
QUERY (2 * x + z <= 3.5) AND (z >= 1);

==== Bit Vector Types ====

For every positive integer <math>n</math>, the type <math>\mathrm{BITVECTOR}(n)</math> is interpreted as the set of all bit vectors of size <math>n</math>.
A rich set of bit vector operators is supported.

==== User-defined Basic Types ====

Users can define new basic types
(often referred to as ''uninterpreted'' types in the SMT literature).
Each such type is interpreted as a set of unspecified cardinality
but disjoint from any other type.

User-defined basic types are created by declarations like the following:

% User declarations of basic types:

MyBrandNewType: TYPE;

Apples, Oranges: TYPE;

=== Structured Types ===

CVC4's structured types are divided in the following families.

==== Array Types ====

Array types are created by the mixfix type constructors <math>\mathrm{ARRAY}\ \_\ \mathrm{OF}\ \_</math>
whose arguments can be instantiated by any value type.

I : TYPE;

%% Array types:

% Arrays with indices from I and values from REAL
Array1: TYPE = ARRAY I OF REAL;

% Arrays with integer indices and array values
Array2: TYPE = ARRAY INT OF (ARRAY INT OF REAL);

% Arrays with integer pair indices and integer values
IntMatrix: TYPE = ARRAY [INT, INT] OF INT;

An array type of the form <math>\mathrm{ARRAY}\ T_1\ \mathrm{OF}\ T_2</math> is interpreted
as the set of all total maps from <math>T_1</math> to <math>T_2</math>.
The main difference with the function type <math>T_1 \to T_2</math> is that arrays,
contrary to functions, are first-class objects of the language, that is, values of an array
type can be arguments or results of functions.
Furthermore, array types come equipped with an update operation.

==== Tuple Types ====

Tuple types are created by the mixfix type constructors

<center>
<math>
\begin{array}{l} [\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ \ ,\ \_\ ] \\[1ex] \ldots \end{array}
</math>
</center>

whose arguments can be instantiated by any value type.

IntArray: TYPE = ARRAY INT OF INT;

% Tuple type declarations

RealPair: TYPE = [REAL, REAL]

MyTuple: TYPE = [ REAL, IntArray, [INT, INT] ];

A tuple type of the form <math>[T_1, \ldots, T_n]</math> is interpreted
as the Cartesian product <math>T_1 \times \cdots \times T_n</math>.

Note that while the types <math>(T_1, \ldots, T_n) \to T</math> and
<math>[T_1 \times \cdots \times T_n] \to T</math> are semantically equivalent,
they are operationally different in CVC4.
The first is the type of functions that take <math>n</math> arguments
of respective type <math>T_1</math>, <math>\ldots</math>, <math>T_n</math>,
while the second is the type of functions that take one argument of an <math>n</math>-tuple type.

==== Record Types ====

Similar to, but more general than tuple types, record types are created by type constructors of the form

<center>
<math>
[\#\ l_1: \_\ ,\ \ldots\ ,\ l_n: \_\ \#]
</math>
</center>

where <math>n > 0</math>, <math>l_1,\ldots, l_n</math> are field labels,
and the arguments can be instantiated with any first-order types.

MyType: TYPE;

% Record declaration

RecordType: TYPE = [# id: REAL, age: INT, info: MyType #];

The order of the fields in a record type is meaningful:
permuting the field names gives a different type.

Note that record types are non-recursive.
For instance, it is not possible to declare a record type called <code>Person</code> containing
a field of type <code>Person</code>.
Recursive types are provided in CVC4 by the more general inductive data types.
(As a matter of fact, both record and tuple types are implemented internally as inductive data types.)

==== Inductive Data Types ====

Inductive data types in CVC4 are similar to inductive data types of functional languages.
They can be parametric or not.

===== Non-Parametric Data Types =====

Non-parametric data types are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1 & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2 & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types, including any <math>A_i</math>.
Such declarations define the data types <math>A_1, \ldots, A_n</math>.
For each data type <math>A_i</math> they introduce:

* constructor symbols <math>cons</math> of type <math>(T_1, \ldots, T_k) \to \mathit{type\_name}_i</math>,
* selector symbols <math>\mathit{sel}_j</math> of type <math>\mathit{type\_name}_i \to T_j</math>, and
* tester symbols <math>\mathit{is\_cons}</math> of type <math>\mathit{type\_name}_i \to \mathrm{BOOLEAN}</math>.

Note that permitting more than one data type to be defined in the same declarations allows
the definition of mutually recursive types.

% simple enumeration type

% implicitly defined are the testers: is_red, is_yellow and is_blue
% (similarly for the other data types)

DATATYPE
PrimaryColor = red | yellow | blue
END;

% infinite set of pairwise distinct values ..., v(-1), v(0), v(1), ...

DATATYPE
Id = v (id: INT)
END;

% ML-style integer lists

DATATYPE
IntList = nil | ins (head: INT, tail: IntList)
END;

% AST for lamba calculus

DATATYPE
Term = var (index: INT)
| apply (arg_1: Term, arg_2: Term)
| lambda (arg: INT, body: Term)
END;

% Trees

DATATYPE
Tree = tree (value: REAL, children: TreeList),
TreeList = nil_tl
| ins_tl (first_t1: Tree, rest_t1: TreeList)
END;

Constructor, selector and tester symbols defined for a data type have global scope.
So, for example, it is not possible for two different data types to use
the same name for a constructor.

An inductive data type is interpreted as a term algebra constructed by the constructor symbols
over some sets of generators.
For example, the type <code>IntList</code> defined above is interpreted as the set
of all terms constructed with <code>nil</code> and <code>ins</code> over the integers.

===== Parametric Data Types =====

Parametric data types are infinite families of (non-parametric) data types
with each family parametrized by one or more type variables.
They are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE}\ [X_1, \ldots, X_p] \\
\begin{array}{ccc}
\ \ A_1 & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2 & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
<math>X_1, \ldots, X_p</math> are type variables,
each <math>A_i</math> is a type name parametrized by some of the variables <math>X_1, \ldots, X_p</math>
and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types,
possibly parametrized by <math>X_1, \ldots, X_p</math>, including any <math>A_i</math>.

% Parametric pairs
DATATYPE [X, Y]
Pair[X, Y] = pair (first: X, second: Y)
END;

% Parametric lists

DATATYPE [X]
List[X] = nil | cons (head: X, tail: List[X])
END;

% Parametric trees using the list type above

DATATYPE [X]
Tree[X] = node (value: X, children: List[Tree[X]]),
END;

The declarations above define infinitely many types of the form
Pair[S,T], List[T] and Tree[T] where S and T are first-order types.
Note that the identifier <code>List</code> above, for example, by itself does not denote a type.
In contrast, the terms <code>List[Real]</code>, <code>List[List[Real]]</code>, <code>List[Tree[INT]]</code>,
and so on do.

===== Restriction to Inductive Types =====

By adopting a term algebra semantics, CVC4 allows only ''inductive'' data types,
that is, data types whose values are essentially (labeled, ordered) finite trees.
Infinite structures such as streams or even finite but cyclic ones
such as circular lists are then excluded.
For instance, none of the following declarations define inductive data types,
and are rejected by CVC4:

DATATYPE
IntStream = s (first:INT, rest: IntStream)
END;

DATATYPE
RationalTree = node1 (child: RationalTree)
| node2 (left_child: RationalTree, right_child:RationalTree)
END;

DATATYPE
T1 = c1 (s1: T2),
T2 = c2 (s2: T1)
END;

In concrete, a declaration of <math>n \geq 1</math> datatypes <math>T_1, \ldots, T_n</math> will be rejected if for any one of the types <math>T_1, \ldots, T_n</math>, it is impossible to build a finite term of that type using only the constructors of <math>T_1, \ldots, T_n</math> and free constants of type other than <math>T_1, \ldots, T_n</math>.

Inductive data types are the only types where the user also chooses names for the built-in operations to:

* construct a value of the type (with the constructors),
* extract components from a value (with the selectors), or
* check if a value was constructed with a certain constructor or not (with the testers).

For all the other types, CVC4 provides predefined names for the built-in operations on the type.

=== Function Types ===

Function (<math>\to</math>) types are created by the mixfix type constructors
<center>
<math>
\begin{array}{l}
\_ \to \_ \\[1ex] (\ \_\ ,\ \_\ ) \to \_
\\[1ex] (\ \_\ ,\ \_\ ,\ \_\ ) \to \_
\\[1ex] \ldots
\end{array}
</math>
</center>
whose arguments can be instantiated by any first-order type.

% Function type declarations

UnaryFunType: TYPE = INT -> REAL;

BinaryFunType: TYPE = (REAL, REAL) -> ARRAY REAL OF REAL;

TernaryFunType: TYPE = (REAL, BITVECTOR(4), INT) -> BOOLEAN;

A function type of the form <math>(T_1, \ldots, T_n) \to T</math> with <math>n > 0</math> is interpreted as the set of all ''total'' functions from the Cartesian product <math>T_1 \times \cdots \times T_n</math> to <math>T</math>.

The example above also shows how to introduce type names.
A name like <code>UnaryFunType</code> above is just an abbreviation for the type <math>\mathrm{INT} \to \mathrm{REAL}</math> and can be used interchangeably with it.

In general, any type defined by a type expression <code>E</code> can be given a name with the declaration:

name : TYPE = E;

=== Type Checking ===

In CVC4, formulas and terms are statically typed at the level of types
(as opposed to subtypes) according to the usual rules of first-order many-sorted logic,
with the main difference that formulas are just terms of type <math>BOOLEAN</math>:

* each variable has one associated first-order type,
* each constant symbol has one or more associated first-order types,
* each function symbol has one or more associated function types,
* the type of a term consisting just of a variable is the type associated to that variable,
* the type of a term consisting just of a constant symbol is the type associated to that constant symbol,
* the term obtained by applying a function symbol <math>f</math> to the terms <math>t_1, \ldots, t_n</math> is <math>T</math> if <math>f</math> has type <math>(T_1, \ldots, T_n) \to T</math> and each <math>t_i</math> has type <math>T_i</math>.

Attempting to enter an ill-typed term will result in an error.

Another significant difference with standard many-sorted logic is that
some built-in symbols are parametrically polymorphic.
For instance, the function symbol for extracting the element of any array has
type <math>(\mathit{ARRAY}\ T_1\ \mathit{OF}\ T_2,\; T_1) \to T_2</math>
for all first-order types <math>T_1, T_2</math>.

==== Type Ascription ====

By the type inference rules above some terms might have more than one type.
This can happen with terms built with polymorphic data type constructors
that have more than one return type for the same input type.
In that case, a type ascription operator (<code>::</code>) must be applied
to the constructor to specify the intended return type.

DATATYPE [X]
List[X] = nil | cons (head: X, tail: List[X])
END;

ASSERT y = cons(1, nil::List[REAL]);

DATATYPE [X, Y]
Union[X, Y] = left(val_l: X) | right(val_r: Y)
END;

ASSERT y = left::Union[BOOLEAN, REAL](TRUE);

The constant symbol <math>\mathrm{nil}</math> declared above has infinitely many types
(<math>\mathrm{List}[\mathrm{REAL}]</math>, <math>\mathrm{List}[\mathrm{BOOLEAN}]</math>,
<math>\mathrm{List}[[\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{List}[\mathrm{List}[\mathrm{REAL}]]</math>, ...)
CVC4's type checker requires the user to indicate explicitly the type
of each occurrence of <code>nil</code> in a term.
Similarly,
the injection operator <code>left</code> has infinitely many return types
for the same input type, for instance:
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{REAL}]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, [\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{List}[\mathrm{REAL}]]</math>,
and so on.
Applications of <code>left</code> need to specify the intended returned typed, as shown above.

== Terms and Formulas ==

In addition to type expressions, CVC4 has expressions for terms and for formulas
(i.e., terms of type <math>\mathrm{BOOLEAN}</math>).
By and large, these are standard first-order terms built out of typed variables,
predefined theory-specific operators, free (i.e., user-defined) function symbols,
and quantifiers.
Extensions include an if-then-else operator, lambda abstractions, and local symbol
declarations, as illustrated below.
Note that these extensions still keep CVC4's language first-order.
In particular, lambda abstractions are restricted to take and return only terms of
a first-order type.
Similarly, variables can only be of a first-order type.

A number of built-in function symbols (for instance, the arithmetic ones) are used
as infix operators. All user-defined symbols are used as prefix ones.

User-defined, i.e., free, function symbols include ''constant symbols'' and
''predicate symbols'', respectively nullary function symbols and function symbols
with a <math>\mathrm{BOOLEAN}</math> return type.
These symbols are introduced with global declarations of the form
<math> f_1, \ldots, f_m: T;</math>
where <math>m > 0</math>, <math>f_i</math> are the names of the symbols and
<math>T</math> is their type:

% integer constants

a, b, c: INT;

% real constants

x, y, z: REAL;

% unary function

f1: REAL -> REAL;

% binary function

f2: (REAL, INT) -> REAL;

% unary function with a tuple argument

f3: [INT, REAL] -> BOOLEAN;

% binary predicate

p: (INT, REAL) -> BOOLEAN;

% Propositional "variables"

P, Q; BOOLEAN;

Like type declarations, function symbol declarations like the above have global scope
and must be unique.
In other words, it is not possible to declare a function symbol globally more than once
in the same lexical scope.
This entails among other things that globally-defined free symbols cannot be overloaded
with different types and that theory symbols cannot be redeclared globally as free symbols.

=== Global symbol definitions ===

As with types, a function symbol can be defined as the name of another term
of the corresponding type.
With constant symbols, this is done with a declaration of the form <math>f:T = t;</math> :

c: INT;

i: INT = 5 + 3*c; % i is effectively a shorthand for 5 + 3*c

j: REAL = 3/4;

t: [REAL, INT] = (2/3, -4);

r: [# key: INT, value: REAL #] = (# key := 4, value := (c + 1)/2 #);

f: BOOLEAN = FORALL (x:INT): x <= 0 OR x > c ;

A restriction on constants of type <math>\mathit{BOOLEAN}</math> is that their value
can only be a closed formula, that is, a formula with no free variables.

A term and its name can be used interchangeably in later expressions.
Named terms are often useful for shared subterms (terms used several times in different places)
since their use can make the input exponentially more concise.
Named terms are processed very efficiently by CVC4.
It is much more efficient to associate a complex term with a name directly rather than
to declare a constant and later assert that it is equal to the same term.
This point is explained in more detail later in section [[Commands | Commands]].

More generally, in CVC4 one can associate a term to function symbols of any arity.
For non-constant function symbols this is done with a declaration of the form

<center>
<math>f:(T_1, \ldots, T_n) \to T = \mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t\;;</math>
</center>

where <math>t</math> is any term of type <math>T</math> with free variables
in <math>\{x_1, \ldots, x_n\}</math>.
The lambda binder has the usual semantics and conforms to the usual lexical scoping rules:
within the term <math>t</math> the declaration of the symbols <math>x_1, \ldots, x_n</math>
as local variables of respective type <math>T_1, \ldots, T_n</math> hides any previous
declarations of those symbols that are in scope.

As a general shorthand, when <math>k</math> consecutive types
<math>T_i, \ldots, T_{i+k-1}</math> in the lambda expression
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t</math> are identical, the syntax
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x_i,\ldots, x_{i+k-1}:T_i,\ldots, x:T_n): t</math>
can also be used.

% Global declaration of x as a unary function symbol

x: REAL -> REAL;

% Local declarations of x as variable (hiding the global one)

f: REAL -> REAL = LAMBDA (x: REAL): 2*x + 3;

p: (INT, INT) -> BOOLEAN = LAMBDA (x,i: INT): i*x - 1 > 0;

g: (REAL, INT) -> [REAL, INT] = LAMBDA (x: REAL, i:INT): (x + 1, i - 3);

Note that lambda definitions are not recursive:
the symbol being defined cannot occur in the body of the lambda term.
They should be understood as macros.
For instance, any occurrence of the term <math>f(t)</math>
where <math>f</math> is as defined above will be treated
as if it was the term <math>(2*t + 3)</math>.

=== Local symbol definitions ===

Constant and function symbols can also be declared locally anywhere within a term
by means of a let binder.
This is done with a declaration of the form

<center>
<math>
\mathrm{LET}\ f = t \ \mathrm{IN}\ t' ;
</math>
</center>

where <math>t</math> is a term with no free variables, possibly a lambda term.
Let binders can be nested arbitrarily and follow the usual lexical scoping rules.
The following general form
<center>
<math>
\mathrm{LET}\ f_1 = t_1, f_2 = t_2, \ldots, f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>
can be use above can used as a shorthand for
<center>
<math>
\mathrm{LET}\ f_1 = t_1\ \mathrm{IN}\
\mathrm{LET}\ f_2 = t_2\ \mathrm{IN}\
\ldots \
\mathrm{LET}\ f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>

t: REAL =
LET x1 = 42,
g = LAMBDA(x:INT): x + 1,
x2 = 2*x1 + 7/2
IN
(LET x3 = g(x1) IN x3 + x2) / x1;

Note that the same symbol = is used, unambiguously, in the syntax of global declarations,
let declarations, and as a predicate symbol.

'''Note:'''
A <math>\mathrm{LET}</math> term with a multiple symbols defines them sequentially.
A parallel version of the <math>\mathrm{LET}</math> construct will be introduced in a later version.

== Built-in theories and their symbols ==

In addition to user-defined symbols, CVC4 terms can use a number of predefined symbols:
the logical symbols, such as <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, etc.,
as well as theory symbols, function symbols belonging to one of the built-in theories.
They are described next, with the theory symbols grouped by theory.

=== Logical Symbols ===

The logical symbols in CVC4's language include
the equality and disequality predicate symbols, respectively written as = and /=,
the multiarity disequality symbol <math>\mathrm{DISTINCT}</math>,
together with the logical constants <math>\mathrm{TRUE}</math>, <math>\mathrm{FALSE}</math>,
the connectives <math>\mathrm{NOT}</math>, <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, <math>\mathrm{XOR}</math>, <math>\Rightarrow</math>, <math>\Leftrightarrow</math>, and
the first-order quantifiers <math>\mathrm{EXISTS}</math> and <math>\mathrm{FORALL}</math>,
all with the standard many-sorted logic semantics.

The binary connectives have infix syntax and type
<math>(\mathrm{BOOLEAN},\mathrm{BOOLEAN}) \to \mathrm{BOOLEAN}</math>.
The symbols = and /=, which are also infix, are instead parametrically polymorphic,
having type <math>(T,T) \to \mathrm{BOOLEAN}</math>
for every first-order type <math>T</math>.
They are interpreted respectively as the identity relation and its complement.

The DISTINCT symbol is both overloaded and polymorphic.
It has type <math>(T,...,T) \to \mathrm{BOOLEAN}</math>
for every sequence <math>(T,...,T)</math> of length <math>n > 0</math>
and first-order type <math>T</math>.
For each <math>n > 0</math>, it is interpreted as the relation
that holds exactly for tuples of pairwise distinct elements.

The syntax for quantifiers is similar to that of the lambda binder.

Here is an example of a formula built just of these logical symbols and variables:

A, B: TYPE;

q: BOOLEAN = FORALL (x,y: A, i,j,k: B):
i = j AND i /= k => EXISTS (z: A): x /= z OR z /= y;

Binding and scoping of quantified variables follows the same rules as
in let expressions.
In particular, a quantifier will shadow in its scope any constant and function symbols
with the same name as one of the variables it quantifies:

A: TYPE;
i, j: INT;

% The first occurrence of i and of j in f are constant symbols,
% the others are variables.

f: BOOLEAN = i = j AND FORALL (i,j: A): i = j OR i /= j;

Optionally, it is also possible to specify instantiation patterns
for quantified variables.
The general syntax for a quantified formula <math>\psi</math> with patterns is

<center>
<math>
Q\;(x_1:T_1, \ldots, x_k:T_k):\; p_1: \ldots\; p_n:\; \varphi
</math>
</center>

where <math>n \geq 0</math>, <math>Q</math> is
either <math>\mathrm{FORALL}</math> or <math>\mathrm{EXISTS}</math>,
<math>\varphi</math> is a term of type <math>\mathrm{BOOLEAN}</math>,
and each of the <math>p_i</math>'s,
a pattern for the quantifier <math>Q\;(x_1:T_1, \ldots, x_k:T_k)</math>, has the form

<center>
<math>
\mathrm{PATTERN}\; (t_1, \ldots, t_m)
</math>
</center>

where <math>m > 0</math> and <math>t_1, \ldots, t_m</math> are
arbitrary binder-free terms (no lets, no quantifiers).
Those terms can contain (free) variables, typically, but not exclusively,
drawn from <math>x_1, \ldots, x_k</math>.
(Additional variables can occur if <math>\psi</math> occurs in a bigger formula
binding those variables.)

A: TYPE;
b, c: A;
p, q: A -> BOOLEAN;
r: (A, A) -> BOOLEAN;

ASSERT FORALL (x0, x1, x2: A):
PATTERN (r(x0, x1), r(x1, x2)):
(r(x0, x1) AND r(x1, x2)) => r(x0, x2) ;

ASSERT FORALL (x: A):
PATTERN (r(x, b)):
PATTERN (r(x, c)):
p(x) => q(x) ;

ASSERT EXISTS (y: A):
FORALL (x: A):
PATTERN (r(x, y), p(y)):
r(x, y) => q(x) ;

Patterns have no logical meaning:
adding them to a formula does not change its semantics.
Their purpose is purely operational, as explained in
the [[#Instantiation Patterns | Instantiation Patterns]] section.

In addition to these constructs, CVC4 also has a general mixfix conditional operator
of the form

<center>
<math>
\mathrm{IF}\ b\ \mathrm{THEN}\ t\ \mathrm{ELSIF}\ b_1\ \mathrm{THEN}\ t_1\ \ldots\ \mathrm{ELSIF}\ b_n\ \mathrm{THEN}\ t_n\ \mathrm{ELSE}\ t_{n+1}\ \mathrm{ENDIF}
</math>
</center>

with <math>n \geq 0</math> where
<math>b, b_1, \ldots, b_n</math> are terms of type <math>\mathrm{BOOLEAN}</math> and
<math>t, t_1, \ldots, t_n, t_{n+1}</math> are terms of the same first-order type <math>T</math>:

% Conditional term
x, y, z, w: REAL;

t: REAL =
IF x > 0 THEN y
ELSIF x >= 1 THEN z
ELSIF x > 2 THEN w
ELSE 2/3 ENDIF;

=== User-defined Functions and Types ===

The theory of user-defined functions,also know in the SMT literature as
the theory ''Equality over Uninterpreted Functions'', or ''EUF'', is in effect
a family of theories of equality parametrized by the basic types and the free symbols
a user can define during a run of CVC4.

This theory has no built-in symbols (other than the logical ones).
Its types consist of ''all and only'' the user-defined types.
Its function symbols consist of ''all and only'' the user-defined free symbols.

=== Arithmetic ===

The real arithmetic theory has two types:
<math>\mathrm{REAL}</math> and <math>\mathrm{INTEGER}</math>
with the latter a subtype of the first.
Its built-in symbols for the usual arithmetic constants
and operators over the type <math>\mathrm{REAL}</math>, each with the expected type:
all numerals 0, 1, ..., as well as - (both unary and binary), +, *, /, <, >, <=, >=.
Application of the binary symbols are in infix form.
Note that + is only binary, and so an expression such as +4 is ill-formed.

Rational values can be expressed in decimal or fractional format,
e.g., 0.1, 23.243241, 1/2, 3/4, and so on.
A leading 0 is mandatory for decimal numbers smaller than one
(e.g., the syntax .3 cannot be used as a shorthand for 0.3).
However, a trailing 0 is ''not'' required for decimals that are whole numbers
(e.g., 3. is allowed as a shorthand for 3.0).
The size of the numerals used in the representation of natural and rational numbers
is unbounded; more accurately, bounded only by the amount of available memory.

=== Bit vectors ===

=== Arrays ===

The theory of arrays is a parametric theory of (total) unary maps.
It comes equipped with mixfix polymorphic selection and update operators, respectively
<center>
<math>\_[\_]</math> and <math>\_\ \mathrm{WITH}\ [\_]\ := \_</math> .
</center>
The semantics of these operators is the expected one:
for all first-order types <math>T_1</math> and <math>T_2</math>,
if <math>a</math> is of type <math>\mathrm{ARRAY}\ T_1 \mathrm{OF}\ T_2</math>,
<math>i</math> is of type <math>T_1</math>, and
<math>v</math> is of type <math>T_2</math>,
* <math>a[i]</math> denotes the value that <math>a</math> associates to index <math>i</math>,
* <math>a\ \mathrm{WITH}\ [i]\ := v</math> denotes a map that associates <math>v</math> to index <math>i</math> and is otherwise identical to <math>a</math>.
Sequential updates can be chained with the shorthand syntax
<math>\_\ \mathrm{WITH}\ [\_]\ := \_, \ldots, [\_]\ := \_</math>.

A: TYPE = ARRAY INT OF REAL;
a: A;
i: INT = 4;

% selection:

elem: REAL = a[i];

% update

a1: A = a WITH [10] := 1/2;

% sequential update
% (syntactic sugar for (a WITH [10] := 2/3) WITH [42] := 3/2)

a2: A = a WITH [10] := 2/3, [42] := 3/2;

Since arrays are just maps, equality between them is extensional, that is,
for two arrays of the same type to be different they have to map at least one
index to differ values.

=== Data types ===

The theory of inductive data types is in fact a family of theories parametrized
by a data type declaration specifying constructors and selectors
for one or more user-defined data types.

No built-in operators other than equality and disequality are provided
for this family in the native language.
Each user-provided data type declaration, however, generates constructor, selector and tester operators
as described in the [[#Inductive Data Types | Inductive Data Types]] section.

=== Tuples and Records ===

Semantically both records and tuples can be seen as special instances
of inductive data types.
CVC4 implements them internally indeed as data types.
In essence, a record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math>
is encoded as a data type of the form

<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\ \ \mathrm{Record} = \mathit{rec}(l_0:T_0, \ldots, l_n:T_n) \\
\mathrm{END};
\end{array}
</math>
</center>

Tuples of length <math>n</math> are in turn special cases of records whose field names are
the numerals from <math>0</math> to <math>n-1</math>.

Externally, tuples and records have their own syntax for constructor and selector operators.
* Records of type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> have the associated record constructor <math>(\#\ l_0 := \_,\; \ldots,\; l_n := \_\ \#)</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.
* Tuples of type <math>[\ T_0, \ldots, T_n\ ]</math> have the associated tuple constructor <math>(\ \_,\; \ldots,\; \_\ )</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.

The selector operators on records and tuples follows a dot notation syntax.

% Record construction and field selection
Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);
k: INT = x.key;
v: REAL = x.weight;

% Tuple construction and projection
y: [REAL, INT, REAL] = ( 4/5, 9, 11/9 );
first_elem: REAL = y.0;
third_elem: REAL = y.2;

Differently from data types, records and tuples are also provided with built-in update operators similar in syntax and semantics to the update operator for arrays.
More precisely, for each record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .l_i\ := \_
</math>
</center>

The operator maps a record <math>r</math> of that type and a value <math>v</math>
of type <math>T_i</math> to the record that stores <math>v</math> in field <math>l_i</math>
and is otherwise identical to <math>r</math>.
Analogously, for each tuple type <math>[T_0, \ldots, T_n]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .i\ := \_
</math>
</center>

with similar semantics.

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = x WITH .weight := 48;

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = y WITH .1 := 3;

Updates to a nested component can be combined in a single WITH operator:

Cache: TYPE = ARRAY [0..100] OF [# addr: INT, data: REAL #];
State: TYPE = [# pc: INT, cache: Cache #];

s0: State;
s1: State = s0 WITH .cache[10].data := 2/3;

Note that, differently from updates on arrays, tuple and record updates are
just additional syntactic sugar.
For instance, the record <code>x1</code> and tuple <code>y1</code> defined above
could have been equivalently defined as follows:

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = (# key := x.key, weight := 48 #);

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = ( y.0, 3, y.1 );

== Commands ==

In addition to declarations of types and function symbols,
the CVC4 native language contains the following commands:

* <math>\mathrm{ASSERT}\ F</math> -- Add the formula <math>F</math> to the current logical context <math>\Gamma</math>.
* [[#CHECKSAT|<math>\mathrm{CHECKSAT}\ F</math>]] -- Check if the formula <math>F</math> is satisfiable in the current logical context (<math>\Gamma \not\models_T \mathrm{NOT}\ F</math>).
* <math>\mathrm{CONTINUE}</math> -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, search for a counter-example different from the current one.
* [[#COUNTEREXAMPLE|<math>\mathrm{COUNTEREXAMPLE}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print the context that is a witness for invalidity/satisfiability.
* [[#COUNTERMODEL|<math>\mathrm{COUNTERMODEL}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print a model that makes the formula invalid/satisfiable. The model is provided in terms of concrete values for each free symbol.
* <math>\mathrm{OPTION}\ o\ v</math> -- Set the command-line option flag <math>o</math> to value <math>v</math>. The argument <math>o</math> is provide as a string literal enclosed in double-quotes and <math>v</math> as an integer value.
* <math>\mathrm{POP}</math> -- Equivalent to <math>\mathrm{POPTO}\ 1</math>
* [[#POPTO|<math>\mathrm{POPTO}\ n</math>]] -- Restore the system to the state it was in right before the most recent call to <math>\mathrm{PUSH}</math> made from stack level <math>n</math>. Note that the current stack level is printed as part of the output of the <math>\mathrm{WHERE}</math> command.
* <math>\mathrm{PUSH}</math> -- Save (checkpoint) the current state of the system.
* [[#QUERY|<math>\mathrm{QUERY}\ F</math>]] -- Check if the formula <math>F</math> is valid in the current logical context (<math>\Gamma\models_T F</math>).
* [[#RESTART|<math>\mathrm{RESTART}\ F</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, repeat the check but with the additional assumption <math>F</math> in the context.
* <math>\mathrm{PRINT}\ t</math> -- Parse and print back the term <math>t</math>.
* <math>\mathrm{TRANSFORM}\ t</math> -- Simplify the term <math>t</math> and print the result.
* <math>\mathrm{WHERE}</math> -- Print all the formulas in the current logical context <math>\Gamma</math>.

The remaining commands take a single argument, given as a string literal enclosed in double-quotes.

* <math>\mathrm{ECHO}\ s</math> -- Print string <math>s</math>
* <math>\mathrm{INCLUDE}\ f</math> -- Read commands from file <math>f</math>.
* <math>\mathrm{TRACE}\ f</math> -- Turn on tracing for the debug flag <math>f</math>.
* <math>\mathrm{UNTRACE}\ f</math> -- Turn off tracing for the debug flag <math>f</math>.

Here, we explain some of the above commands in more detail.

=== QUERY ===

The command <math>\mathrm{QUERY}\ F</math> invokes the core functionality of CVC4 to check
the validity of the formula <math>F</math> with respect to the assertions made thus far,
which constitute the context <math>\Gamma</math>.
The argument <math>F</math> must be well typed term of type <math>\mathrm{BOOLEAN}</math>,
as described in [[#Terms and Formulas | Terms and Formulas]].

The execution of this command always terminates and produces one of three possible answers:
<code>valid</code>, <code>invalid</code>, and <code>unknown</code>.

* A <code>valid</code> answer indicates that <math>\Gamma \models_T F</math>. After a query returning such an answer, the logical context <math>\Gamma</math> is exactly as it was before the query.
* An <code>invalid</code> answer indicates that <math>\Gamma \not\models_T F</math>, that is, there is a model of the background theory <math>T</math> that satisfies <math>\Gamma \cup \{\mathrm{NOT}\ F\}</math>. When <math>\mathrm{QUERY}\ F</math> returns <code>invalid</code>, the logical context <math>\Gamma</math> is augmented with a set <math>\Delta</math> of ground (i.e., variable-free) literals such that <math>\Gamma\cup\Delta</math> is satisfiable in <math>T</math>, but <math>\Gamma\cup\Delta\models_T \mathrm{NOT}\ F</math>. In fact, in this case <math>\Delta</math> ''propositionally entails'' <math>\mathrm{NOT}\ F</math>, in the sense that, every truth assignment to the literals of <math>\Delta</math> that satisfies <math>\Delta</math> falsifies <math>F</math>. We call the new context <math>\Gamma\cup\Delta</math> a ''counterexample'' for <math>F</math>.
* An <code>unknown</code> answer is similar to an <code>invalid</code> answer in that additional literals are added to the context which propositionally entail <math>\mathrm{NOT}\ F</math>. The difference in this case is that CVC4 cannot guarantee that <math>\Gamma\cup\Delta</math> is actually satisfiable in <math>T</math>.

CVC4 may report <code>unknown</code> when the context or the query contains
non-linear arithmetic terms or quantifiers.
In all other cases, it is expected to be sound and complete,
i.e., to report <code>Valid</code> if <math>\Gamma \models_T F</math>
and <code>Invalid</code> otherwise.

After an <code>invalid</code> (resp. <code>unknown</code>) answer,
counterexamples (resp. possible counterexamples) can be obtained with
a <math>\mathrm{WHERE}</math>, <math>\mathrm{COUNTEREXAMPLE}</math>,
or <math>\mathrm{COUNTERMODEL}</math> command.


Since the <math>\mathrm{QUERY}</math> command may modify
the current context, if one needs to check several formulas in a row
in the same context, it is a good idea to surround every
query by a <math>\mathrm{PUSH}</math> and <math>\mathrm{POP}</math> invocation
in order to preserve the context:

PUSH;
QUERY <formula>;
POP;

=== CHECKSAT ===

The command <math>\mathrm{CHECKSAT}\ F</math> behaves identically
to <math>\mathrm{QUERY}\ \mathrm{NOT}\ F</math>.

=== RESTART ===

The command <math>\mathrm{RESTART}\ F</math> can only be invoked after an invalid query.
For example, in an interactive setting:

QUERY <formula>;

CVC4> invalid

RESTART <formula2>;

Functionally, the behavior of the above command sequence is identical to the following:

PUSH;
QUERY <formula>;
POP;
ASSERT <formula2>;
QUERY <formula>;

The advantage of using the <math>\mathrm{RESTART}</math> command is that
the first command sequence may be executed much more efficiently that the second.
The reason is that with <math>\mathrm{RESTART}</math> CVC4 will re-use
what it has learned while answering the previous query rather than starting
over from scratch.

=== COUNTERMODEL ===

[More]

=== COUNTEREXAMPLE ===

[More]

=== POPTO ===

[More]

== Instantiation Patterns ==

CVC4 processes each universally quantified formula in the current context
by adding instances of the formula obtained by replacing its universal variables
with ground terms.
Patterns restrict the choice of ground terms for the quantified variables,
with the goal of controlling the potential explosion of ground instances.
In essence, adding patterns to a formula is a way for the user to tell CVC4
to focus only on certain instances which, in the user's opinion, will be
most helpful during a proof.

In more detail, patterns have the following effect on formulas that are found
in the logical context or get added to it later while CVC4 is trying to prove
the validity of some formula <math>F</math>.

If a formula in the current context starts with an existential quantifier,
CVC4 ''Skolemizes'' it, that is, replaces it in the context with the formula
obtained by substituting the existentially quantified variables
by fresh constants and dropping the quantifier.
Any patterns for the existential quantifier are simply ignored.

If a formula starts with a universal quantifier
<math>\mathrm{FORALL}\; (x_1:T_1, \ldots, x_n:T_n)</math>,
CVC4 adds to the context a number of instances of the formula,
with the goal of using them to prove the query <math>F</math> valid.
An instance is obtained by replacing each <math>x_i</math> with a ground term
of the same type occurring in one of the formulas in the context,
and dropping the universal quantifier.
If <math>x_i</math> occurs in a pattern
<math>\mathrm{PATTERN}\; (t_1, \ldots, t_m)</math> for the quantifier,
it will be instantiated only with terms obtained by simultaneously matching
all the terms in the pattern against ground terms in the current context
<math>\Gamma</math>.

Specifically, the matching process produces one or more substitutions
<math>\sigma</math> for the variables in <math>(t_1, \ldots, t_m)</math>
which satisfy the following invariant:
for each <math>i = 1, \ldots, m</math>, <math>\sigma(t_i)</math> is
a ground term and there is a ground term <math>s_i</math> in <math>\Gamma</math>
such that <math>\Gamma \models_T \sigma(t_i) = s_i</math>.
The variables of <math>(x_1:T_1, \ldots, x_n:T_n)</math> that occur
in the pattern are instantiated only with those substitutions
(while any remaining variables are instantiated arbitrarily).

The Skolemized version or the added instances of a context formula may themselves
start with a quantifier.
The same instantiation process is applied to them too, recursively.

Note that the matching mechanism is not limited to syntactic matching
but is modulo the equations asserted in the context.
Because of decidability and/or efficiency limitations, the matching process
is not exhaustive.
CVC4 will typically miss some substitutions that satisfy the invariant above.
As a consequence, it might fail to prove the validity of the query formula
<math>F</math>, which makes CVC4 incomplete for contexts containing
quantified formulas.
It should be noted though that exhaustive matching, which can be achieved
simply by not specifying any patterns, does not yield completeness anyway
since the instantiation of universal variables is still restricted
to just the ground terms in the context,
whereas in general additional ground terms might be needed.



=CVC4's support for the SMT-LIB language=

==SMT-LIB compliance==

Every effort has been made to make CVC4 compliant with the SMT-LIB 2.0
standard (http://smtlib.org/). However, when parsing SMT-LIB input,
certain default settings don't match what is stated in the official
standard. To make CVC4 adhere more strictly to the standard, use the
"--smtlib" command-line option. Even with this setting, CVC4 is
somewhat lenient; some non-conforming input may still be parsed and
processed.

=The CVC4 library interface (API)=
==Using CVC4 in a C++ project==
==Using CVC4 from Java==
==The compatibility interface==

=Upgrading from CVC3 to CVC4=

==Features not supported by CVC4 (yet)==

===Type Correctness Conditions (TCCs)===

Type Correctness Conditions (TCCs), and the checking of such, are not
supported by CVC4 1.0. Thus, a function defined only on integers can be
applied to REAL (as INT is a subtype of REAL), and CVC4 will not complain,
but may produce strange results. For example:

f : INT -> INT;
ASSERT f(1/3) = 0;
ASSERT f(2/3) = 1;
CHECKSAT;
% sat
COUNTEREXAMPLE;
% f : (INT) -> INT = LAMBDA(x1:INT) : 0;

CVC3 can be used to produce TCCs for this input (with the +dump-tcc option).
The TCC can be checked by CVC3 or another solver. (CVC3 can also check
TCCs while solving with +tcc.)

==If you were using the text interfaces of CVC3==

The native language of all solvers in the CVC family, referred to as the
"presentation language," has undergone some revisions for CVC4. The
most notable is that CVC4 does _not_ add counterexample assertions to
the current assertion set after a SAT/INVALID result. For example:

x, y : INT;
ASSERT x = 1 OR x = 2;
ASSERT y = 1 OR y = 2;
ASSERT x /= y;
CHECKSAT;
% sat
QUERY x = 1;
% invalid
QUERY x = 2;
% invalid

Here, CVC4 responds "invalid" to the second and third queries, because
each has a counterexample (x=2 is a counterexample to the first, and
x=1 is a counterexample to the second). However, CVC3 will respond
with "valid" to one of these two, as the first query (the CHECKSAT)
had the side-effect of locking CVC3 into one of the two cases; the
later queries are effectively querying the counterexample that was
found by the first. CVC4 removes this side-effect of the CHECKSAT and
QUERY commands.

CVC4 supports rational literals (of type REAL) in decimal; CVC3 did not
support decimals.

CVC4 does not have support for the IS_INTEGER predicate.

==If you were using the library ("in-memory") interface of CVC3==
===If you were using CVC3 from C===
===If you were using CVC3 from Java===

=Useful command-line options=

==Statistics==

Statistics can be dumped on exit (both normal and abnormal exits) with
the --statistics command line option.

==Time and resource limits==

CVC4 can be made to self-timeout after a given number of milliseconds.
Use the --tlimit command line option to limit the entire run of
CVC4, or use --tlimit-per to limit each individual query separately.
Preprocessing time is not counted by the time limit, so for some large
inputs which require aggressive preprocessing, you may notice that
--tlimit does not work very well. If you suspect this might be the
case, you can use "-vv" (double verbosity) to see what CVC4 is doing.

Time-limited runs are not deterministic; two consecutive runs with the
same time limit might produce different results (i.e., one may time out
and responds with "unknown", while the other completes and provides an
answer). To ensure that results are reproducible, use --rlimit or
--rlimit-per. These options take a "resource count" (presently, based on
the number of SAT conflicts) that limits the search time. A word of
caution, though: there is no guarantee that runs of different versions of
CVC4 or of different builds of CVC4 (e.g., two CVC4 binaries with different
features enabled, or for different architectures) will interpret the resource
count in the same manner.

CVC4 does not presently have a way to limit its memory use; you may opt
to run it from a shell after using "ulimit" to limit the size of the
heap.

=Dumping API calls or preprocessed output=

=Changing the output language=

=Proof support=

CVC4 1.0 has limited support for proofs, and they are disabled by default.
(Run the configure script with --enable-proof to enable proofs). Proofs
are exported in LFSC format and are limited to the propositional backbone
of the discovered proof (theory lemmas are stated without proof in this
release).

=Portfolio solving=

If enabled at configure-time (./configure --with-portfolio), a second
CVC4 binary will be produced ("pcvc4"). This binary has support for
running multiple instances of CVC4 in different threads. Use --threads=N
to specify the number of threads, and use --thread0="options for thread 0"
--thread1="options for thread 1", etc., to specify a configuration for the
threads. Lemmas are *not* shared between the threads by default; to adjust
this, use the --filter-lemma-length=N option to share lemmas of N literals
(or smaller). (Some lemmas are ineligible for sharing because they include
literals that are "local" to one thread.)

Currently, the portfolio **does not work** with quantifiers or with
the theory of inductive datatypes. These limitations will be addressed
in a future release.

=Emacs support=

For a suggestion of editing CVC4 source code with emacs, see the file
contrib/editing-with-emacs. For a CVC language mode (the native input
language for CVC4), see contrib/cvc-mode.el.

User Manual

2012-11-26T04:30:35Z

Tinelli: /* Arithmetic */

This manual includes lots of information about how to use CVC4.

It is a work in-progress.

= What is CVC4? =

CVC4 is the last of a long line of SMT solvers that started with SVC and includes CVC, CVC-Lite and CVC3.
Technically, it is an automated validity checker for a many-sorted (i.e., typed) first-order logic with built-in theories.
The current built-in theories are the theories of:

* equality over free (aka uninterpreted) function and predicate symbols,
* real and integer linear arithmetic (with some support for non-linear arithmetic),
* bit vectors,
* arrays,
* tuples,
* records,
* user-defined inductive data types.

CVC4 checks whether a given formula <math>\phi</math> is valid in the built-in theories under a given set <math>\Gamma</math> of assumptions, a ''context''.
More precisely, it checks whether

<center>
<math>\Gamma\models_T \phi</math>
</center>

that is, whether <math>\phi</math> is a logical consequence in <math>T</math> of the set of formulas <math>\Gamma</math>, where <math>T</math> is the union of CVC4's built-in theories.

Roughly speaking, when <math>\phi</math> is a universal formula and <math>\Gamma</math> is a set of existential formulas (i.e., when <math>\phi</math> and <math>\Gamma</math> contain at most universal, respectively existential, quantifiers), CVC4 is a decision procedure:
it is guaranteed (modulo bugs and memory limits) to return a correct "valid" or "invalid" answer eventually.
In all other cases, CVC4 is deductively sound but incomplete:
it will never say that an invalid formula is valid,
but it may either never return or give up and return "unknown" for some formulas.

Currently, when CVC4 returns "valid" for a query formula <math>\phi</math> under a context <math>\Gamma</math>
it provides no evidence to back its claim.
Future versions will also return a ''proof certificate'',
a formal proof that <math>\Gamma'\models_T \phi</math> for some subset <math>\Gamma'</math> of <math>\Gamma</math>.

When CVC4 returns "invalid" it can return
both a ''counter-example'' to <math>\phi</math>'s validity under the context <math>\Gamma</math> and a ''counter-model''.
Both a counter-example and a counter-model are a set <math>\Delta</math> of additional formulas consistent with <math>\Gamma</math> in <math>T</math>, but entailing the negation of <math>\phi</math>.
Formally:

<center>
<math>\Gamma \cup \Delta \not\models_T \mathit{false}</math>
and
<math>\Gamma \cup \Delta \models_T \lnot \phi</math>.
</center>

The difference is that a counter-model is given as a set of equations providing a concrete assignment of values for the free symbols in <math>\Gamma</math> and <math>\phi</math>
(see the section on [[#CVC4's native input language|CVC4's native input language]] for more details).

=Obtaining and compiling CVC4=

CVC4 is distributed in the following ways:
* [[#Obtaining_binary_packages|Binary packages]]
* [[#Obtaining_source_packages|Source packages]]
* [[#Source_repository|Source repository checkout]]

==Obtaining binary packages==

[http://cvc4.cs.nyu.edu/builds/ Binary packages are available] for CVC4.
Nightly builds:
* [http://cvc4.cs.nyu.edu/builds/debian/unstable Debian] packages
* [http://cvc4.cs.nyu.edu/builds/x86_64-linux-opt/ Optimized] binaries (statically linked)
* [http://cvc4.cs.nyu.edu/builds/x86_64-linux-dbg/ Debug] binaries (statically linked)

==Obtaining source packages==

[http://cvc4.cs.nyu.edu/builds/src/ Sources are available] from the same site as the binaries.

==Source repository==
The [http://cvc4.cs.nyu.edu/builds/src/ CVC4 source repository] is currently hosted by [http://cims.nyu.edu/ CIMS] and requires a CIMS account. Please contact a member of the development team for access. Please see the additional instructions for [[#Building_CVC4 from_a_repository_checkout]] here.

==Building from source==

===Quick-start instructions===
To compile from a source package:
# Install antlr
# Configure cvc4
# Compile cvc4
# Install cvc4 [optional]
cd contrib
./get-antlr-3.4
cd ..
./configure --with-antlr-dir=`pwd`/antlr-3.4 ANTLR=`pwd`/antlr-3.4/bin/antlr3
make
make check [recommended]
make install [optional]

(To build from a repository checkout, see [[#Building_CVC4_from_a_repository_checkout|below]].)

===Common make Options===
* "''make install''" will install into the "--prefix" option you gave to
the configure script (''/usr/local'' by default).
./configure --prefix=~/install_targets/cvc4 ...
make install
* '''You should run "''make check''"''' before installation to ensure that CVC4 has been
built correctly. In particular, GCC version 4.5.1 seems to have a
bug in the optimizer that results in incorrect behavior (and wrong
results) in many builds. This is a known problem for Minisat, and
since Minisat is at the core of CVC4, a problem for CVC4. "''make check''"
easily detects this problem (by showing a number of FAILed test cases).
It is ok if the unit tests aren't run as part of "''make check''", but all
system tests and regression tests should pass without incident.
* To build API documentation, use "''make doc''". Documentation is produced
under ''builds/doc/'' but is not installed by "''make install''".

Examples and tutorials are not installed with "''make install''." See [[#Examples_and_tutorials_are_not_built_or_installed|below]].

For more information about the build system itself (probably not
necessary for casual users), see the [[#Appendix:_Build_architecture|Appendix]] at the bottom of this
file.

===Common configure Options===
*'''--prefix=PREFIX''' install architecture-independent files in PREFIX (by default /usr/local)
*'''--with-build={production,debug,default,competition}'''
*'''--with-antlr-dir=PATH'''
*'''--with-cln'''/'''--with-gmp''' selects the numbers package to use by default ([[#Optional requirements]])
*'''--enable-static-binary''' build a fully statically-linked binary. (This is recommended for Mac OS X users that want to be able to use gdb.)
*'''ANTLR=PATH''' location of the antlr3 script
*'''--with-boost=DIR''' installation location of the boost libraries (most users will not need this)

See '''./configure --help''' for more.

===Build dependencies===

The following tools and libraries are required to run CVC4. Versions
given are minimum versions; more recent versions should be compatible.

*'''GNU C and C++''' (gcc and g++), reasonably recent versions
*'''GNU Make'''
*'''GNU Bash'''
*'''GMP v4.2''' (GNU Multi-Precision arithmetic library)
*'''libantlr3c v3.2 or v3.4''' (ANTLR parser generator C support library)
*'''The Boost C++ base libraries'''
*'''MacPorts''' [highly recommended if on a Mac; see [[#MacPorts]]]

The hardest to obtain and install is the libantlr3c requirement, and
is explained [[#Installing libantlr3c: ANTLR parser generator C support library|next]].

If "make" is non-GNU on your system, make sure to invoke "gmake" (or
whatever GNU Make is installed as). If your usual shell is not Bash,
the configure script should auto-correct this. If it does not, you'll
see strange shell syntax errors, and you may need to explicitly set
SHELL or CONFIG_SHELL to the location of bash on your system.

====Installing libantlr3c: ANTLR parser generator C support library====

For libantlr3c, you can use the convenience script in
''contrib/get-antlr-3.4'' in the source distribution---this will download, patch, compile and install
libantlr3c into your cvc4 directory as ''cvc4/antlr-3.4/''.
cd contrib
./get-antlr-3.4

CVC4 must be configured with the antlr library installation directory, '''--with-antlr-dir''', and an antlr executable script file, '''ANTLR'''. If libantlr3c was installed via get-antlr-3.4, the following configure line should suffice for CVC44
./configure --with-antlr-dir=`pwd`/antlr-3.4 ANTLR=`pwd`/antlr-3.4/bin/antlr3

For 64 bit machines, libantlr3c needs to be configured with 64 bit explicitly
./configure --enable-64bit ...
The get-antlr-3.4 script makes a guess at whether the machine is 64 bit and adds the appropriate flag.
To force the script to compile 32 bit:
MACHINE_TYPE="x86" ./get-antlr3.4
To force the script to compile 64 bit:
MACHINE_TYPE="x86_64" ./get-antlr3.4

For a longer discussion, instructions for manual installation, and more in depth troubleshooting, see [[Developer's Guide#ANTLR3]].

====MacPorts====

On a Mac, it is '''highly''' recommended that you use MacPorts (see
http://www.macports.org/). Doing so is easy. Then, simply run the
script ''contrib/mac-build'', which installs a few ports from the MacPorts
repository, then compiles and installs antlr3c using the ''get-antlr-3.4''
script. The mac-build script should set you up
with all requirements, and will tell you how to configure CVC4 when it
completes successfully.

====Installing the Boost C++ base libraries====

A Boost package is available on most Linux distributions; check yours
for a package named something like libboost-dev or boost-devel. There
are a number of additional Boost packages in some distributions, but
this "basic" one should be sufficient for building CVC4.

Should you want to install Boost manually, or to learn more about the
Boost project, please visit http://www.boost.org/.

===Optional requirements===

None of these is required, but can improve CVC4 as described below:

*'''Optional: SWIG 2.0.x''' (Simplified Wrapper and Interface Generator)
*'''Optional: CLN v1.3 or newer''' (Class Library for Numbers)
*'''Optional: CUDD v2.4.2 or newer''' (Colorado University Decision Diagram package)
*'''Optional: GNU Readline library''' (for an improved interactive experience)
*'''Optional: The Boost C++ threading library''' (libboost_thread)
*'''Optional: CxxTest unit testing framework'''

SWIG is necessary to build the Java API (and of course a JDK is
necessary, too). SWIG 1.x won't work; you'll need 2.0, and the more
recent the better. On Mac, we've seen SWIG segfault when generating
CVC4 language bindings; version 2.0.8 or higher is recommended to
avoid this. See [[#Language_bindings|Language bindings]] below for build instructions.

CLN is an alternative multiprecision arithmetic package that can offer
better performance and memory footprint than GMP. CLN is covered by
the GNU General Public License, version 3; so if you choose to use
CVC4 with CLN support, you are licensing CVC4 under that same license.
(Usually CVC4's license is more permissive than GPL is; see the file
COPYING in the CVC4 source distribution for details.) Please visit
http://www.ginac.de/CLN/ for more details about CLN.

CUDD is a decision diagram package that changes the behavior of the
CVC4 arithmetic solver in some cases; it may or may not improve the
arithmetic solver's performance. See [[#Building_with_CUDD_(optional)|below]] for instructions on
obtaining and building CUDD.

The GNU Readline library is optionally used to provide command
editing, tab completion, and history functionality at the CVC prompt
(when running in interactive mode). Check your distribution for a
package named "libreadline-dev" or "readline-devel" or similar.

The Boost C++ threading library (often packaged independently of the
Boost base library) is needed to run CVC4 in "portfolio"
(multithreaded) mode. Check your distribution for a package named
"libboost-thread-dev" or similar.

CxxTest is necessary to run CVC4's unit tests (included with the
distribution). Running these is not really required for users of
CVC4; "make check" will skip unit tests if CxxTest isn't available,
and go on to run the extensive system- and regression-tests in the
source tree. However, if you're interested, you can download CxxTest
at http://cxxtest.com/ .

====Building with CUDD (optional)====

CUDD, if desired, must be installed delicately. The CVC4 configure
script attempts to auto-detect the locations and names of CUDD headers
and libraries the way that the Fedora RPMs install them, the way that
our NYU-provided Debian packages install them, and the way they exist
when you download and build the CUDD sources directly. If you install
from Fedora RPMs or our Debian packages, the process should be
completely automatic, since the libraries and headers are installed in
a standard location. If you download the sources yourself, you need
to build them in a special way. Fortunately, the
"contrib/build-cudd-2.4.2-with-libtool.sh" script in the CVC4 source
tree does exactly what you need: it patches the CUDD makefiles to use
libtool, builds the libtool libraries, then reverses the patch to
leave the makefiles as they were. Once you run this script on an
unpacked CUDD 2.4.2 source distribution, then CVC4's configure script
should pick up the libraries if you provide
--with-cudd-dir=/PATH/TO/CUDD/SOURCES.

If you want to force linking to CUDD, provide --with-cudd to the
configure script; this makes it a hard requirement rather than an
optional add-on.

The NYU-provided Debian packaging of CUDD 2.4.2 and CUDD 2.5.0 are
here (along with the CVC4 Debian packages):

deb http://cvc4.cs.nyu.edu/debian/ unstable/

On Debian (and Debian-derived distributions like Ubuntu), you only
need to drop that one line in your /etc/apt/sources.list file, then install with your favorite package manager.

The Debian source package "cudd", available from the same repository,
includes a diff of all changes made to cudd makefiles.

===Language bindings===

There are several options available for using CVC4 from the API.

First, CVC4 offers a complete and flexible API for manipulating
expressions, maintaining a stack of assertions, and checking
satisfiability, and related things. The C++ libraries (libcvc4.so and
libcvc4parser.so) and required headers are installed normally via a
"make install". This API is also available from Java (via CVC4.jar
and libcvc4jni.so) by configuring with --enable-language-bindings=java.
You'll also need SWIG 2.0 installed (and you might need to help
configure find it if you installed it in a nonstandard place with
--with-swig-dir=/path/to/swig/installation). You may also need to
give the configure script the path to your Java headers (in
particular, jni.h). You might do so with (for example):

./configure --enable-language-bindings=java \
JAVA_CPPFLAGS=-I/usr/lib/jvm/java-6-openjdk-amd64/include

There is also a "C++ compatibility API" (''#include <cvc4/cvc3_compat.h>''
and link against libcvc4compat.so) that attempts to maintain
source-level backwards-compatibility with the CVC3 C++ API. The
compatibility library is built by default, and
''--enable-language-bindings=java'' enables the Java compatibility library
(CVC4compat.jar and libcvc4compatjni.so).
''--enable-language-bindings=c'' enables the C compatibility library
(''#include <cvc4/bindings/compat/c/c_interface.h>'' and link against
libcvc4bindings_c_compat.so), and if you want both C and Java
bindings, use ''--enable-language-bindings=c,java''. These compatibility
language bindings do NOT require SWIG.

The ''examples/'' directory in the source distribution includes some basic examples (the "simple vc"
and "simple vc compat" family of examples) of all these interfaces.

In principle, since we use SWIG to generate the native Java API, we
could support other languages as well. However, using CVC4 from other
languages is not supported, nor expected to work, at this time. If
you're interested in helping to develop, maintain, and test a language
binding, please contact us via the users' mailing list at
cvc-users@cs.nyu.edu.

===Building CVC4 from a repository checkout===

The following tools and libraries are additionally required to build
CVC4 from from a repository checkout rather than from a prepared
source tarball.

*'''Automake v1.11'''
*'''Autoconf v2.61'''
*'''Libtool v2.2'''
*'''ANTLR3 v3.2 or v3.4'''
*'''Java Development Kit''' ([http://www.antlr.org/wiki/pages/viewpage.action?pageId=728 required for ANTLR3])

First, use "''./autogen.sh''" to create the configure script. Then
proceed as normal for any distribution tarball. The parsers are
pre-generated for the tarballs, but don't exist in the repository; hence the extra ANTLR3 and JDK requirements to
generate the source code for the parsers, when building from the
repository.

===Examples and tutorials are not built or installed===

Examples are not built by "''make''" or "''make install''". See
''examples/README'' in the source distribution for information on what to find in the ''examples/''
directory, as well as information about building and installing them.

===Appendix: Build architecture===

The build system is generated by automake, libtool, and autoconf. It
is somewhat nonstandard, though, which (for one thing) requires that
GNU Make be used. If you ./configure in the top-level source
directory, the objects will actually all appear in
builds/${arch}/${build_id}. This is to allow multiple, separate
builds in the same place (e.g., an assertions-enabled debugging build
alongside a production build), without changing directories at the
shell. The "current" build is maintained, and you can still use
(e.g.) "make -C src/main" to rebuild objects in just one subdirectory.

You can also create your own build directory inside or outside of the
source tree and configure from there. All objects will then be built
in that directory, and you'll ultimately find the "cvc4" binary in
src/main/, and the libraries under src/ and src/parser/.

=Using the CVC4 binary=

The CVC4 driver binary ("cvc4"), once installed, can be executed directly to enter into interactive mode:

$ cvc4
cvc4 1.0 assertions:off
CVC4>

You can then enter commands into CVC4 interactively:

CVC4> OPTION "incremental";
CVC4> OPTION "produce-models";
CVC4> TRANSFORM 25*25;
625
CVC4> x, y : INT;
CVC4> QUERY x = y;
invalid
CVC4> COUNTERMODEL;
x : INT = -1;
y : INT = 0;
CVC4> ASSERT x >= 0;
CVC4> QUERY x = y;
invalid
CVC4> COUNTERMODEL;
x : INT = 0;
y : INT = 1;
CVC4>

The above example shows two useful options, ''incremental'' and ''produce-models.''

* The ''incremental'' option allows you to issue multiple QUERY (or CHECKSAT) commands, and allows the use of the PUSH and POP commands. Without this option, CVC4 optimizes itself for a single QUERY or CHECKSAT command (though you may issue any number of ASSERT commands). The ''incremental'' option may also be given by passing the ''-i'' command line option to CVC4.
* The ''produce-models'' option allows you to query the model (here, with the COUNTERMODEL command) after an "invalid" QUERY (or "satisfiable" CHECK-SAT). Without it, CVC4 doesn't do the bookkeeping necessary to support model generation. The ''produce-models'' option may also be given by passing the ''-m'' command line option to CVC4.

So, if you invoke CVC4 with ''-im'', you don't need to pass those options at all:

$ cvc4 -im
cvc4 1.0 assertions:off
CVC4> x, y : INT;
CVC4> QUERY x = y;
invalid
CVC4> COUNTERMODEL;
x : INT = -1;
y : INT = 0;
CVC4> ASSERT x >= 0;
CVC4> QUERY x = y;
invalid
CVC4> COUNTERMODEL;
x : INT = 0;
y : INT = 1;
CVC4>

By default, CVC4 operates in [[#CVC4's native input language|CVC-language mode]]. If you enter something that looks like SMT-LIB, it will suggest that you use the "''--lang smt''" command-line option for SMT-LIB mode:

CVC4> (declare-fun x () Int)
Parse Error: <shell>:1.7: In CVC4 presentation language mode, but SMT-LIB format detected. Use --lang smt for SMT-LIB support.
CVC4>

==Verbosity==

CVC4 has various levels of verbosity. By default, CVC4 is pretty quiet, only reporting serious warnings and notices. If you're curious about what it's doing, you can pass CVC4 the ''-v'' option:

$ cvc4 -v file.smt2
Invoking: (set-logic AUFLIRA)
Invoking: (set-info :smt-lib-version 2.000000)
Invoking: (set-info :category "crafted")
Invoking: (set-info :status unsat)
Invoking: (declare-fun x () Real)
''etc...''

For even more verbosity, you can pass CVC4 an ''additional'' ''-v'':

$ cvc4 -vv file.smt2
Invoking: (set-logic AUFLIRA)
Invoking: (set-info :smt-lib-version 2.000000)
Invoking: (set-info :category "crafted")
Invoking: (set-info :status unsat)
Invoking: (declare-fun x () Real)
''etc...''
expanding definitions...
constraining subtypes...
applying substitutions...
simplifying assertions...
doing static learning...
''etc...''

Internally, verbosity is just an integer value. It starts at 0, and with every ''-v'' on the command line it is incremented; with every ''-q'', decremented. It can also be set directly. From CVC language:

CVC4> OPTION "verbosity" 2;

Or from SMT-LIB language:

CVC4> (set-option :verbosity 2)

==Getting statistics==

Statistics can be dumped on exit (both normal and abnormal exits) with the ''--statistics'' command line option.

$ cvc4 --statistics foo.smt2
sat
sat::decisions, 0
sat::propagations, 3
sat::starts, 1
theory::uf::TheoryUF::functionTermsCount, 2
theory::uf::TheoryUF::mergesCount, 2
theory::uf::TheoryUF::termsCount, 6
theory<THEORY_UF>::propagations, 1
driver::filename, foo.smt2
driver::sat/unsat, sat
driver::totalTime, 0.02015373
''[many others]''

Many statistics name-value pairs follow, one comma-separated pair per line.

==Exit status==

The exit status of CVC4 depends on the ''last'' QUERY or CHECK-SAT. If you wish to call CVC4 from a program (e.g., a shell script) and care only about the satisfiability or validity of a single formula, you can pass the ''-q'' option (as described [[#Verbosity|above, under verbosity]]) and check the exit code. With ''-q'', CVC4 should not produce any output unless it encounters a fatal error.

QUERY asks a validity question, and CHECK-SAT a satisfiability question, and these are dual problems; hence the terminology is different, but really "sat" and "invalid" are the same internally, as are "unsat" and "valid":

<table border="1">
<tr><th>Solver's last result</th><th>Exit code</th><th>Notes</th></tr>
<tr><td>'''sat''' or '''invalid'''</td><td>10</td></tr>
<tr><td>'''unsat''' or '''valid'''</td><td>20</td></tr>
<tr><td>'''unknown'''</td><td>0</td><td>could be for any reason: time limit exceeded, no memory, incompleteness..</td></tr>
<tr><td>''no result''</td><td>0</td><td>no query or check-sat command issued</td></tr>
<tr><td>parse errors</td><td>0 (in interactive mode)<br/>1 (otherwise)</td><td>see below</td></tr>
<tr><td>other errors</td><td>1 (usually)</td><td>see below</td></tr>
</table>

Most "normal errors" return a 1 as the exit code, but out of memory conditions, and others, can produce different exit codes. In interactive mode, parse errors are ignored and the next line read; so in interactive mode, you may see an exit code of 0 even in the presence of such an error.

In SMT-LIB mode, an SMT-LIB command script that sets its status via "set-info :status" also affects the exit code. So, for instance, the following SMT-LIB script returns an exit code of 10 even though it contains no "check-sat" command:

(set-logic QF_UF)
(set-info :status sat)
(exit)

Without the "set-info," it would have returned an exit code of 0.

=CVC4's native input language=

The native input language consists of a sequence of symbol declarations and commands, each followed by a semicolon (<code>;</code>).

Any text after the first occurrence of a percent character and to the end of the current line is a comment:

%%% This is a native language comment

== Type System ==

CVC4's type system includes a set of built-in types which can be expanded with additional user-defined types.

The type system consists of ''first-order'' types, ''subtypes'' of first-order types, and ''higher-order'' types, all of which are interpreted as sets.
For convenience, we will sometimes identify below the interpretation of a type with the type itself.

First-order types consist of basic types and structured types. The basic types are <math>\mathrm{BOOLEAN}</math>, <math>\mathrm{REAL}</math>, <math>\mathrm{BITVECTOR}(n)</math> for all <math>n > 0</math>, as well as user-defined basic types (also called uninterpreted types).
The structured types are array, tuple, record types, and ML-style user-defined (inductive) datatypes.

'''Note:''' Currently, subtypes consist only of the built-in subtype <math>\mathrm{INT}</math> of <math>\mathrm{REAL}</math>.

Support for CVC3-style user-defined subtypes will be added in a later release.

Function types are the only higher-order types.
More precisely, they are just second-order types
since function symbols in CVC4, both built-in and user-defined, can take as argument or return only values of
a first-order type.

=== Basic Types ===

==== The BOOLEAN Type ====

The <math>\mathrm{BOOLEAN}</math> type is interpreted as the two-element set of Boolean values
<math>\{\mathrm{TRUE},\; \mathrm{FALSE}\}</math>.

'''Note:''' CVC4's treatment of this type differs from CVC3's where <math>\mathrm{BOOLEAN}</math> is used only as the type of formulas, but not as value type. CVC3 follows the two-tiered structure of classical first-order logic
which distinguishes between formulas and terms, and allows terms to occur in formulas but not vice versa (with the exception of the IF-THEN-ELSE construct).
CVC4 drops the distinction between terms and formulas and defines the latter just as terms of type <math>\mathrm{BOOLEAN}</math>. As such, formulas can occur as subterms of possibly non-Boolean terms.

Example:

[To do]

==== The REAL Type ====

The <math>\mathrm{REAL}</math> type is interpreted as the set of real numbers.

Note that these are the (infinite precision) mathematical reals,
not the floating point numbers.
Support for floating point types is planned for future versions.

x, y : REAL;
QUERY (( x <= y ) AND ( y <= x )) => ( x = y );

==== The INT Type ====

The <math>\mathrm{INT}</math> type is interpreted as the set of integer numbers
and is considered as a subtype of <math>\mathrm{REAL}</math>.
The latter means in particular that it is possible to mix integer and real terms
in expressions without the need of an explicit ''upcasting'' operator.

Note that these are the (infinite precision) mathematical integers,
not the finite precision machine integers used in most programming languages.
The latter are models by [[ #Bitvectors | bit vector ]] types.

x, y : INT;
QUERY ((2 * x + 4 * y <= 1) AND ( y >= x)) => (x <= 0);
z : REAL;
QUERY (2 * x + z <= 3.5) AND (z >= 1);

==== Bit Vector Types ====

For every positive integer <math>n</math>, the type <math>\mathrm{BITVECTOR}(n)</math> is interpreted as the set of all bit vectors of size <math>n</math>.
A rich set of bit vector operators is supported.

==== User-defined Basic Types ====

Users can define new basic types
(often referred to as ''uninterpreted'' types in the SMT literature).
Each such type is interpreted as a set of unspecified cardinality
but disjoint from any other type.

User-defined basic types are created by declarations like the following:

% User declarations of basic types:

MyBrandNewType: TYPE;

Apples, Oranges: TYPE;

=== Structured Types ===

CVC4's structured types are divided in the following families.

==== Array Types ====

Array types are created by the mixfix type constructors <math>\mathrm{ARRAY}\ \_\ \mathrm{OF}\ \_</math>
whose arguments can be instantiated by any value type.

I : TYPE;

%% Array types:

% Arrays with indices from I and values from REAL
Array1: TYPE = ARRAY I OF REAL;

% Arrays with integer indices and array values
Array2: TYPE = ARRAY INT OF (ARRAY INT OF REAL);

% Arrays with integer pair indices and integer values
IntMatrix: TYPE = ARRAY [INT, INT] OF INT;

An array type of the form <math>\mathrm{ARRAY}\ T_1\ \mathrm{OF}\ T_2</math> is interpreted
as the set of all total maps from <math>T_1</math> to <math>T_2</math>.
The main difference with the function type <math>T_1 \to T_2</math> is that arrays,
contrary to functions, are first-class objects of the language, that is, values of an array
type can be arguments or results of functions.
Furthermore, array types come equipped with an update operation.

==== Tuple Types ====

Tuple types are created by the mixfix type constructors

<center>
<math>
\begin{array}{l} [\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ \ ,\ \_\ ] \\[1ex] \ldots \end{array}
</math>
</center>

whose arguments can be instantiated by any value type.

IntArray: TYPE = ARRAY INT OF INT;

% Tuple type declarations

RealPair: TYPE = [REAL, REAL]

MyTuple: TYPE = [ REAL, IntArray, [INT, INT] ];

A tuple type of the form <math>[T_1, \ldots, T_n]</math> is interpreted
as the Cartesian product <math>T_1 \times \cdots \times T_n</math>.

Note that while the types <math>(T_1, \ldots, T_n) \to T</math> and
<math>[T_1 \times \cdots \times T_n] \to T</math> are semantically equivalent,
they are operationally different in CVC4.
The first is the type of functions that take <math>n</math> arguments
of respective type <math>T_1</math>, <math>\ldots</math>, <math>T_n</math>,
while the second is the type of functions that take one argument of an <math>n</math>-tuple type.

==== Record Types ====

Similar to, but more general than tuple types, record types are created by type constructors of the form

<center>
<math>
[\#\ l_1: \_\ ,\ \ldots\ ,\ l_n: \_\ \#]
</math>
</center>

where <math>n > 0</math>, <math>l_1,\ldots, l_n</math> are field labels,
and the arguments can be instantiated with any first-order types.

MyType: TYPE;

% Record declaration

RecordType: TYPE = [# id: REAL, age: INT, info: MyType #];

The order of the fields in a record type is meaningful:
permuting the field names gives a different type.

Note that record types are non-recursive.
For instance, it is not possible to declare a record type called <code>Person</code> containing
a field of type <code>Person</code>.
Recursive types are provided in CVC4 by the more general inductive data types.
(As a matter of fact, both record and tuple types are implemented internally as inductive data types.)

==== Inductive Data Types ====

Inductive data types in CVC4 are similar to inductive data types of functional languages.
They can be parametric or not.

===== Non-Parametric Data Types =====

Non-parametric data types are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1 & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2 & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types, including any <math>A_i</math>.
Such declarations define the data types <math>A_1, \ldots, A_n</math>.
For each data type <math>A_i</math> they introduce:

* constructor symbols <math>cons</math> of type <math>(T_1, \ldots, T_k) \to \mathit{type\_name}_i</math>,
* selector symbols <math>\mathit{sel}_j</math> of type <math>\mathit{type\_name}_i \to T_j</math>, and
* tester symbols <math>\mathit{is\_cons}</math> of type <math>\mathit{type\_name}_i \to \mathrm{BOOLEAN}</math>.

Note that permitting more than one data type to be defined in the same declarations allows
the definition of mutually recursive types.

% simple enumeration type

% implicitly defined are the testers: is_red, is_yellow and is_blue
% (similarly for the other data types)

DATATYPE
PrimaryColor = red | yellow | blue
END;

% infinite set of pairwise distinct values ..., v(-1), v(0), v(1), ...

DATATYPE
Id = v (id: INT)
END;

% ML-style integer lists

DATATYPE
IntList = nil | ins (head: INT, tail: IntList)
END;

% AST for lamba calculus

DATATYPE
Term = var (index: INT)
| apply (arg_1: Term, arg_2: Term)
| lambda (arg: INT, body: Term)
END;

% Trees

DATATYPE
Tree = tree (value: REAL, children: TreeList),
TreeList = nil_tl
| ins_tl (first_t1: Tree, rest_t1: TreeList)
END;

Constructor, selector and tester symbols defined for a data type have global scope.
So, for example, it is not possible for two different data types to use
the same name for a constructor.

An inductive data type is interpreted as a term algebra constructed by the constructor symbols
over some sets of generators.
For example, the type <code>IntList</code> defined above is interpreted as the set
of all terms constructed with <code>nil</code> and <code>ins</code> over the integers.

===== Parametric Data Types =====

Parametric data types are infinite families of (non-parametric) data types
with each family parametrized by one or more type variables.
They are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE}\ [X_1, \ldots, X_p] \\
\begin{array}{ccc}
\ \ A_1 & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2 & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
<math>X_1, \ldots, X_p</math> are type variables,
each <math>A_i</math> is a type name parametrized by some of the variables <math>X_1, \ldots, X_p</math>
and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types,
possibly parametrized by <math>X_1, \ldots, X_p</math>, including any <math>A_i</math>.

% Parametric pairs
DATATYPE [X, Y]
Pair[X, Y] = pair (first: X, second: Y)
END;

% Parametric lists

DATATYPE [X]
List[X] = nil | cons (head: X, tail: List[X])
END;

% Parametric trees using the list type above

DATATYPE [X]
Tree[X] = node (value: X, children: List[Tree[X]]),
END;

The declarations above define infinitely many types of the form
Pair[S,T], List[T] and Tree[T] where S and T are first-order types.
Note that the identifier <code>List</code> above, for example, by itself does not denote a type.
In contrast, the terms <code>List[Real]</code>, <code>List[List[Real]]</code>, <code>List[Tree[INT]]</code>,
and so on do.

===== Restriction to Inductive Types =====

By adopting a term algebra semantics, CVC4 allows only ''inductive'' data types,
that is, data types whose values are essentially (labeled, ordered) finite trees.
Infinite structures such as streams or even finite but cyclic ones
such as circular lists are then excluded.
For instance, none of the following declarations define inductive data types,
and are rejected by CVC4:

DATATYPE
IntStream = s (first:INT, rest: IntStream)
END;

DATATYPE
RationalTree = node1 (child: RationalTree)
| node2 (left_child: RationalTree, right_child:RationalTree)
END;

DATATYPE
T1 = c1 (s1: T2),
T2 = c2 (s2: T1)
END;

In concrete, a declaration of <math>n \geq 1</math> datatypes <math>T_1, \ldots, T_n</math> will be rejected if for any one of the types <math>T_1, \ldots, T_n</math>, it is impossible to build a finite term of that type using only the constructors of <math>T_1, \ldots, T_n</math> and free constants of type other than <math>T_1, \ldots, T_n</math>.

Inductive data types are the only types where the user also chooses names for the built-in operations to:

* construct a value of the type (with the constructors),
* extract components from a value (with the selectors), or
* check if a value was constructed with a certain constructor or not (with the testers).

For all the other types, CVC4 provides predefined names for the built-in operations on the type.

=== Function Types ===

Function (<math>\to</math>) types are created by the mixfix type constructors
<center>
<math>
\begin{array}{l}
\_ \to \_ \\[1ex] (\ \_\ ,\ \_\ ) \to \_
\\[1ex] (\ \_\ ,\ \_\ ,\ \_\ ) \to \_
\\[1ex] \ldots
\end{array}
</math>
</center>
whose arguments can be instantiated by any first-order type.

% Function type declarations

UnaryFunType: TYPE = INT -> REAL;

BinaryFunType: TYPE = (REAL, REAL) -> ARRAY REAL OF REAL;

TernaryFunType: TYPE = (REAL, BITVECTOR(4), INT) -> BOOLEAN;

A function type of the form <math>(T_1, \ldots, T_n) \to T</math> with <math>n > 0</math> is interpreted as the set of all ''total'' functions from the Cartesian product <math>T_1 \times \cdots \times T_n</math> to <math>T</math>.

The example above also shows how to introduce type names.
A name like <code>UnaryFunType</code> above is just an abbreviation for the type <math>\mathrm{INT} \to \mathrm{REAL}</math> and can be used interchangeably with it.

In general, any type defined by a type expression <code>E</code> can be given a name with the declaration:

name : TYPE = E;

=== Type Checking ===

In CVC4, formulas and terms are statically typed at the level of types
(as opposed to subtypes) according to the usual rules of first-order many-sorted logic,
with the main difference that formulas are just terms of type <math>BOOLEAN</math>:

* each variable has one associated first-order type,
* each constant symbol has one or more associated first-order types,
* each function symbol has one or more associated function types,
* the type of a term consisting just of a variable is the type associated to that variable,
* the type of a term consisting just of a constant symbol is the type associated to that constant symbol,
* the term obtained by applying a function symbol <math>f</math> to the terms <math>t_1, \ldots, t_n</math> is <math>T</math> if <math>f</math> has type <math>(T_1, \ldots, T_n) \to T</math> and each <math>t_i</math> has type <math>T_i</math>.

Attempting to enter an ill-typed term will result in an error.

Another significant difference with standard many-sorted logic is that
some built-in symbols are parametrically polymorphic.
For instance, the function symbol for extracting the element of any array has
type <math>(\mathit{ARRAY}\ T_1\ \mathit{OF}\ T_2,\; T_1) \to T_2</math>
for all first-order types <math>T_1, T_2</math>.

==== Type Ascription ====

By the type inference rules above some terms might have more than one type.
This can happen with terms built with polymorphic data type constructors
that have more than one return type for the same input type.
In that case, a type ascription operator (<code>::</code>) must be applied
to the constructor to specify the intended return type.

DATATYPE [X]
List[X] = nil | cons (head: X, tail: List[X])
END;

ASSERT y = cons(1, nil::List[REAL]);

DATATYPE [X, Y]
Union[X, Y] = left(val_l: X) | right(val_r: Y)
END;

ASSERT y = left::Union[BOOLEAN, REAL](TRUE);

The constant symbol <math>\mathrm{nil}</math> declared above has infinitely many types
(<math>\mathrm{List}[\mathrm{REAL}]</math>, <math>\mathrm{List}[\mathrm{BOOLEAN}]</math>,
<math>\mathrm{List}[[\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{List}[\mathrm{List}[\mathrm{REAL}]]</math>, ...)
CVC4's type checker requires the user to indicate explicitly the type
of each occurrence of <code>nil</code> in a term.
Similarly,
the injection operator <code>left</code> has infinitely many return types
for the same input type, for instance:
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{REAL}]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, [\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{List}[\mathrm{REAL}]]</math>,
and so on.
Applications of <code>left</code> need to specify the intended returned typed, as shown above.

== Terms and Formulas ==

In addition to type expressions, CVC4 has expressions for terms and for formulas
(i.e., terms of type <math>\mathrm{BOOLEAN}</math>).
By and large, these are standard first-order terms built out of typed variables,
predefined theory-specific operators, free (i.e., user-defined) function symbols,
and quantifiers.
Extensions include an if-then-else operator, lambda abstractions, and local symbol
declarations, as illustrated below.
Note that these extensions still keep CVC4's language first-order.
In particular, lambda abstractions are restricted to take and return only terms of
a first-order type.
Similarly, variables can only be of a first-order type.

A number of built-in function symbols (for instance, the arithmetic ones) are used
as infix operators. All user-defined symbols are used as prefix ones.

User-defined, i.e., free, function symbols include ''constant symbols'' and
''predicate symbols'', respectively nullary function symbols and function symbols
with a <math>\mathrm{BOOLEAN}</math> return type.
These symbols are introduced with global declarations of the form
<math> f_1, \ldots, f_m: T;</math>
where <math>m > 0</math>, <math>f_i</math> are the names of the symbols and
<math>T</math> is their type:

% integer constants

a, b, c: INT;

% real constants

x, y, z: REAL;

% unary function

f1: REAL -> REAL;

% binary function

f2: (REAL, INT) -> REAL;

% unary function with a tuple argument

f3: [INT, REAL] -> BOOLEAN;

% binary predicate

p: (INT, REAL) -> BOOLEAN;

% Propositional "variables"

P, Q; BOOLEAN;

Like type declarations, function symbol declarations like the above have global scope
and must be unique.
In other words, it is not possible to declare a function symbol globally more than once
in the same lexical scope.
This entails among other things that globally-defined free symbols cannot be overloaded
with different types and that theory symbols cannot be redeclared globally as free symbols.

=== Global symbol definitions ===

As with types, a function symbol can be defined as the name of another term
of the corresponding type.
With constant symbols, this is done with a declaration of the form <math>f:T = t;</math> :

c: INT;

i: INT = 5 + 3*c; % i is effectively a shorthand for 5 + 3*c

j: REAL = 3/4;

t: [REAL, INT] = (2/3, -4);

r: [# key: INT, value: REAL #] = (# key := 4, value := (c + 1)/2 #);

f: BOOLEAN = FORALL (x:INT): x <= 0 OR x > c ;

A restriction on constants of type <math>\mathit{BOOLEAN}</math> is that their value
can only be a closed formula, that is, a formula with no free variables.

A term and its name can be used interchangeably in later expressions.
Named terms are often useful for shared subterms (terms used several times in different places)
since their use can make the input exponentially more concise.
Named terms are processed very efficiently by CVC4.
It is much more efficient to associate a complex term with a name directly rather than
to declare a constant and later assert that it is equal to the same term.
This point is explained in more detail later in section [[Commands | Commands]].

More generally, in CVC4 one can associate a term to function symbols of any arity.
For non-constant function symbols this is done with a declaration of the form

<center>
<math>f:(T_1, \ldots, T_n) \to T = \mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t\;;</math>
</center>

where <math>t</math> is any term of type <math>T</math> with free variables
in <math>\{x_1, \ldots, x_n\}</math>.
The lambda binder has the usual semantics and conforms to the usual lexical scoping rules:
within the term <math>t</math> the declaration of the symbols <math>x_1, \ldots, x_n</math>
as local variables of respective type <math>T_1, \ldots, T_n</math> hides any previous
declarations of those symbols that are in scope.

As a general shorthand, when <math>k</math> consecutive types
<math>T_i, \ldots, T_{i+k-1}</math> in the lambda expression
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t</math> are identical, the syntax
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x_i,\ldots, x_{i+k-1}:T_i,\ldots, x:T_n): t</math>
can also be used.

% Global declaration of x as a unary function symbol

x: REAL -> REAL;

% Local declarations of x as variable (hiding the global one)

f: REAL -> REAL = LAMBDA (x: REAL): 2*x + 3;

p: (INT, INT) -> BOOLEAN = LAMBDA (x,i: INT): i*x - 1 > 0;

g: (REAL, INT) -> [REAL, INT] = LAMBDA (x: REAL, i:INT): (x + 1, i - 3);

Note that lambda definitions are not recursive:
the symbol being defined cannot occur in the body of the lambda term.
They should be understood as macros.
For instance, any occurrence of the term <math>f(t)</math>
where <math>f</math> is as defined above will be treated
as if it was the term <math>(2*t + 3)</math>.

=== Local symbol definitions ===

Constant and function symbols can also be declared locally anywhere within a term
by means of a let binder.
This is done with a declaration of the form

<center>
<math>
\mathrm{LET}\ f = t \ \mathrm{IN}\ t' ;
</math>
</center>

where <math>t</math> is a term with no free variables, possibly a lambda term.
Let binders can be nested arbitrarily and follow the usual lexical scoping rules.
The following general form
<center>
<math>
\mathrm{LET}\ f_1 = t_1, f_2 = t_2, \ldots, f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>
can be use above can used as a shorthand for
<center>
<math>
\mathrm{LET}\ f_1 = t_1\ \mathrm{IN}\
\mathrm{LET}\ f_2 = t_2\ \mathrm{IN}\
\ldots \
\mathrm{LET}\ f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>

t: REAL =
LET x1 = 42,
g = LAMBDA(x:INT): x + 1,
x2 = 2*x1 + 7/2
IN
(LET x3 = g(x1) IN x3 + x2) / x1;

Note that the same symbol = is used, unambiguously, in the syntax of global declarations,
let declarations, and as a predicate symbol.

'''Note:'''
A <math>\mathrm{LET}</math> term with a multiple symbols defines them sequentially.
A parallel version of the <math>\mathrm{LET}</math> construct will be introduced in a later version.

== Built-in theories and their symbols ==

In addition to user-defined symbols, CVC4 terms can use a number of predefined symbols:
the logical symbols, such as <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, etc.,
as well as theory symbols, function symbols belonging to one of the built-in theories.
They are described next, with the theory symbols grouped by theory.

=== Logical Symbols ===

The logical symbols in CVC4's language include
the equality and disequality predicate symbols, respectively written as = and /=,
the multiarity disequality symbol <math>\mathrm{DISTINCT}</math>,
together with the logical constants <math>\mathrm{TRUE}</math>, <math>\mathrm{FALSE}</math>,
the connectives <math>\mathrm{NOT}</math>, <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, <math>\mathrm{XOR}</math>, <math>\Rightarrow</math>, <math>\Leftrightarrow</math>, and
the first-order quantifiers <math>\mathrm{EXISTS}</math> and <math>\mathrm{FORALL}</math>,
all with the standard many-sorted logic semantics.

The binary connectives have infix syntax and type
<math>(\mathrm{BOOLEAN},\mathrm{BOOLEAN}) \to \mathrm{BOOLEAN}</math>.
The symbols = and /=, which are also infix, are instead parametrically polymorphic,
having type <math>(T,T) \to \mathrm{BOOLEAN}</math>
for every first-order type <math>T</math>.
They are interpreted respectively as the identity relation and its complement.

The DISTINCT symbol is both overloaded and polymorphic.
It has type <math>(T,...,T) \to \mathrm{BOOLEAN}</math>
for every sequence <math>(T,...,T)</math> of length <math>n > 0</math>
and first-order type <math>T</math>.
For each <math>n > 0</math>, it is interpreted as the relation
that holds exactly for tuples of pairwise distinct elements.

The syntax for quantifiers is similar to that of the lambda binder.

Here is an example of a formula built just of these logical symbols and variables:

A, B: TYPE;

q: BOOLEAN = FORALL (x,y: A, i,j,k: B):
i = j AND i /= k => EXISTS (z: A): x /= z OR z /= y;

Binding and scoping of quantified variables follows the same rules as
in let expressions.
In particular, a quantifier will shadow in its scope any constant and function symbols
with the same name as one of the variables it quantifies:

A: TYPE;
i, j: INT;

% The first occurrence of i and of j in f are constant symbols,
% the others are variables.

f: BOOLEAN = i = j AND FORALL (i,j: A): i = j OR i /= j;

Optionally, it is also possible to specify instantiation patterns
for quantified variables.
The general syntax for a quantified formula <math>\psi</math> with patterns is

<center>
<math>
Q\;(x_1:T_1, \ldots, x_k:T_k):\; p_1: \ldots\; p_n:\; \varphi
</math>
</center>

where <math>n \geq 0</math>, <math>Q</math> is
either <math>\mathrm{FORALL}</math> or <math>\mathrm{EXISTS}</math>,
<math>\varphi</math> is a term of type <math>\mathrm{BOOLEAN}</math>,
and each of the <math>p_i</math>'s,
a pattern for the quantifier <math>Q\;(x_1:T_1, \ldots, x_k:T_k)</math>, has the form

<center>
<math>
\mathrm{PATTERN}\; (t_1, \ldots, t_m)
</math>
</center>

where <math>m > 0</math> and <math>t_1, \ldots, t_m</math> are
arbitrary binder-free terms (no lets, no quantifiers).
Those terms can contain (free) variables, typically, but not exclusively,
drawn from <math>x_1, \ldots, x_k</math>.
(Additional variables can occur if <math>\psi</math> occurs in a bigger formula
binding those variables.)

A: TYPE;
b, c: A;
p, q: A -> BOOLEAN;
r: (A, A) -> BOOLEAN;

ASSERT FORALL (x0, x1, x2: A):
PATTERN (r(x0, x1), r(x1, x2)):
(r(x0, x1) AND r(x1, x2)) => r(x0, x2) ;

ASSERT FORALL (x: A):
PATTERN (r(x, b)):
PATTERN (r(x, c)):
p(x) => q(x) ;

ASSERT EXISTS (y: A):
FORALL (x: A):
PATTERN (r(x, y), p(y)):
r(x, y) => q(x) ;

Patterns have no logical meaning:
adding them to a formula does not change its semantics.
Their purpose is purely operational, as explained in
the [[#Instantiation Patterns | Instantiation Patterns]] section.

In addition to these constructs, CVC4 also has a general mixfix conditional operator
of the form

<center>
<math>
\mathrm{IF}\ b\ \mathrm{THEN}\ t\ \mathrm{ELSIF}\ b_1\ \mathrm{THEN}\ t_1\ \ldots\ \mathrm{ELSIF}\ b_n\ \mathrm{THEN}\ t_n\ \mathrm{ELSE}\ t_{n+1}\ \mathrm{ENDIF}
</math>
</center>

with <math>n \geq 0</math> where
<math>b, b_1, \ldots, b_n</math> are terms of type <math>\mathrm{BOOLEAN}</math> and
<math>t, t_1, \ldots, t_n, t_{n+1}</math> are terms of the same first-order type <math>T</math>:

% Conditional term
x, y, z, w: REAL;

t: REAL =
IF x > 0 THEN y
ELSIF x >= 1 THEN z
ELSIF x > 2 THEN w
ELSE 2/3 ENDIF;

=== User-defined Functions and Types ===

The theory of user-defined functions,also know in the SMT literature as
the theory ''Equality over Uninterpreted Functions'', or ''EUF'', is in effect
a family of theories of equality parametrized by the basic types and the free symbols
a user can define during a run of CVC4.

This theory has no built-in symbols (other than the logical ones).
Its types consist of ''all and only'' the user-defined types.
Its function symbols consist of ''all and only'' the user-defined free symbols.

=== Arithmetic ===

The real arithmetic theory has two types:
<math>\mathrm{REAL}</math> and <math>\mathrm{INTEGER}</math>
with the latter a subtype of the first.
Its built-in symbols for the usual arithmetic constants
and operators over the type <math>\mathrm{REAL}</math>, each with the expected type:
all numerals 0, 1, ..., as well as - (both unary and binary), +, *, /, <, >, <=, >=.
Application of the binary symbols are in infix form.
Note that + is only binary, and so an expression such as +4 is ill-formed.

Rational values can be expressed in decimal or fractional format:
e.g., 0.1, 23.243241, 1/2, 3/4, and so on.
A leading 0 is mandatory for decimal numbers smaller than one
(e.g., the syntax .3 is cannot be used as a shorthand for 0.3).
However, a trailing 0 is ''not'' required for decimals that are whole numbers
(e.g., 3. is allowed as a shorthand for 3.0).
The size of the numerals used in the representation of natural and rational numbers
is unbounded; more accurately, bounded only by the amount of available memory.

=== Bit vectors ===

=== Arrays ===

The theory of arrays is a parametric theory of (total) unary maps.
It comes equipped with mixfix polymorphic selection and update operators, respectively
<center>
<math>\_[\_]</math> and <math>\_\ \mathrm{WITH}\ [\_]\ := \_</math> .
</center>
The semantics of these operators is the expected one:
for all first-order types <math>T_1</math> and <math>T_2</math>,
if <math>a</math> is of type <math>\mathrm{ARRAY}\ T_1 \mathrm{OF}\ T_2</math>,
<math>i</math> is of type <math>T_1</math>, and
<math>v</math> is of type <math>T_2</math>,
* <math>a[i]</math> denotes the value that <math>a</math> associates to index <math>i</math>,
* <math>a\ \mathrm{WITH}\ [i]\ := v</math> denotes a map that associates <math>v</math> to index <math>i</math> and is otherwise identical to <math>a</math>.
Sequential updates can be chained with the shorthand syntax
<math>\_\ \mathrm{WITH}\ [\_]\ := \_, \ldots, [\_]\ := \_</math>.

A: TYPE = ARRAY INT OF REAL;
a: A;
i: INT = 4;

% selection:

elem: REAL = a[i];

% update

a1: A = a WITH [10] := 1/2;

% sequential update
% (syntactic sugar for (a WITH [10] := 2/3) WITH [42] := 3/2)

a2: A = a WITH [10] := 2/3, [42] := 3/2;

Since arrays are just maps, equality between them is extensional, that is,
for two arrays of the same type to be different they have to map at least one
index to differ values.

=== Data types ===

The theory of inductive data types is in fact a family of theories parametrized
by a data type declaration specifying constructors and selectors
for one or more user-defined data types.

No built-in operators other than equality and disequality are provided
for this family in the native language.
Each user-provided data type declaration, however, generates constructor, selector and tester operators
as described in the [[#Inductive Data Types | Inductive Data Types]] section.

=== Tuples and Records ===

Semantically both records and tuples can be seen as special instances
of inductive data types.
CVC4 implements them internally indeed as data types.
In essence, a record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math>
is encoded as a data type of the form

<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\ \ \mathrm{Record} = \mathit{rec}(l_0:T_0, \ldots, l_n:T_n) \\
\mathrm{END};
\end{array}
</math>
</center>

Tuples of length <math>n</math> are in turn special cases of records whose field names are
the numerals from <math>0</math> to <math>n-1</math>.

Externally, tuples and records have their own syntax for constructor and selector operators.
* Records of type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> have the associated record constructor <math>(\#\ l_0 := \_,\; \ldots,\; l_n := \_\ \#)</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.
* Tuples of type <math>[\ T_0, \ldots, T_n\ ]</math> have the associated tuple constructor <math>(\ \_,\; \ldots,\; \_\ )</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.

The selector operators on records and tuples follows a dot notation syntax.

% Record construction and field selection
Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);
k: INT = x.key;
v: REAL = x.weight;

% Tuple construction and projection
y: [REAL, INT, REAL] = ( 4/5, 9, 11/9 );
first_elem: REAL = y.0;
third_elem: REAL = y.2;

Differently from data types, records and tuples are also provided with built-in update operators similar in syntax and semantics to the update operator for arrays.
More precisely, for each record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .l_i\ := \_
</math>
</center>

The operator maps a record <math>r</math> of that type and a value <math>v</math>
of type <math>T_i</math> to the record that stores <math>v</math> in field <math>l_i</math>
and is otherwise identical to <math>r</math>.
Analogously, for each tuple type <math>[T_0, \ldots, T_n]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .i\ := \_
</math>
</center>

with similar semantics.

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = x WITH .weight := 48;

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = y WITH .1 := 3;

Updates to a nested component can be combined in a single WITH operator:

Cache: TYPE = ARRAY [0..100] OF [# addr: INT, data: REAL #];
State: TYPE = [# pc: INT, cache: Cache #];

s0: State;
s1: State = s0 WITH .cache[10].data := 2/3;

Note that, differently from updates on arrays, tuple and record updates are
just additional syntactic sugar.
For instance, the record <code>x1</code> and tuple <code>y1</code> defined above
could have been equivalently defined as follows:

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = (# key := x.key, weight := 48 #);

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = ( y.0, 3, y.1 );

== Commands ==

In addition to declarations of types and function symbols,
the CVC4 native language contains the following commands:

* <math>\mathrm{ASSERT}\ F</math> -- Add the formula <math>F</math> to the current logical context <math>\Gamma</math>.
* [[#CHECKSAT|<math>\mathrm{CHECKSAT}\ F</math>]] -- Check if the formula <math>F</math> is satisfiable in the current logical context (<math>\Gamma \not\models_T \mathrm{NOT}\ F</math>).
* <math>\mathrm{CONTINUE}</math> -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, search for a counter-example different from the current one.
* [[#COUNTEREXAMPLE|<math>\mathrm{COUNTEREXAMPLE}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print the context that is a witness for invalidity/satisfiability.
* [[#COUNTERMODEL|<math>\mathrm{COUNTERMODEL}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print a model that makes the formula invalid/satisfiable. The model is provided in terms of concrete values for each free symbol.
* <math>\mathrm{OPTION}\ o\ v</math> -- Set the command-line option flag <math>o</math> to value <math>v</math>. The argument <math>o</math> is provide as a string literal enclosed in double-quotes and <math>v</math> as an integer value.
* <math>\mathrm{POP}</math> -- Equivalent to <math>\mathrm{POPTO}\ 1</math>
* [[#POPTO|<math>\mathrm{POPTO}\ n</math>]] -- Restore the system to the state it was in right before the most recent call to <math>\mathrm{PUSH}</math> made from stack level <math>n</math>. Note that the current stack level is printed as part of the output of the <math>\mathrm{WHERE}</math> command.
* <math>\mathrm{PUSH}</math> -- Save (checkpoint) the current state of the system.
* [[#QUERY|<math>\mathrm{QUERY}\ F</math>]] -- Check if the formula <math>F</math> is valid in the current logical context (<math>\Gamma\models_T F</math>).
* [[#RESTART|<math>\mathrm{RESTART}\ F</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, repeat the check but with the additional assumption <math>F</math> in the context.
* <math>\mathrm{PRINT}\ t</math> -- Parse and print back the term <math>t</math>.
* <math>\mathrm{TRANSFORM}\ t</math> -- Simplify the term <math>t</math> and print the result.
* <math>\mathrm{WHERE}</math> -- Print all the formulas in the current logical context <math>\Gamma</math>.

The remaining commands take a single argument, given as a string literal enclosed in double-quotes.

* <math>\mathrm{ECHO}\ s</math> -- Print string <math>s</math>
* <math>\mathrm{INCLUDE}\ f</math> -- Read commands from file <math>f</math>.
* <math>\mathrm{TRACE}\ f</math> -- Turn on tracing for the debug flag <math>f</math>.
* <math>\mathrm{UNTRACE}\ f</math> -- Turn off tracing for the debug flag <math>f</math>.

Here, we explain some of the above commands in more detail.

=== QUERY ===

The command <math>\mathrm{QUERY}\ F</math> invokes the core functionality of CVC4 to check
the validity of the formula <math>F</math> with respect to the assertions made thus far,
which constitute the context <math>\Gamma</math>.
The argument <math>F</math> must be well typed term of type <math>\mathrm{BOOLEAN}</math>,
as described in [[#Terms and Formulas | Terms and Formulas]].

The execution of this command always terminates and produces one of three possible answers:
<code>valid</code>, <code>invalid</code>, and <code>unknown</code>.

* A <code>valid</code> answer indicates that <math>\Gamma \models_T F</math>. After a query returning such an answer, the logical context <math>\Gamma</math> is exactly as it was before the query.
* An <code>invalid</code> answer indicates that <math>\Gamma \not\models_T F</math>, that is, there is a model of the background theory <math>T</math> that satisfies <math>\Gamma \cup \{\mathrm{NOT}\ F\}</math>. When <math>\mathrm{QUERY}\ F</math> returns <code>invalid</code>, the logical context <math>\Gamma</math> is augmented with a set <math>\Delta</math> of ground (i.e., variable-free) literals such that <math>\Gamma\cup\Delta</math> is satisfiable in <math>T</math>, but <math>\Gamma\cup\Delta\models_T \mathrm{NOT}\ F</math>. In fact, in this case <math>\Delta</math> ''propositionally entails'' <math>\mathrm{NOT}\ F</math>, in the sense that, every truth assignment to the literals of <math>\Delta</math> that satisfies <math>\Delta</math> falsifies <math>F</math>. We call the new context <math>\Gamma\cup\Delta</math> a ''counterexample'' for <math>F</math>.
* An <code>unknown</code> answer is similar to an <code>invalid</code> answer in that additional literals are added to the context which propositionally entail <math>\mathrm{NOT}\ F</math>. The difference in this case is that CVC4 cannot guarantee that <math>\Gamma\cup\Delta</math> is actually satisfiable in <math>T</math>.

CVC4 may report <code>unknown</code> when the context or the query contains
non-linear arithmetic terms or quantifiers.
In all other cases, it is expected to be sound and complete,
i.e., to report <code>Valid</code> if <math>\Gamma \models_T F</math>
and <code>Invalid</code> otherwise.

After an <code>invalid</code> (resp. <code>unknown</code>) answer,
counterexamples (resp. possible counterexamples) can be obtained with
a <math>\mathrm{WHERE}</math>, <math>\mathrm{COUNTEREXAMPLE}</math>,
or <math>\mathrm{COUNTERMODEL}</math> command.


Since the <math>\mathrm{QUERY}</math> command may modify
the current context, if one needs to check several formulas in a row
in the same context, it is a good idea to surround every
query by a <math>\mathrm{PUSH}</math> and <math>\mathrm{POP}</math> invocation
in order to preserve the context:

PUSH;
QUERY <formula>;
POP;

=== CHECKSAT ===

The command <math>\mathrm{CHECKSAT}\ F</math> behaves identically
to <math>\mathrm{QUERY}\ \mathrm{NOT}\ F</math>.

=== RESTART ===

The command <math>\mathrm{RESTART}\ F</math> can only be invoked after an invalid query.
For example, in an interactive setting:

QUERY <formula>;

CVC4> invalid

RESTART <formula2>;

Functionally, the behavior of the above command sequence is identical to the following:

PUSH;
QUERY <formula>;
POP;
ASSERT <formula2>;
QUERY <formula>;

The advantage of using the <math>\mathrm{RESTART}</math> command is that
the first command sequence may be executed much more efficiently that the second.
The reason is that with <math>\mathrm{RESTART}</math> CVC4 will re-use
what it has learned while answering the previous query rather than starting
over from scratch.

=== COUNTERMODEL ===

[More]

=== COUNTEREXAMPLE ===

[More]

=== POPTO ===

[More]

== Instantiation Patterns ==

CVC4 processes each universally quantified formula in the current context
by adding instances of the formula obtained by replacing its universal variables
with ground terms.
Patterns restrict the choice of ground terms for the quantified variables,
with the goal of controlling the potential explosion of ground instances.
In essence, adding patterns to a formula is a way for the user to tell CVC4
to focus only on certain instances which, in the user's opinion, will be
most helpful during a proof.

In more detail, patterns have the following effect on formulas that are found
in the logical context or get added to it later while CVC4 is trying to prove
the validity of some formula <math>F</math>.

If a formula in the current context starts with an existential quantifier,
CVC4 ''Skolemizes'' it, that is, replaces it in the context with the formula
obtained by substituting the existentially quantified variables
by fresh constants and dropping the quantifier.
Any patterns for the existential quantifier are simply ignored.

If a formula starts with a universal quantifier
<math>\mathrm{FORALL}\; (x_1:T_1, \ldots, x_n:T_n)</math>,
CVC4 adds to the context a number of instances of the formula,
with the goal of using them to prove the query <math>F</math> valid.
An instance is obtained by replacing each <math>x_i</math> with a ground term
of the same type occurring in one of the formulas in the context,
and dropping the universal quantifier.
If <math>x_i</math> occurs in a pattern
<math>\mathrm{PATTERN}\; (t_1, \ldots, t_m)</math> for the quantifier,
it will be instantiated only with terms obtained by simultaneously matching
all the terms in the pattern against ground terms in the current context
<math>\Gamma</math>.

Specifically, the matching process produces one or more substitutions
<math>\sigma</math> for the variables in <math>(t_1, \ldots, t_m)</math>
which satisfy the following invariant:
for each <math>i = 1, \ldots, m</math>, <math>\sigma(t_i)</math> is
a ground term and there is a ground term <math>s_i</math> in <math>\Gamma</math>
such that <math>\Gamma \models_T \sigma(t_i) = s_i</math>.
The variables of <math>(x_1:T_1, \ldots, x_n:T_n)</math> that occur
in the pattern are instantiated only with those substitutions
(while any remaining variables are instantiated arbitrarily).

The Skolemized version or the added instances of a context formula may themselves
start with a quantifier.
The same instantiation process is applied to them too, recursively.

Note that the matching mechanism is not limited to syntactic matching
but is modulo the equations asserted in the context.
Because of decidability and/or efficiency limitations, the matching process
is not exhaustive.
CVC4 will typically miss some substitutions that satisfy the invariant above.
As a consequence, it might fail to prove the validity of the query formula
<math>F</math>, which makes CVC4 incomplete for contexts containing
quantified formulas.
It should be noted though that exhaustive matching, which can be achieved
simply by not specifying any patterns, does not yield completeness anyway
since the instantiation of universal variables is still restricted
to just the ground terms in the context,
whereas in general additional ground terms might be needed.



=CVC4's support for the SMT-LIB language=

==SMT-LIB compliance==

Every effort has been made to make CVC4 compliant with the SMT-LIB 2.0
standard (http://smtlib.org/). However, when parsing SMT-LIB input,
certain default settings don't match what is stated in the official
standard. To make CVC4 adhere more strictly to the standard, use the
"--smtlib" command-line option. Even with this setting, CVC4 is
somewhat lenient; some non-conforming input may still be parsed and
processed.

=The CVC4 library interface (API)=
==Using CVC4 in a C++ project==
==Using CVC4 from Java==
==The compatibility interface==

=Upgrading from CVC3 to CVC4=

==Features not supported by CVC4 (yet)==

===Type Correctness Conditions (TCCs)===

Type Correctness Conditions (TCCs), and the checking of such, are not
supported by CVC4 1.0. Thus, a function defined only on integers can be
applied to REAL (as INT is a subtype of REAL), and CVC4 will not complain,
but may produce strange results. For example:

f : INT -> INT;
ASSERT f(1/3) = 0;
ASSERT f(2/3) = 1;
CHECKSAT;
% sat
COUNTEREXAMPLE;
% f : (INT) -> INT = LAMBDA(x1:INT) : 0;

CVC3 can be used to produce TCCs for this input (with the +dump-tcc option).
The TCC can be checked by CVC3 or another solver. (CVC3 can also check
TCCs while solving with +tcc.)

==If you were using the text interfaces of CVC3==

The native language of all solvers in the CVC family, referred to as the
"presentation language," has undergone some revisions for CVC4. The
most notable is that CVC4 does _not_ add counterexample assertions to
the current assertion set after a SAT/INVALID result. For example:

x, y : INT;
ASSERT x = 1 OR x = 2;
ASSERT y = 1 OR y = 2;
ASSERT x /= y;
CHECKSAT;
% sat
QUERY x = 1;
% invalid
QUERY x = 2;
% invalid

Here, CVC4 responds "invalid" to the second and third queries, because
each has a counterexample (x=2 is a counterexample to the first, and
x=1 is a counterexample to the second). However, CVC3 will respond
with "valid" to one of these two, as the first query (the CHECKSAT)
had the side-effect of locking CVC3 into one of the two cases; the
later queries are effectively querying the counterexample that was
found by the first. CVC4 removes this side-effect of the CHECKSAT and
QUERY commands.

CVC4 supports rational literals (of type REAL) in decimal; CVC3 did not
support decimals.

CVC4 does not have support for the IS_INTEGER predicate.

==If you were using the library ("in-memory") interface of CVC3==
===If you were using CVC3 from C===
===If you were using CVC3 from Java===

=Useful command-line options=

==Statistics==

Statistics can be dumped on exit (both normal and abnormal exits) with
the --statistics command line option.

==Time and resource limits==

CVC4 can be made to self-timeout after a given number of milliseconds.
Use the --tlimit command line option to limit the entire run of
CVC4, or use --tlimit-per to limit each individual query separately.
Preprocessing time is not counted by the time limit, so for some large
inputs which require aggressive preprocessing, you may notice that
--tlimit does not work very well. If you suspect this might be the
case, you can use "-vv" (double verbosity) to see what CVC4 is doing.

Time-limited runs are not deterministic; two consecutive runs with the
same time limit might produce different results (i.e., one may time out
and responds with "unknown", while the other completes and provides an
answer). To ensure that results are reproducible, use --rlimit or
--rlimit-per. These options take a "resource count" (presently, based on
the number of SAT conflicts) that limits the search time. A word of
caution, though: there is no guarantee that runs of different versions of
CVC4 or of different builds of CVC4 (e.g., two CVC4 binaries with different
features enabled, or for different architectures) will interpret the resource
count in the same manner.

CVC4 does not presently have a way to limit its memory use; you may opt
to run it from a shell after using "ulimit" to limit the size of the
heap.

=Dumping API calls or preprocessed output=

=Changing the output language=

=Proof support=

CVC4 1.0 has limited support for proofs, and they are disabled by default.
(Run the configure script with --enable-proof to enable proofs). Proofs
are exported in LFSC format and are limited to the propositional backbone
of the discovered proof (theory lemmas are stated without proof in this
release).

=Portfolio solving=

If enabled at configure-time (./configure --with-portfolio), a second
CVC4 binary will be produced ("pcvc4"). This binary has support for
running multiple instances of CVC4 in different threads. Use --threads=N
to specify the number of threads, and use --thread0="options for thread 0"
--thread1="options for thread 1", etc., to specify a configuration for the
threads. Lemmas are *not* shared between the threads by default; to adjust
this, use the --filter-lemma-length=N option to share lemmas of N literals
(or smaller). (Some lemmas are ineligible for sharing because they include
literals that are "local" to one thread.)

Currently, the portfolio **does not work** with quantifiers or with
the theory of inductive datatypes. These limitations will be addressed
in a future release.

=Emacs support=

For a suggestion of editing CVC4 source code with emacs, see the file
contrib/editing-with-emacs. For a CVC language mode (the native input
language for CVC4), see contrib/cvc-mode.el.

User Manual

2012-11-26T04:30:12Z

Tinelli: /* Arithmetic */

This manual includes lots of information about how to use CVC4.

It is a work in-progress.

= What is CVC4? =

CVC4 is the last of a long line of SMT solvers that started with SVC and includes CVC, CVC-Lite and CVC3.
Technically, it is an automated validity checker for a many-sorted (i.e., typed) first-order logic with built-in theories.
The current built-in theories are the theories of:

* equality over free (aka uninterpreted) function and predicate symbols,
* real and integer linear arithmetic (with some support for non-linear arithmetic),
* bit vectors,
* arrays,
* tuples,
* records,
* user-defined inductive data types.

CVC4 checks whether a given formula <math>\phi</math> is valid in the built-in theories under a given set <math>\Gamma</math> of assumptions, a ''context''.
More precisely, it checks whether

<center>
<math>\Gamma\models_T \phi</math>
</center>

that is, whether <math>\phi</math> is a logical consequence in <math>T</math> of the set of formulas <math>\Gamma</math>, where <math>T</math> is the union of CVC4's built-in theories.

Roughly speaking, when <math>\phi</math> is a universal formula and <math>\Gamma</math> is a set of existential formulas (i.e., when <math>\phi</math> and <math>\Gamma</math> contain at most universal, respectively existential, quantifiers), CVC4 is a decision procedure:
it is guaranteed (modulo bugs and memory limits) to return a correct "valid" or "invalid" answer eventually.
In all other cases, CVC4 is deductively sound but incomplete:
it will never say that an invalid formula is valid,
but it may either never return or give up and return "unknown" for some formulas.

Currently, when CVC4 returns "valid" for a query formula <math>\phi</math> under a context <math>\Gamma</math>
it provides no evidence to back its claim.
Future versions will also return a ''proof certificate'',
a formal proof that <math>\Gamma'\models_T \phi</math> for some subset <math>\Gamma'</math> of <math>\Gamma</math>.

When CVC4 returns "invalid" it can return
both a ''counter-example'' to <math>\phi</math>'s validity under the context <math>\Gamma</math> and a ''counter-model''.
Both a counter-example and a counter-model are a set <math>\Delta</math> of additional formulas consistent with <math>\Gamma</math> in <math>T</math>, but entailing the negation of <math>\phi</math>.
Formally:

<center>
<math>\Gamma \cup \Delta \not\models_T \mathit{false}</math>
and
<math>\Gamma \cup \Delta \models_T \lnot \phi</math>.
</center>

The difference is that a counter-model is given as a set of equations providing a concrete assignment of values for the free symbols in <math>\Gamma</math> and <math>\phi</math>
(see the section on [[#CVC4's native input language|CVC4's native input language]] for more details).

=Obtaining and compiling CVC4=

CVC4 is distributed in the following ways:
* [[#Obtaining_binary_packages|Binary packages]]
* [[#Obtaining_source_packages|Source packages]]
* [[#Source_repository|Source repository checkout]]

==Obtaining binary packages==

[http://cvc4.cs.nyu.edu/builds/ Binary packages are available] for CVC4.
Nightly builds:
* [http://cvc4.cs.nyu.edu/builds/debian/unstable Debian] packages
* [http://cvc4.cs.nyu.edu/builds/x86_64-linux-opt/ Optimized] binaries (statically linked)
* [http://cvc4.cs.nyu.edu/builds/x86_64-linux-dbg/ Debug] binaries (statically linked)

==Obtaining source packages==

[http://cvc4.cs.nyu.edu/builds/src/ Sources are available] from the same site as the binaries.

==Source repository==
The [http://cvc4.cs.nyu.edu/builds/src/ CVC4 source repository] is currently hosted by [http://cims.nyu.edu/ CIMS] and requires a CIMS account. Please contact a member of the development team for access. Please see the additional instructions for [[#Building_CVC4 from_a_repository_checkout]] here.

==Building from source==

===Quick-start instructions===
To compile from a source package:
# Install antlr
# Configure cvc4
# Compile cvc4
# Install cvc4 [optional]
cd contrib
./get-antlr-3.4
cd ..
./configure --with-antlr-dir=`pwd`/antlr-3.4 ANTLR=`pwd`/antlr-3.4/bin/antlr3
make
make check [recommended]
make install [optional]

(To build from a repository checkout, see [[#Building_CVC4_from_a_repository_checkout|below]].)

===Common make Options===
* "''make install''" will install into the "--prefix" option you gave to
the configure script (''/usr/local'' by default).
./configure --prefix=~/install_targets/cvc4 ...
make install
* '''You should run "''make check''"''' before installation to ensure that CVC4 has been
built correctly. In particular, GCC version 4.5.1 seems to have a
bug in the optimizer that results in incorrect behavior (and wrong
results) in many builds. This is a known problem for Minisat, and
since Minisat is at the core of CVC4, a problem for CVC4. "''make check''"
easily detects this problem (by showing a number of FAILed test cases).
It is ok if the unit tests aren't run as part of "''make check''", but all
system tests and regression tests should pass without incident.
* To build API documentation, use "''make doc''". Documentation is produced
under ''builds/doc/'' but is not installed by "''make install''".

Examples and tutorials are not installed with "''make install''." See [[#Examples_and_tutorials_are_not_built_or_installed|below]].

For more information about the build system itself (probably not
necessary for casual users), see the [[#Appendix:_Build_architecture|Appendix]] at the bottom of this
file.

===Common configure Options===
*'''--prefix=PREFIX''' install architecture-independent files in PREFIX (by default /usr/local)
*'''--with-build={production,debug,default,competition}'''
*'''--with-antlr-dir=PATH'''
*'''--with-cln'''/'''--with-gmp''' selects the numbers package to use by default ([[#Optional requirements]])
*'''--enable-static-binary''' build a fully statically-linked binary. (This is recommended for Mac OS X users that want to be able to use gdb.)
*'''ANTLR=PATH''' location of the antlr3 script
*'''--with-boost=DIR''' installation location of the boost libraries (most users will not need this)

See '''./configure --help''' for more.

===Build dependencies===

The following tools and libraries are required to run CVC4. Versions
given are minimum versions; more recent versions should be compatible.

*'''GNU C and C++''' (gcc and g++), reasonably recent versions
*'''GNU Make'''
*'''GNU Bash'''
*'''GMP v4.2''' (GNU Multi-Precision arithmetic library)
*'''libantlr3c v3.2 or v3.4''' (ANTLR parser generator C support library)
*'''The Boost C++ base libraries'''
*'''MacPorts''' [highly recommended if on a Mac; see [[#MacPorts]]]

The hardest to obtain and install is the libantlr3c requirement, and
is explained [[#Installing libantlr3c: ANTLR parser generator C support library|next]].

If "make" is non-GNU on your system, make sure to invoke "gmake" (or
whatever GNU Make is installed as). If your usual shell is not Bash,
the configure script should auto-correct this. If it does not, you'll
see strange shell syntax errors, and you may need to explicitly set
SHELL or CONFIG_SHELL to the location of bash on your system.

====Installing libantlr3c: ANTLR parser generator C support library====

For libantlr3c, you can use the convenience script in
''contrib/get-antlr-3.4'' in the source distribution---this will download, patch, compile and install
libantlr3c into your cvc4 directory as ''cvc4/antlr-3.4/''.
cd contrib
./get-antlr-3.4

CVC4 must be configured with the antlr library installation directory, '''--with-antlr-dir''', and an antlr executable script file, '''ANTLR'''. If libantlr3c was installed via get-antlr-3.4, the following configure line should suffice for CVC44
./configure --with-antlr-dir=`pwd`/antlr-3.4 ANTLR=`pwd`/antlr-3.4/bin/antlr3

For 64 bit machines, libantlr3c needs to be configured with 64 bit explicitly
./configure --enable-64bit ...
The get-antlr-3.4 script makes a guess at whether the machine is 64 bit and adds the appropriate flag.
To force the script to compile 32 bit:
MACHINE_TYPE="x86" ./get-antlr3.4
To force the script to compile 64 bit:
MACHINE_TYPE="x86_64" ./get-antlr3.4

For a longer discussion, instructions for manual installation, and more in depth troubleshooting, see [[Developer's Guide#ANTLR3]].

====MacPorts====

On a Mac, it is '''highly''' recommended that you use MacPorts (see
http://www.macports.org/). Doing so is easy. Then, simply run the
script ''contrib/mac-build'', which installs a few ports from the MacPorts
repository, then compiles and installs antlr3c using the ''get-antlr-3.4''
script. The mac-build script should set you up
with all requirements, and will tell you how to configure CVC4 when it
completes successfully.

====Installing the Boost C++ base libraries====

A Boost package is available on most Linux distributions; check yours
for a package named something like libboost-dev or boost-devel. There
are a number of additional Boost packages in some distributions, but
this "basic" one should be sufficient for building CVC4.

Should you want to install Boost manually, or to learn more about the
Boost project, please visit http://www.boost.org/.

===Optional requirements===

None of these is required, but can improve CVC4 as described below:

*'''Optional: SWIG 2.0.x''' (Simplified Wrapper and Interface Generator)
*'''Optional: CLN v1.3 or newer''' (Class Library for Numbers)
*'''Optional: CUDD v2.4.2 or newer''' (Colorado University Decision Diagram package)
*'''Optional: GNU Readline library''' (for an improved interactive experience)
*'''Optional: The Boost C++ threading library''' (libboost_thread)
*'''Optional: CxxTest unit testing framework'''

SWIG is necessary to build the Java API (and of course a JDK is
necessary, too). SWIG 1.x won't work; you'll need 2.0, and the more
recent the better. On Mac, we've seen SWIG segfault when generating
CVC4 language bindings; version 2.0.8 or higher is recommended to
avoid this. See [[#Language_bindings|Language bindings]] below for build instructions.

CLN is an alternative multiprecision arithmetic package that can offer
better performance and memory footprint than GMP. CLN is covered by
the GNU General Public License, version 3; so if you choose to use
CVC4 with CLN support, you are licensing CVC4 under that same license.
(Usually CVC4's license is more permissive than GPL is; see the file
COPYING in the CVC4 source distribution for details.) Please visit
http://www.ginac.de/CLN/ for more details about CLN.

CUDD is a decision diagram package that changes the behavior of the
CVC4 arithmetic solver in some cases; it may or may not improve the
arithmetic solver's performance. See [[#Building_with_CUDD_(optional)|below]] for instructions on
obtaining and building CUDD.

The GNU Readline library is optionally used to provide command
editing, tab completion, and history functionality at the CVC prompt
(when running in interactive mode). Check your distribution for a
package named "libreadline-dev" or "readline-devel" or similar.

The Boost C++ threading library (often packaged independently of the
Boost base library) is needed to run CVC4 in "portfolio"
(multithreaded) mode. Check your distribution for a package named
"libboost-thread-dev" or similar.

CxxTest is necessary to run CVC4's unit tests (included with the
distribution). Running these is not really required for users of
CVC4; "make check" will skip unit tests if CxxTest isn't available,
and go on to run the extensive system- and regression-tests in the
source tree. However, if you're interested, you can download CxxTest
at http://cxxtest.com/ .

====Building with CUDD (optional)====

CUDD, if desired, must be installed delicately. The CVC4 configure
script attempts to auto-detect the locations and names of CUDD headers
and libraries the way that the Fedora RPMs install them, the way that
our NYU-provided Debian packages install them, and the way they exist
when you download and build the CUDD sources directly. If you install
from Fedora RPMs or our Debian packages, the process should be
completely automatic, since the libraries and headers are installed in
a standard location. If you download the sources yourself, you need
to build them in a special way. Fortunately, the
"contrib/build-cudd-2.4.2-with-libtool.sh" script in the CVC4 source
tree does exactly what you need: it patches the CUDD makefiles to use
libtool, builds the libtool libraries, then reverses the patch to
leave the makefiles as they were. Once you run this script on an
unpacked CUDD 2.4.2 source distribution, then CVC4's configure script
should pick up the libraries if you provide
--with-cudd-dir=/PATH/TO/CUDD/SOURCES.

If you want to force linking to CUDD, provide --with-cudd to the
configure script; this makes it a hard requirement rather than an
optional add-on.

The NYU-provided Debian packaging of CUDD 2.4.2 and CUDD 2.5.0 are
here (along with the CVC4 Debian packages):

deb http://cvc4.cs.nyu.edu/debian/ unstable/

On Debian (and Debian-derived distributions like Ubuntu), you only
need to drop that one line in your /etc/apt/sources.list file, then install with your favorite package manager.

The Debian source package "cudd", available from the same repository,
includes a diff of all changes made to cudd makefiles.

===Language bindings===

There are several options available for using CVC4 from the API.

First, CVC4 offers a complete and flexible API for manipulating
expressions, maintaining a stack of assertions, and checking
satisfiability, and related things. The C++ libraries (libcvc4.so and
libcvc4parser.so) and required headers are installed normally via a
"make install". This API is also available from Java (via CVC4.jar
and libcvc4jni.so) by configuring with --enable-language-bindings=java.
You'll also need SWIG 2.0 installed (and you might need to help
configure find it if you installed it in a nonstandard place with
--with-swig-dir=/path/to/swig/installation). You may also need to
give the configure script the path to your Java headers (in
particular, jni.h). You might do so with (for example):

./configure --enable-language-bindings=java \
JAVA_CPPFLAGS=-I/usr/lib/jvm/java-6-openjdk-amd64/include

There is also a "C++ compatibility API" (''#include <cvc4/cvc3_compat.h>''
and link against libcvc4compat.so) that attempts to maintain
source-level backwards-compatibility with the CVC3 C++ API. The
compatibility library is built by default, and
''--enable-language-bindings=java'' enables the Java compatibility library
(CVC4compat.jar and libcvc4compatjni.so).
''--enable-language-bindings=c'' enables the C compatibility library
(''#include <cvc4/bindings/compat/c/c_interface.h>'' and link against
libcvc4bindings_c_compat.so), and if you want both C and Java
bindings, use ''--enable-language-bindings=c,java''. These compatibility
language bindings do NOT require SWIG.

The ''examples/'' directory in the source distribution includes some basic examples (the "simple vc"
and "simple vc compat" family of examples) of all these interfaces.

In principle, since we use SWIG to generate the native Java API, we
could support other languages as well. However, using CVC4 from other
languages is not supported, nor expected to work, at this time. If
you're interested in helping to develop, maintain, and test a language
binding, please contact us via the users' mailing list at
cvc-users@cs.nyu.edu.

===Building CVC4 from a repository checkout===

The following tools and libraries are additionally required to build
CVC4 from from a repository checkout rather than from a prepared
source tarball.

*'''Automake v1.11'''
*'''Autoconf v2.61'''
*'''Libtool v2.2'''
*'''ANTLR3 v3.2 or v3.4'''
*'''Java Development Kit''' ([http://www.antlr.org/wiki/pages/viewpage.action?pageId=728 required for ANTLR3])

First, use "''./autogen.sh''" to create the configure script. Then
proceed as normal for any distribution tarball. The parsers are
pre-generated for the tarballs, but don't exist in the repository; hence the extra ANTLR3 and JDK requirements to
generate the source code for the parsers, when building from the
repository.

===Examples and tutorials are not built or installed===

Examples are not built by "''make''" or "''make install''". See
''examples/README'' in the source distribution for information on what to find in the ''examples/''
directory, as well as information about building and installing them.

===Appendix: Build architecture===

The build system is generated by automake, libtool, and autoconf. It
is somewhat nonstandard, though, which (for one thing) requires that
GNU Make be used. If you ./configure in the top-level source
directory, the objects will actually all appear in
builds/${arch}/${build_id}. This is to allow multiple, separate
builds in the same place (e.g., an assertions-enabled debugging build
alongside a production build), without changing directories at the
shell. The "current" build is maintained, and you can still use
(e.g.) "make -C src/main" to rebuild objects in just one subdirectory.

You can also create your own build directory inside or outside of the
source tree and configure from there. All objects will then be built
in that directory, and you'll ultimately find the "cvc4" binary in
src/main/, and the libraries under src/ and src/parser/.

=Using the CVC4 binary=

The CVC4 driver binary ("cvc4"), once installed, can be executed directly to enter into interactive mode:

$ cvc4
cvc4 1.0 assertions:off
CVC4>

You can then enter commands into CVC4 interactively:

CVC4> OPTION "incremental";
CVC4> OPTION "produce-models";
CVC4> TRANSFORM 25*25;
625
CVC4> x, y : INT;
CVC4> QUERY x = y;
invalid
CVC4> COUNTERMODEL;
x : INT = -1;
y : INT = 0;
CVC4> ASSERT x >= 0;
CVC4> QUERY x = y;
invalid
CVC4> COUNTERMODEL;
x : INT = 0;
y : INT = 1;
CVC4>

The above example shows two useful options, ''incremental'' and ''produce-models.''

* The ''incremental'' option allows you to issue multiple QUERY (or CHECKSAT) commands, and allows the use of the PUSH and POP commands. Without this option, CVC4 optimizes itself for a single QUERY or CHECKSAT command (though you may issue any number of ASSERT commands). The ''incremental'' option may also be given by passing the ''-i'' command line option to CVC4.
* The ''produce-models'' option allows you to query the model (here, with the COUNTERMODEL command) after an "invalid" QUERY (or "satisfiable" CHECK-SAT). Without it, CVC4 doesn't do the bookkeeping necessary to support model generation. The ''produce-models'' option may also be given by passing the ''-m'' command line option to CVC4.

So, if you invoke CVC4 with ''-im'', you don't need to pass those options at all:

$ cvc4 -im
cvc4 1.0 assertions:off
CVC4> x, y : INT;
CVC4> QUERY x = y;
invalid
CVC4> COUNTERMODEL;
x : INT = -1;
y : INT = 0;
CVC4> ASSERT x >= 0;
CVC4> QUERY x = y;
invalid
CVC4> COUNTERMODEL;
x : INT = 0;
y : INT = 1;
CVC4>

By default, CVC4 operates in [[#CVC4's native input language|CVC-language mode]]. If you enter something that looks like SMT-LIB, it will suggest that you use the "''--lang smt''" command-line option for SMT-LIB mode:

CVC4> (declare-fun x () Int)
Parse Error: <shell>:1.7: In CVC4 presentation language mode, but SMT-LIB format detected. Use --lang smt for SMT-LIB support.
CVC4>

==Verbosity==

CVC4 has various levels of verbosity. By default, CVC4 is pretty quiet, only reporting serious warnings and notices. If you're curious about what it's doing, you can pass CVC4 the ''-v'' option:

$ cvc4 -v file.smt2
Invoking: (set-logic AUFLIRA)
Invoking: (set-info :smt-lib-version 2.000000)
Invoking: (set-info :category "crafted")
Invoking: (set-info :status unsat)
Invoking: (declare-fun x () Real)
''etc...''

For even more verbosity, you can pass CVC4 an ''additional'' ''-v'':

$ cvc4 -vv file.smt2
Invoking: (set-logic AUFLIRA)
Invoking: (set-info :smt-lib-version 2.000000)
Invoking: (set-info :category "crafted")
Invoking: (set-info :status unsat)
Invoking: (declare-fun x () Real)
''etc...''
expanding definitions...
constraining subtypes...
applying substitutions...
simplifying assertions...
doing static learning...
''etc...''

Internally, verbosity is just an integer value. It starts at 0, and with every ''-v'' on the command line it is incremented; with every ''-q'', decremented. It can also be set directly. From CVC language:

CVC4> OPTION "verbosity" 2;

Or from SMT-LIB language:

CVC4> (set-option :verbosity 2)

==Getting statistics==

Statistics can be dumped on exit (both normal and abnormal exits) with the ''--statistics'' command line option.

$ cvc4 --statistics foo.smt2
sat
sat::decisions, 0
sat::propagations, 3
sat::starts, 1
theory::uf::TheoryUF::functionTermsCount, 2
theory::uf::TheoryUF::mergesCount, 2
theory::uf::TheoryUF::termsCount, 6
theory<THEORY_UF>::propagations, 1
driver::filename, foo.smt2
driver::sat/unsat, sat
driver::totalTime, 0.02015373
''[many others]''

Many statistics name-value pairs follow, one comma-separated pair per line.

==Exit status==

The exit status of CVC4 depends on the ''last'' QUERY or CHECK-SAT. If you wish to call CVC4 from a program (e.g., a shell script) and care only about the satisfiability or validity of a single formula, you can pass the ''-q'' option (as described [[#Verbosity|above, under verbosity]]) and check the exit code. With ''-q'', CVC4 should not produce any output unless it encounters a fatal error.

QUERY asks a validity question, and CHECK-SAT a satisfiability question, and these are dual problems; hence the terminology is different, but really "sat" and "invalid" are the same internally, as are "unsat" and "valid":

<table border="1">
<tr><th>Solver's last result</th><th>Exit code</th><th>Notes</th></tr>
<tr><td>'''sat''' or '''invalid'''</td><td>10</td></tr>
<tr><td>'''unsat''' or '''valid'''</td><td>20</td></tr>
<tr><td>'''unknown'''</td><td>0</td><td>could be for any reason: time limit exceeded, no memory, incompleteness..</td></tr>
<tr><td>''no result''</td><td>0</td><td>no query or check-sat command issued</td></tr>
<tr><td>parse errors</td><td>0 (in interactive mode)<br/>1 (otherwise)</td><td>see below</td></tr>
<tr><td>other errors</td><td>1 (usually)</td><td>see below</td></tr>
</table>

Most "normal errors" return a 1 as the exit code, but out of memory conditions, and others, can produce different exit codes. In interactive mode, parse errors are ignored and the next line read; so in interactive mode, you may see an exit code of 0 even in the presence of such an error.

In SMT-LIB mode, an SMT-LIB command script that sets its status via "set-info :status" also affects the exit code. So, for instance, the following SMT-LIB script returns an exit code of 10 even though it contains no "check-sat" command:

(set-logic QF_UF)
(set-info :status sat)
(exit)

Without the "set-info," it would have returned an exit code of 0.

=CVC4's native input language=

The native input language consists of a sequence of symbol declarations and commands, each followed by a semicolon (<code>;</code>).

Any text after the first occurrence of a percent character and to the end of the current line is a comment:

%%% This is a native language comment

== Type System ==

CVC4's type system includes a set of built-in types which can be expanded with additional user-defined types.

The type system consists of ''first-order'' types, ''subtypes'' of first-order types, and ''higher-order'' types, all of which are interpreted as sets.
For convenience, we will sometimes identify below the interpretation of a type with the type itself.

First-order types consist of basic types and structured types. The basic types are <math>\mathrm{BOOLEAN}</math>, <math>\mathrm{REAL}</math>, <math>\mathrm{BITVECTOR}(n)</math> for all <math>n > 0</math>, as well as user-defined basic types (also called uninterpreted types).
The structured types are array, tuple, record types, and ML-style user-defined (inductive) datatypes.

'''Note:''' Currently, subtypes consist only of the built-in subtype <math>\mathrm{INT}</math> of <math>\mathrm{REAL}</math>.

Support for CVC3-style user-defined subtypes will be added in a later release.

Function types are the only higher-order types.
More precisely, they are just second-order types
since function symbols in CVC4, both built-in and user-defined, can take as argument or return only values of
a first-order type.

=== Basic Types ===

==== The BOOLEAN Type ====

The <math>\mathrm{BOOLEAN}</math> type is interpreted as the two-element set of Boolean values
<math>\{\mathrm{TRUE},\; \mathrm{FALSE}\}</math>.

'''Note:''' CVC4's treatment of this type differs from CVC3's where <math>\mathrm{BOOLEAN}</math> is used only as the type of formulas, but not as value type. CVC3 follows the two-tiered structure of classical first-order logic
which distinguishes between formulas and terms, and allows terms to occur in formulas but not vice versa (with the exception of the IF-THEN-ELSE construct).
CVC4 drops the distinction between terms and formulas and defines the latter just as terms of type <math>\mathrm{BOOLEAN}</math>. As such, formulas can occur as subterms of possibly non-Boolean terms.

Example:

[To do]

==== The REAL Type ====

The <math>\mathrm{REAL}</math> type is interpreted as the set of real numbers.

Note that these are the (infinite precision) mathematical reals,
not the floating point numbers.
Support for floating point types is planned for future versions.

x, y : REAL;
QUERY (( x <= y ) AND ( y <= x )) => ( x = y );

==== The INT Type ====

The <math>\mathrm{INT}</math> type is interpreted as the set of integer numbers
and is considered as a subtype of <math>\mathrm{REAL}</math>.
The latter means in particular that it is possible to mix integer and real terms
in expressions without the need of an explicit ''upcasting'' operator.

Note that these are the (infinite precision) mathematical integers,
not the finite precision machine integers used in most programming languages.
The latter are models by [[ #Bitvectors | bit vector ]] types.

x, y : INT;
QUERY ((2 * x + 4 * y <= 1) AND ( y >= x)) => (x <= 0);
z : REAL;
QUERY (2 * x + z <= 3.5) AND (z >= 1);

==== Bit Vector Types ====

For every positive integer <math>n</math>, the type <math>\mathrm{BITVECTOR}(n)</math> is interpreted as the set of all bit vectors of size <math>n</math>.
A rich set of bit vector operators is supported.

==== User-defined Basic Types ====

Users can define new basic types
(often referred to as ''uninterpreted'' types in the SMT literature).
Each such type is interpreted as a set of unspecified cardinality
but disjoint from any other type.

User-defined basic types are created by declarations like the following:

% User declarations of basic types:

MyBrandNewType: TYPE;

Apples, Oranges: TYPE;

=== Structured Types ===

CVC4's structured types are divided in the following families.

==== Array Types ====

Array types are created by the mixfix type constructors <math>\mathrm{ARRAY}\ \_\ \mathrm{OF}\ \_</math>
whose arguments can be instantiated by any value type.

I : TYPE;

%% Array types:

% Arrays with indices from I and values from REAL
Array1: TYPE = ARRAY I OF REAL;

% Arrays with integer indices and array values
Array2: TYPE = ARRAY INT OF (ARRAY INT OF REAL);

% Arrays with integer pair indices and integer values
IntMatrix: TYPE = ARRAY [INT, INT] OF INT;

An array type of the form <math>\mathrm{ARRAY}\ T_1\ \mathrm{OF}\ T_2</math> is interpreted
as the set of all total maps from <math>T_1</math> to <math>T_2</math>.
The main difference with the function type <math>T_1 \to T_2</math> is that arrays,
contrary to functions, are first-class objects of the language, that is, values of an array
type can be arguments or results of functions.
Furthermore, array types come equipped with an update operation.

==== Tuple Types ====

Tuple types are created by the mixfix type constructors

<center>
<math>
\begin{array}{l} [\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ \ ,\ \_\ ] \\[1ex] \ldots \end{array}
</math>
</center>

whose arguments can be instantiated by any value type.

IntArray: TYPE = ARRAY INT OF INT;

% Tuple type declarations

RealPair: TYPE = [REAL, REAL]

MyTuple: TYPE = [ REAL, IntArray, [INT, INT] ];

A tuple type of the form <math>[T_1, \ldots, T_n]</math> is interpreted
as the Cartesian product <math>T_1 \times \cdots \times T_n</math>.

Note that while the types <math>(T_1, \ldots, T_n) \to T</math> and
<math>[T_1 \times \cdots \times T_n] \to T</math> are semantically equivalent,
they are operationally different in CVC4.
The first is the type of functions that take <math>n</math> arguments
of respective type <math>T_1</math>, <math>\ldots</math>, <math>T_n</math>,
while the second is the type of functions that take one argument of an <math>n</math>-tuple type.

==== Record Types ====

Similar to, but more general than tuple types, record types are created by type constructors of the form

<center>
<math>
[\#\ l_1: \_\ ,\ \ldots\ ,\ l_n: \_\ \#]
</math>
</center>

where <math>n > 0</math>, <math>l_1,\ldots, l_n</math> are field labels,
and the arguments can be instantiated with any first-order types.

MyType: TYPE;

% Record declaration

RecordType: TYPE = [# id: REAL, age: INT, info: MyType #];

The order of the fields in a record type is meaningful:
permuting the field names gives a different type.

Note that record types are non-recursive.
For instance, it is not possible to declare a record type called <code>Person</code> containing
a field of type <code>Person</code>.
Recursive types are provided in CVC4 by the more general inductive data types.
(As a matter of fact, both record and tuple types are implemented internally as inductive data types.)

==== Inductive Data Types ====

Inductive data types in CVC4 are similar to inductive data types of functional languages.
They can be parametric or not.

===== Non-Parametric Data Types =====

Non-parametric data types are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1 & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2 & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types, including any <math>A_i</math>.
Such declarations define the data types <math>A_1, \ldots, A_n</math>.
For each data type <math>A_i</math> they introduce:

* constructor symbols <math>cons</math> of type <math>(T_1, \ldots, T_k) \to \mathit{type\_name}_i</math>,
* selector symbols <math>\mathit{sel}_j</math> of type <math>\mathit{type\_name}_i \to T_j</math>, and
* tester symbols <math>\mathit{is\_cons}</math> of type <math>\mathit{type\_name}_i \to \mathrm{BOOLEAN}</math>.

Note that permitting more than one data type to be defined in the same declarations allows
the definition of mutually recursive types.

% simple enumeration type

% implicitly defined are the testers: is_red, is_yellow and is_blue
% (similarly for the other data types)

DATATYPE
PrimaryColor = red | yellow | blue
END;

% infinite set of pairwise distinct values ..., v(-1), v(0), v(1), ...

DATATYPE
Id = v (id: INT)
END;

% ML-style integer lists

DATATYPE
IntList = nil | ins (head: INT, tail: IntList)
END;

% AST for lamba calculus

DATATYPE
Term = var (index: INT)
| apply (arg_1: Term, arg_2: Term)
| lambda (arg: INT, body: Term)
END;

% Trees

DATATYPE
Tree = tree (value: REAL, children: TreeList),
TreeList = nil_tl
| ins_tl (first_t1: Tree, rest_t1: TreeList)
END;

Constructor, selector and tester symbols defined for a data type have global scope.
So, for example, it is not possible for two different data types to use
the same name for a constructor.

An inductive data type is interpreted as a term algebra constructed by the constructor symbols
over some sets of generators.
For example, the type <code>IntList</code> defined above is interpreted as the set
of all terms constructed with <code>nil</code> and <code>ins</code> over the integers.

===== Parametric Data Types =====

Parametric data types are infinite families of (non-parametric) data types
with each family parametrized by one or more type variables.
They are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE}\ [X_1, \ldots, X_p] \\
\begin{array}{ccc}
\ \ A_1 & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2 & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
<math>X_1, \ldots, X_p</math> are type variables,
each <math>A_i</math> is a type name parametrized by some of the variables <math>X_1, \ldots, X_p</math>
and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types,
possibly parametrized by <math>X_1, \ldots, X_p</math>, including any <math>A_i</math>.

% Parametric pairs
DATATYPE [X, Y]
Pair[X, Y] = pair (first: X, second: Y)
END;

% Parametric lists

DATATYPE [X]
List[X] = nil | cons (head: X, tail: List[X])
END;

% Parametric trees using the list type above

DATATYPE [X]
Tree[X] = node (value: X, children: List[Tree[X]]),
END;

The declarations above define infinitely many types of the form
Pair[S,T], List[T] and Tree[T] where S and T are first-order types.
Note that the identifier <code>List</code> above, for example, by itself does not denote a type.
In contrast, the terms <code>List[Real]</code>, <code>List[List[Real]]</code>, <code>List[Tree[INT]]</code>,
and so on do.

===== Restriction to Inductive Types =====

By adopting a term algebra semantics, CVC4 allows only ''inductive'' data types,
that is, data types whose values are essentially (labeled, ordered) finite trees.
Infinite structures such as streams or even finite but cyclic ones
such as circular lists are then excluded.
For instance, none of the following declarations define inductive data types,
and are rejected by CVC4:

DATATYPE
IntStream = s (first:INT, rest: IntStream)
END;

DATATYPE
RationalTree = node1 (child: RationalTree)
| node2 (left_child: RationalTree, right_child:RationalTree)
END;

DATATYPE
T1 = c1 (s1: T2),
T2 = c2 (s2: T1)
END;

In concrete, a declaration of <math>n \geq 1</math> datatypes <math>T_1, \ldots, T_n</math> will be rejected if for any one of the types <math>T_1, \ldots, T_n</math>, it is impossible to build a finite term of that type using only the constructors of <math>T_1, \ldots, T_n</math> and free constants of type other than <math>T_1, \ldots, T_n</math>.

Inductive data types are the only types where the user also chooses names for the built-in operations to:

* construct a value of the type (with the constructors),
* extract components from a value (with the selectors), or
* check if a value was constructed with a certain constructor or not (with the testers).

For all the other types, CVC4 provides predefined names for the built-in operations on the type.

=== Function Types ===

Function (<math>\to</math>) types are created by the mixfix type constructors
<center>
<math>
\begin{array}{l}
\_ \to \_ \\[1ex] (\ \_\ ,\ \_\ ) \to \_
\\[1ex] (\ \_\ ,\ \_\ ,\ \_\ ) \to \_
\\[1ex] \ldots
\end{array}
</math>
</center>
whose arguments can be instantiated by any first-order type.

% Function type declarations

UnaryFunType: TYPE = INT -> REAL;

BinaryFunType: TYPE = (REAL, REAL) -> ARRAY REAL OF REAL;

TernaryFunType: TYPE = (REAL, BITVECTOR(4), INT) -> BOOLEAN;

A function type of the form <math>(T_1, \ldots, T_n) \to T</math> with <math>n > 0</math> is interpreted as the set of all ''total'' functions from the Cartesian product <math>T_1 \times \cdots \times T_n</math> to <math>T</math>.

The example above also shows how to introduce type names.
A name like <code>UnaryFunType</code> above is just an abbreviation for the type <math>\mathrm{INT} \to \mathrm{REAL}</math> and can be used interchangeably with it.

In general, any type defined by a type expression <code>E</code> can be given a name with the declaration:

name : TYPE = E;

=== Type Checking ===

In CVC4, formulas and terms are statically typed at the level of types
(as opposed to subtypes) according to the usual rules of first-order many-sorted logic,
with the main difference that formulas are just terms of type <math>BOOLEAN</math>:

* each variable has one associated first-order type,
* each constant symbol has one or more associated first-order types,
* each function symbol has one or more associated function types,
* the type of a term consisting just of a variable is the type associated to that variable,
* the type of a term consisting just of a constant symbol is the type associated to that constant symbol,
* the term obtained by applying a function symbol <math>f</math> to the terms <math>t_1, \ldots, t_n</math> is <math>T</math> if <math>f</math> has type <math>(T_1, \ldots, T_n) \to T</math> and each <math>t_i</math> has type <math>T_i</math>.

Attempting to enter an ill-typed term will result in an error.

Another significant difference with standard many-sorted logic is that
some built-in symbols are parametrically polymorphic.
For instance, the function symbol for extracting the element of any array has
type <math>(\mathit{ARRAY}\ T_1\ \mathit{OF}\ T_2,\; T_1) \to T_2</math>
for all first-order types <math>T_1, T_2</math>.

==== Type Ascription ====

By the type inference rules above some terms might have more than one type.
This can happen with terms built with polymorphic data type constructors
that have more than one return type for the same input type.
In that case, a type ascription operator (<code>::</code>) must be applied
to the constructor to specify the intended return type.

DATATYPE [X]
List[X] = nil | cons (head: X, tail: List[X])
END;

ASSERT y = cons(1, nil::List[REAL]);

DATATYPE [X, Y]
Union[X, Y] = left(val_l: X) | right(val_r: Y)
END;

ASSERT y = left::Union[BOOLEAN, REAL](TRUE);

The constant symbol <math>\mathrm{nil}</math> declared above has infinitely many types
(<math>\mathrm{List}[\mathrm{REAL}]</math>, <math>\mathrm{List}[\mathrm{BOOLEAN}]</math>,
<math>\mathrm{List}[[\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{List}[\mathrm{List}[\mathrm{REAL}]]</math>, ...)
CVC4's type checker requires the user to indicate explicitly the type
of each occurrence of <code>nil</code> in a term.
Similarly,
the injection operator <code>left</code> has infinitely many return types
for the same input type, for instance:
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{REAL}]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, [\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{List}[\mathrm{REAL}]]</math>,
and so on.
Applications of <code>left</code> need to specify the intended returned typed, as shown above.

== Terms and Formulas ==

In addition to type expressions, CVC4 has expressions for terms and for formulas
(i.e., terms of type <math>\mathrm{BOOLEAN}</math>).
By and large, these are standard first-order terms built out of typed variables,
predefined theory-specific operators, free (i.e., user-defined) function symbols,
and quantifiers.
Extensions include an if-then-else operator, lambda abstractions, and local symbol
declarations, as illustrated below.
Note that these extensions still keep CVC4's language first-order.
In particular, lambda abstractions are restricted to take and return only terms of
a first-order type.
Similarly, variables can only be of a first-order type.

A number of built-in function symbols (for instance, the arithmetic ones) are used
as infix operators. All user-defined symbols are used as prefix ones.

User-defined, i.e., free, function symbols include ''constant symbols'' and
''predicate symbols'', respectively nullary function symbols and function symbols
with a <math>\mathrm{BOOLEAN}</math> return type.
These symbols are introduced with global declarations of the form
<math> f_1, \ldots, f_m: T;</math>
where <math>m > 0</math>, <math>f_i</math> are the names of the symbols and
<math>T</math> is their type:

% integer constants

a, b, c: INT;

% real constants

x, y, z: REAL;

% unary function

f1: REAL -> REAL;

% binary function

f2: (REAL, INT) -> REAL;

% unary function with a tuple argument

f3: [INT, REAL] -> BOOLEAN;

% binary predicate

p: (INT, REAL) -> BOOLEAN;

% Propositional "variables"

P, Q; BOOLEAN;

Like type declarations, function symbol declarations like the above have global scope
and must be unique.
In other words, it is not possible to declare a function symbol globally more than once
in the same lexical scope.
This entails among other things that globally-defined free symbols cannot be overloaded
with different types and that theory symbols cannot be redeclared globally as free symbols.

=== Global symbol definitions ===

As with types, a function symbol can be defined as the name of another term
of the corresponding type.
With constant symbols, this is done with a declaration of the form <math>f:T = t;</math> :

c: INT;

i: INT = 5 + 3*c; % i is effectively a shorthand for 5 + 3*c

j: REAL = 3/4;

t: [REAL, INT] = (2/3, -4);

r: [# key: INT, value: REAL #] = (# key := 4, value := (c + 1)/2 #);

f: BOOLEAN = FORALL (x:INT): x <= 0 OR x > c ;

A restriction on constants of type <math>\mathit{BOOLEAN}</math> is that their value
can only be a closed formula, that is, a formula with no free variables.

A term and its name can be used interchangeably in later expressions.
Named terms are often useful for shared subterms (terms used several times in different places)
since their use can make the input exponentially more concise.
Named terms are processed very efficiently by CVC4.
It is much more efficient to associate a complex term with a name directly rather than
to declare a constant and later assert that it is equal to the same term.
This point is explained in more detail later in section [[Commands | Commands]].

More generally, in CVC4 one can associate a term to function symbols of any arity.
For non-constant function symbols this is done with a declaration of the form

<center>
<math>f:(T_1, \ldots, T_n) \to T = \mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t\;;</math>
</center>

where <math>t</math> is any term of type <math>T</math> with free variables
in <math>\{x_1, \ldots, x_n\}</math>.
The lambda binder has the usual semantics and conforms to the usual lexical scoping rules:
within the term <math>t</math> the declaration of the symbols <math>x_1, \ldots, x_n</math>
as local variables of respective type <math>T_1, \ldots, T_n</math> hides any previous
declarations of those symbols that are in scope.

As a general shorthand, when <math>k</math> consecutive types
<math>T_i, \ldots, T_{i+k-1}</math> in the lambda expression
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t</math> are identical, the syntax
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x_i,\ldots, x_{i+k-1}:T_i,\ldots, x:T_n): t</math>
can also be used.

% Global declaration of x as a unary function symbol

x: REAL -> REAL;

% Local declarations of x as variable (hiding the global one)

f: REAL -> REAL = LAMBDA (x: REAL): 2*x + 3;

p: (INT, INT) -> BOOLEAN = LAMBDA (x,i: INT): i*x - 1 > 0;

g: (REAL, INT) -> [REAL, INT] = LAMBDA (x: REAL, i:INT): (x + 1, i - 3);

Note that lambda definitions are not recursive:
the symbol being defined cannot occur in the body of the lambda term.
They should be understood as macros.
For instance, any occurrence of the term <math>f(t)</math>
where <math>f</math> is as defined above will be treated
as if it was the term <math>(2*t + 3)</math>.

=== Local symbol definitions ===

Constant and function symbols can also be declared locally anywhere within a term
by means of a let binder.
This is done with a declaration of the form

<center>
<math>
\mathrm{LET}\ f = t \ \mathrm{IN}\ t' ;
</math>
</center>

where <math>t</math> is a term with no free variables, possibly a lambda term.
Let binders can be nested arbitrarily and follow the usual lexical scoping rules.
The following general form
<center>
<math>
\mathrm{LET}\ f_1 = t_1, f_2 = t_2, \ldots, f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>
can be use above can used as a shorthand for
<center>
<math>
\mathrm{LET}\ f_1 = t_1\ \mathrm{IN}\
\mathrm{LET}\ f_2 = t_2\ \mathrm{IN}\
\ldots \
\mathrm{LET}\ f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>

t: REAL =
LET x1 = 42,
g = LAMBDA(x:INT): x + 1,
x2 = 2*x1 + 7/2
IN
(LET x3 = g(x1) IN x3 + x2) / x1;

Note that the same symbol = is used, unambiguously, in the syntax of global declarations,
let declarations, and as a predicate symbol.

'''Note:'''
A <math>\mathrm{LET}</math> term with a multiple symbols defines them sequentially.
A parallel version of the <math>\mathrm{LET}</math> construct will be introduced in a later version.

== Built-in theories and their symbols ==

In addition to user-defined symbols, CVC4 terms can use a number of predefined symbols:
the logical symbols, such as <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, etc.,
as well as theory symbols, function symbols belonging to one of the built-in theories.
They are described next, with the theory symbols grouped by theory.

=== Logical Symbols ===

The logical symbols in CVC4's language include
the equality and disequality predicate symbols, respectively written as = and /=,
the multiarity disequality symbol <math>\mathrm{DISTINCT}</math>,
together with the logical constants <math>\mathrm{TRUE}</math>, <math>\mathrm{FALSE}</math>,
the connectives <math>\mathrm{NOT}</math>, <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, <math>\mathrm{XOR}</math>, <math>\Rightarrow</math>, <math>\Leftrightarrow</math>, and
the first-order quantifiers <math>\mathrm{EXISTS}</math> and <math>\mathrm{FORALL}</math>,
all with the standard many-sorted logic semantics.

The binary connectives have infix syntax and type
<math>(\mathrm{BOOLEAN},\mathrm{BOOLEAN}) \to \mathrm{BOOLEAN}</math>.
The symbols = and /=, which are also infix, are instead parametrically polymorphic,
having type <math>(T,T) \to \mathrm{BOOLEAN}</math>
for every first-order type <math>T</math>.
They are interpreted respectively as the identity relation and its complement.

The DISTINCT symbol is both overloaded and polymorphic.
It has type <math>(T,...,T) \to \mathrm{BOOLEAN}</math>
for every sequence <math>(T,...,T)</math> of length <math>n > 0</math>
and first-order type <math>T</math>.
For each <math>n > 0</math>, it is interpreted as the relation
that holds exactly for tuples of pairwise distinct elements.

The syntax for quantifiers is similar to that of the lambda binder.

Here is an example of a formula built just of these logical symbols and variables:

A, B: TYPE;

q: BOOLEAN = FORALL (x,y: A, i,j,k: B):
i = j AND i /= k => EXISTS (z: A): x /= z OR z /= y;

Binding and scoping of quantified variables follows the same rules as
in let expressions.
In particular, a quantifier will shadow in its scope any constant and function symbols
with the same name as one of the variables it quantifies:

A: TYPE;
i, j: INT;

% The first occurrence of i and of j in f are constant symbols,
% the others are variables.

f: BOOLEAN = i = j AND FORALL (i,j: A): i = j OR i /= j;

Optionally, it is also possible to specify instantiation patterns
for quantified variables.
The general syntax for a quantified formula <math>\psi</math> with patterns is

<center>
<math>
Q\;(x_1:T_1, \ldots, x_k:T_k):\; p_1: \ldots\; p_n:\; \varphi
</math>
</center>

where <math>n \geq 0</math>, <math>Q</math> is
either <math>\mathrm{FORALL}</math> or <math>\mathrm{EXISTS}</math>,
<math>\varphi</math> is a term of type <math>\mathrm{BOOLEAN}</math>,
and each of the <math>p_i</math>'s,
a pattern for the quantifier <math>Q\;(x_1:T_1, \ldots, x_k:T_k)</math>, has the form

<center>
<math>
\mathrm{PATTERN}\; (t_1, \ldots, t_m)
</math>
</center>

where <math>m > 0</math> and <math>t_1, \ldots, t_m</math> are
arbitrary binder-free terms (no lets, no quantifiers).
Those terms can contain (free) variables, typically, but not exclusively,
drawn from <math>x_1, \ldots, x_k</math>.
(Additional variables can occur if <math>\psi</math> occurs in a bigger formula
binding those variables.)

A: TYPE;
b, c: A;
p, q: A -> BOOLEAN;
r: (A, A) -> BOOLEAN;

ASSERT FORALL (x0, x1, x2: A):
PATTERN (r(x0, x1), r(x1, x2)):
(r(x0, x1) AND r(x1, x2)) => r(x0, x2) ;

ASSERT FORALL (x: A):
PATTERN (r(x, b)):
PATTERN (r(x, c)):
p(x) => q(x) ;

ASSERT EXISTS (y: A):
FORALL (x: A):
PATTERN (r(x, y), p(y)):
r(x, y) => q(x) ;

Patterns have no logical meaning:
adding them to a formula does not change its semantics.
Their purpose is purely operational, as explained in
the [[#Instantiation Patterns | Instantiation Patterns]] section.

In addition to these constructs, CVC4 also has a general mixfix conditional operator
of the form

<center>
<math>
\mathrm{IF}\ b\ \mathrm{THEN}\ t\ \mathrm{ELSIF}\ b_1\ \mathrm{THEN}\ t_1\ \ldots\ \mathrm{ELSIF}\ b_n\ \mathrm{THEN}\ t_n\ \mathrm{ELSE}\ t_{n+1}\ \mathrm{ENDIF}
</math>
</center>

with <math>n \geq 0</math> where
<math>b, b_1, \ldots, b_n</math> are terms of type <math>\mathrm{BOOLEAN}</math> and
<math>t, t_1, \ldots, t_n, t_{n+1}</math> are terms of the same first-order type <math>T</math>:

% Conditional term
x, y, z, w: REAL;

t: REAL =
IF x > 0 THEN y
ELSIF x >= 1 THEN z
ELSIF x > 2 THEN w
ELSE 2/3 ENDIF;

=== User-defined Functions and Types ===

The theory of user-defined functions,also know in the SMT literature as
the theory ''Equality over Uninterpreted Functions'', or ''EUF'', is in effect
a family of theories of equality parametrized by the basic types and the free symbols
a user can define during a run of CVC4.

This theory has no built-in symbols (other than the logical ones).
Its types consist of ''all and only'' the user-defined types.
Its function symbols consist of ''all and only'' the user-defined free symbols.

=== Arithmetic ===

The real arithmetic theory has two types:
<math>\mathrm{REAL}</math> and <math>\mathrm{INTEGER}</math>
with the latter a subtype of the first.
Its built-in symbols for the usual arithmetic constants
and operators over the type <math>\mathrm{REAL}</math>, each with the expected type:
all numerals 0, 1, ..., as well as - (both unary and binary), +, *, /, <, >, <=, >=.
Application of the binary symbols are in infix form.
Note that + is only binary, and so a term such as +4 is ill-formed.

Rational values can be expressed in decimal or fractional format:
e.g., 0.1, 23.243241, 1/2, 3/4, and so on.
A leading 0 is mandatory for decimal numbers smaller than one
(e.g., the syntax .3 is cannot be used as a shorthand for 0.3).
However, a trailing 0 is ''not'' required for decimals that are whole numbers
(e.g., 3. is allowed as a shorthand for 3.0).
The size of the numerals used in the representation of natural and rational numbers
is unbounded; more accurately, bounded only by the amount of available memory.

=== Bit vectors ===

=== Arrays ===

The theory of arrays is a parametric theory of (total) unary maps.
It comes equipped with mixfix polymorphic selection and update operators, respectively
<center>
<math>\_[\_]</math> and <math>\_\ \mathrm{WITH}\ [\_]\ := \_</math> .
</center>
The semantics of these operators is the expected one:
for all first-order types <math>T_1</math> and <math>T_2</math>,
if <math>a</math> is of type <math>\mathrm{ARRAY}\ T_1 \mathrm{OF}\ T_2</math>,
<math>i</math> is of type <math>T_1</math>, and
<math>v</math> is of type <math>T_2</math>,
* <math>a[i]</math> denotes the value that <math>a</math> associates to index <math>i</math>,
* <math>a\ \mathrm{WITH}\ [i]\ := v</math> denotes a map that associates <math>v</math> to index <math>i</math> and is otherwise identical to <math>a</math>.
Sequential updates can be chained with the shorthand syntax
<math>\_\ \mathrm{WITH}\ [\_]\ := \_, \ldots, [\_]\ := \_</math>.

A: TYPE = ARRAY INT OF REAL;
a: A;
i: INT = 4;

% selection:

elem: REAL = a[i];

% update

a1: A = a WITH [10] := 1/2;

% sequential update
% (syntactic sugar for (a WITH [10] := 2/3) WITH [42] := 3/2)

a2: A = a WITH [10] := 2/3, [42] := 3/2;

Since arrays are just maps, equality between them is extensional, that is,
for two arrays of the same type to be different they have to map at least one
index to differ values.

=== Data types ===

The theory of inductive data types is in fact a family of theories parametrized
by a data type declaration specifying constructors and selectors
for one or more user-defined data types.

No built-in operators other than equality and disequality are provided
for this family in the native language.
Each user-provided data type declaration, however, generates constructor, selector and tester operators
as described in the [[#Inductive Data Types | Inductive Data Types]] section.

=== Tuples and Records ===

Semantically both records and tuples can be seen as special instances
of inductive data types.
CVC4 implements them internally indeed as data types.
In essence, a record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math>
is encoded as a data type of the form

<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\ \ \mathrm{Record} = \mathit{rec}(l_0:T_0, \ldots, l_n:T_n) \\
\mathrm{END};
\end{array}
</math>
</center>

Tuples of length <math>n</math> are in turn special cases of records whose field names are
the numerals from <math>0</math> to <math>n-1</math>.

Externally, tuples and records have their own syntax for constructor and selector operators.
* Records of type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> have the associated record constructor <math>(\#\ l_0 := \_,\; \ldots,\; l_n := \_\ \#)</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.
* Tuples of type <math>[\ T_0, \ldots, T_n\ ]</math> have the associated tuple constructor <math>(\ \_,\; \ldots,\; \_\ )</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.

The selector operators on records and tuples follows a dot notation syntax.

% Record construction and field selection
Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);
k: INT = x.key;
v: REAL = x.weight;

% Tuple construction and projection
y: [REAL, INT, REAL] = ( 4/5, 9, 11/9 );
first_elem: REAL = y.0;
third_elem: REAL = y.2;

Differently from data types, records and tuples are also provided with built-in update operators similar in syntax and semantics to the update operator for arrays.
More precisely, for each record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .l_i\ := \_
</math>
</center>

The operator maps a record <math>r</math> of that type and a value <math>v</math>
of type <math>T_i</math> to the record that stores <math>v</math> in field <math>l_i</math>
and is otherwise identical to <math>r</math>.
Analogously, for each tuple type <math>[T_0, \ldots, T_n]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .i\ := \_
</math>
</center>

with similar semantics.

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = x WITH .weight := 48;

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = y WITH .1 := 3;

Updates to a nested component can be combined in a single WITH operator:

Cache: TYPE = ARRAY [0..100] OF [# addr: INT, data: REAL #];
State: TYPE = [# pc: INT, cache: Cache #];

s0: State;
s1: State = s0 WITH .cache[10].data := 2/3;

Note that, differently from updates on arrays, tuple and record updates are
just additional syntactic sugar.
For instance, the record <code>x1</code> and tuple <code>y1</code> defined above
could have been equivalently defined as follows:

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = (# key := x.key, weight := 48 #);

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = ( y.0, 3, y.1 );

== Commands ==

In addition to declarations of types and function symbols,
the CVC4 native language contains the following commands:

* <math>\mathrm{ASSERT}\ F</math> -- Add the formula <math>F</math> to the current logical context <math>\Gamma</math>.
* [[#CHECKSAT|<math>\mathrm{CHECKSAT}\ F</math>]] -- Check if the formula <math>F</math> is satisfiable in the current logical context (<math>\Gamma \not\models_T \mathrm{NOT}\ F</math>).
* <math>\mathrm{CONTINUE}</math> -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, search for a counter-example different from the current one.
* [[#COUNTEREXAMPLE|<math>\mathrm{COUNTEREXAMPLE}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print the context that is a witness for invalidity/satisfiability.
* [[#COUNTERMODEL|<math>\mathrm{COUNTERMODEL}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print a model that makes the formula invalid/satisfiable. The model is provided in terms of concrete values for each free symbol.
* <math>\mathrm{OPTION}\ o\ v</math> -- Set the command-line option flag <math>o</math> to value <math>v</math>. The argument <math>o</math> is provide as a string literal enclosed in double-quotes and <math>v</math> as an integer value.
* <math>\mathrm{POP}</math> -- Equivalent to <math>\mathrm{POPTO}\ 1</math>
* [[#POPTO|<math>\mathrm{POPTO}\ n</math>]] -- Restore the system to the state it was in right before the most recent call to <math>\mathrm{PUSH}</math> made from stack level <math>n</math>. Note that the current stack level is printed as part of the output of the <math>\mathrm{WHERE}</math> command.
* <math>\mathrm{PUSH}</math> -- Save (checkpoint) the current state of the system.
* [[#QUERY|<math>\mathrm{QUERY}\ F</math>]] -- Check if the formula <math>F</math> is valid in the current logical context (<math>\Gamma\models_T F</math>).
* [[#RESTART|<math>\mathrm{RESTART}\ F</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, repeat the check but with the additional assumption <math>F</math> in the context.
* <math>\mathrm{PRINT}\ t</math> -- Parse and print back the term <math>t</math>.
* <math>\mathrm{TRANSFORM}\ t</math> -- Simplify the term <math>t</math> and print the result.
* <math>\mathrm{WHERE}</math> -- Print all the formulas in the current logical context <math>\Gamma</math>.

The remaining commands take a single argument, given as a string literal enclosed in double-quotes.

* <math>\mathrm{ECHO}\ s</math> -- Print string <math>s</math>
* <math>\mathrm{INCLUDE}\ f</math> -- Read commands from file <math>f</math>.
* <math>\mathrm{TRACE}\ f</math> -- Turn on tracing for the debug flag <math>f</math>.
* <math>\mathrm{UNTRACE}\ f</math> -- Turn off tracing for the debug flag <math>f</math>.

Here, we explain some of the above commands in more detail.

=== QUERY ===

The command <math>\mathrm{QUERY}\ F</math> invokes the core functionality of CVC4 to check
the validity of the formula <math>F</math> with respect to the assertions made thus far,
which constitute the context <math>\Gamma</math>.
The argument <math>F</math> must be well typed term of type <math>\mathrm{BOOLEAN}</math>,
as described in [[#Terms and Formulas | Terms and Formulas]].

The execution of this command always terminates and produces one of three possible answers:
<code>valid</code>, <code>invalid</code>, and <code>unknown</code>.

* A <code>valid</code> answer indicates that <math>\Gamma \models_T F</math>. After a query returning such an answer, the logical context <math>\Gamma</math> is exactly as it was before the query.
* An <code>invalid</code> answer indicates that <math>\Gamma \not\models_T F</math>, that is, there is a model of the background theory <math>T</math> that satisfies <math>\Gamma \cup \{\mathrm{NOT}\ F\}</math>. When <math>\mathrm{QUERY}\ F</math> returns <code>invalid</code>, the logical context <math>\Gamma</math> is augmented with a set <math>\Delta</math> of ground (i.e., variable-free) literals such that <math>\Gamma\cup\Delta</math> is satisfiable in <math>T</math>, but <math>\Gamma\cup\Delta\models_T \mathrm{NOT}\ F</math>. In fact, in this case <math>\Delta</math> ''propositionally entails'' <math>\mathrm{NOT}\ F</math>, in the sense that, every truth assignment to the literals of <math>\Delta</math> that satisfies <math>\Delta</math> falsifies <math>F</math>. We call the new context <math>\Gamma\cup\Delta</math> a ''counterexample'' for <math>F</math>.
* An <code>unknown</code> answer is similar to an <code>invalid</code> answer in that additional literals are added to the context which propositionally entail <math>\mathrm{NOT}\ F</math>. The difference in this case is that CVC4 cannot guarantee that <math>\Gamma\cup\Delta</math> is actually satisfiable in <math>T</math>.

CVC4 may report <code>unknown</code> when the context or the query contains
non-linear arithmetic terms or quantifiers.
In all other cases, it is expected to be sound and complete,
i.e., to report <code>Valid</code> if <math>\Gamma \models_T F</math>
and <code>Invalid</code> otherwise.

After an <code>invalid</code> (resp. <code>unknown</code>) answer,
counterexamples (resp. possible counterexamples) can be obtained with
a <math>\mathrm{WHERE}</math>, <math>\mathrm{COUNTEREXAMPLE}</math>,
or <math>\mathrm{COUNTERMODEL}</math> command.


Since the <math>\mathrm{QUERY}</math> command may modify
the current context, if one needs to check several formulas in a row
in the same context, it is a good idea to surround every
query by a <math>\mathrm{PUSH}</math> and <math>\mathrm{POP}</math> invocation
in order to preserve the context:

PUSH;
QUERY <formula>;
POP;

=== CHECKSAT ===

The command <math>\mathrm{CHECKSAT}\ F</math> behaves identically
to <math>\mathrm{QUERY}\ \mathrm{NOT}\ F</math>.

=== RESTART ===

The command <math>\mathrm{RESTART}\ F</math> can only be invoked after an invalid query.
For example, in an interactive setting:

QUERY <formula>;

CVC4> invalid

RESTART <formula2>;

Functionally, the behavior of the above command sequence is identical to the following:

PUSH;
QUERY <formula>;
POP;
ASSERT <formula2>;
QUERY <formula>;

The advantage of using the <math>\mathrm{RESTART}</math> command is that
the first command sequence may be executed much more efficiently that the second.
The reason is that with <math>\mathrm{RESTART}</math> CVC4 will re-use
what it has learned while answering the previous query rather than starting
over from scratch.

=== COUNTERMODEL ===

[More]

=== COUNTEREXAMPLE ===

[More]

=== POPTO ===

[More]

== Instantiation Patterns ==

CVC4 processes each universally quantified formula in the current context
by adding instances of the formula obtained by replacing its universal variables
with ground terms.
Patterns restrict the choice of ground terms for the quantified variables,
with the goal of controlling the potential explosion of ground instances.
In essence, adding patterns to a formula is a way for the user to tell CVC4
to focus only on certain instances which, in the user's opinion, will be
most helpful during a proof.

In more detail, patterns have the following effect on formulas that are found
in the logical context or get added to it later while CVC4 is trying to prove
the validity of some formula <math>F</math>.

If a formula in the current context starts with an existential quantifier,
CVC4 ''Skolemizes'' it, that is, replaces it in the context with the formula
obtained by substituting the existentially quantified variables
by fresh constants and dropping the quantifier.
Any patterns for the existential quantifier are simply ignored.

If a formula starts with a universal quantifier
<math>\mathrm{FORALL}\; (x_1:T_1, \ldots, x_n:T_n)</math>,
CVC4 adds to the context a number of instances of the formula,
with the goal of using them to prove the query <math>F</math> valid.
An instance is obtained by replacing each <math>x_i</math> with a ground term
of the same type occurring in one of the formulas in the context,
and dropping the universal quantifier.
If <math>x_i</math> occurs in a pattern
<math>\mathrm{PATTERN}\; (t_1, \ldots, t_m)</math> for the quantifier,
it will be instantiated only with terms obtained by simultaneously matching
all the terms in the pattern against ground terms in the current context
<math>\Gamma</math>.

Specifically, the matching process produces one or more substitutions
<math>\sigma</math> for the variables in <math>(t_1, \ldots, t_m)</math>
which satisfy the following invariant:
for each <math>i = 1, \ldots, m</math>, <math>\sigma(t_i)</math> is
a ground term and there is a ground term <math>s_i</math> in <math>\Gamma</math>
such that <math>\Gamma \models_T \sigma(t_i) = s_i</math>.
The variables of <math>(x_1:T_1, \ldots, x_n:T_n)</math> that occur
in the pattern are instantiated only with those substitutions
(while any remaining variables are instantiated arbitrarily).

The Skolemized version or the added instances of a context formula may themselves
start with a quantifier.
The same instantiation process is applied to them too, recursively.

Note that the matching mechanism is not limited to syntactic matching
but is modulo the equations asserted in the context.
Because of decidability and/or efficiency limitations, the matching process
is not exhaustive.
CVC4 will typically miss some substitutions that satisfy the invariant above.
As a consequence, it might fail to prove the validity of the query formula
<math>F</math>, which makes CVC4 incomplete for contexts containing
quantified formulas.
It should be noted though that exhaustive matching, which can be achieved
simply by not specifying any patterns, does not yield completeness anyway
since the instantiation of universal variables is still restricted
to just the ground terms in the context,
whereas in general additional ground terms might be needed.



=CVC4's support for the SMT-LIB language=

==SMT-LIB compliance==

Every effort has been made to make CVC4 compliant with the SMT-LIB 2.0
standard (http://smtlib.org/). However, when parsing SMT-LIB input,
certain default settings don't match what is stated in the official
standard. To make CVC4 adhere more strictly to the standard, use the
"--smtlib" command-line option. Even with this setting, CVC4 is
somewhat lenient; some non-conforming input may still be parsed and
processed.

=The CVC4 library interface (API)=
==Using CVC4 in a C++ project==
==Using CVC4 from Java==
==The compatibility interface==

=Upgrading from CVC3 to CVC4=

==Features not supported by CVC4 (yet)==

===Type Correctness Conditions (TCCs)===

Type Correctness Conditions (TCCs), and the checking of such, are not
supported by CVC4 1.0. Thus, a function defined only on integers can be
applied to REAL (as INT is a subtype of REAL), and CVC4 will not complain,
but may produce strange results. For example:

f : INT -> INT;
ASSERT f(1/3) = 0;
ASSERT f(2/3) = 1;
CHECKSAT;
% sat
COUNTEREXAMPLE;
% f : (INT) -> INT = LAMBDA(x1:INT) : 0;

CVC3 can be used to produce TCCs for this input (with the +dump-tcc option).
The TCC can be checked by CVC3 or another solver. (CVC3 can also check
TCCs while solving with +tcc.)

==If you were using the text interfaces of CVC3==

The native language of all solvers in the CVC family, referred to as the
"presentation language," has undergone some revisions for CVC4. The
most notable is that CVC4 does _not_ add counterexample assertions to
the current assertion set after a SAT/INVALID result. For example:

x, y : INT;
ASSERT x = 1 OR x = 2;
ASSERT y = 1 OR y = 2;
ASSERT x /= y;
CHECKSAT;
% sat
QUERY x = 1;
% invalid
QUERY x = 2;
% invalid

Here, CVC4 responds "invalid" to the second and third queries, because
each has a counterexample (x=2 is a counterexample to the first, and
x=1 is a counterexample to the second). However, CVC3 will respond
with "valid" to one of these two, as the first query (the CHECKSAT)
had the side-effect of locking CVC3 into one of the two cases; the
later queries are effectively querying the counterexample that was
found by the first. CVC4 removes this side-effect of the CHECKSAT and
QUERY commands.

CVC4 supports rational literals (of type REAL) in decimal; CVC3 did not
support decimals.

CVC4 does not have support for the IS_INTEGER predicate.

==If you were using the library ("in-memory") interface of CVC3==
===If you were using CVC3 from C===
===If you were using CVC3 from Java===

=Useful command-line options=

==Statistics==

Statistics can be dumped on exit (both normal and abnormal exits) with
the --statistics command line option.

==Time and resource limits==

CVC4 can be made to self-timeout after a given number of milliseconds.
Use the --tlimit command line option to limit the entire run of
CVC4, or use --tlimit-per to limit each individual query separately.
Preprocessing time is not counted by the time limit, so for some large
inputs which require aggressive preprocessing, you may notice that
--tlimit does not work very well. If you suspect this might be the
case, you can use "-vv" (double verbosity) to see what CVC4 is doing.

Time-limited runs are not deterministic; two consecutive runs with the
same time limit might produce different results (i.e., one may time out
and responds with "unknown", while the other completes and provides an
answer). To ensure that results are reproducible, use --rlimit or
--rlimit-per. These options take a "resource count" (presently, based on
the number of SAT conflicts) that limits the search time. A word of
caution, though: there is no guarantee that runs of different versions of
CVC4 or of different builds of CVC4 (e.g., two CVC4 binaries with different
features enabled, or for different architectures) will interpret the resource
count in the same manner.

CVC4 does not presently have a way to limit its memory use; you may opt
to run it from a shell after using "ulimit" to limit the size of the
heap.

=Dumping API calls or preprocessed output=

=Changing the output language=

=Proof support=

CVC4 1.0 has limited support for proofs, and they are disabled by default.
(Run the configure script with --enable-proof to enable proofs). Proofs
are exported in LFSC format and are limited to the propositional backbone
of the discovered proof (theory lemmas are stated without proof in this
release).

=Portfolio solving=

If enabled at configure-time (./configure --with-portfolio), a second
CVC4 binary will be produced ("pcvc4"). This binary has support for
running multiple instances of CVC4 in different threads. Use --threads=N
to specify the number of threads, and use --thread0="options for thread 0"
--thread1="options for thread 1", etc., to specify a configuration for the
threads. Lemmas are *not* shared between the threads by default; to adjust
this, use the --filter-lemma-length=N option to share lemmas of N literals
(or smaller). (Some lemmas are ineligible for sharing because they include
literals that are "local" to one thread.)

Currently, the portfolio **does not work** with quantifiers or with
the theory of inductive datatypes. These limitations will be addressed
in a future release.

=Emacs support=

For a suggestion of editing CVC4 source code with emacs, see the file
contrib/editing-with-emacs. For a CVC language mode (the native input
language for CVC4), see contrib/cvc-mode.el.

User Manual

2012-11-26T04:29:50Z

Tinelli: /* Arithmetic */

This manual includes lots of information about how to use CVC4.

It is a work in-progress.

= What is CVC4? =

CVC4 is the last of a long line of SMT solvers that started with SVC and includes CVC, CVC-Lite and CVC3.
Technically, it is an automated validity checker for a many-sorted (i.e., typed) first-order logic with built-in theories.
The current built-in theories are the theories of:

* equality over free (aka uninterpreted) function and predicate symbols,
* real and integer linear arithmetic (with some support for non-linear arithmetic),
* bit vectors,
* arrays,
* tuples,
* records,
* user-defined inductive data types.

CVC4 checks whether a given formula <math>\phi</math> is valid in the built-in theories under a given set <math>\Gamma</math> of assumptions, a ''context''.
More precisely, it checks whether

<center>
<math>\Gamma\models_T \phi</math>
</center>

that is, whether <math>\phi</math> is a logical consequence in <math>T</math> of the set of formulas <math>\Gamma</math>, where <math>T</math> is the union of CVC4's built-in theories.

Roughly speaking, when <math>\phi</math> is a universal formula and <math>\Gamma</math> is a set of existential formulas (i.e., when <math>\phi</math> and <math>\Gamma</math> contain at most universal, respectively existential, quantifiers), CVC4 is a decision procedure:
it is guaranteed (modulo bugs and memory limits) to return a correct "valid" or "invalid" answer eventually.
In all other cases, CVC4 is deductively sound but incomplete:
it will never say that an invalid formula is valid,
but it may either never return or give up and return "unknown" for some formulas.

Currently, when CVC4 returns "valid" for a query formula <math>\phi</math> under a context <math>\Gamma</math>
it provides no evidence to back its claim.
Future versions will also return a ''proof certificate'',
a formal proof that <math>\Gamma'\models_T \phi</math> for some subset <math>\Gamma'</math> of <math>\Gamma</math>.

When CVC4 returns "invalid" it can return
both a ''counter-example'' to <math>\phi</math>'s validity under the context <math>\Gamma</math> and a ''counter-model''.
Both a counter-example and a counter-model are a set <math>\Delta</math> of additional formulas consistent with <math>\Gamma</math> in <math>T</math>, but entailing the negation of <math>\phi</math>.
Formally:

<center>
<math>\Gamma \cup \Delta \not\models_T \mathit{false}</math>
and
<math>\Gamma \cup \Delta \models_T \lnot \phi</math>.
</center>

The difference is that a counter-model is given as a set of equations providing a concrete assignment of values for the free symbols in <math>\Gamma</math> and <math>\phi</math>
(see the section on [[#CVC4's native input language|CVC4's native input language]] for more details).

=Obtaining and compiling CVC4=

CVC4 is distributed in the following ways:
* [[#Obtaining_binary_packages|Binary packages]]
* [[#Obtaining_source_packages|Source packages]]
* [[#Source_repository|Source repository checkout]]

==Obtaining binary packages==

[http://cvc4.cs.nyu.edu/builds/ Binary packages are available] for CVC4.
Nightly builds:
* [http://cvc4.cs.nyu.edu/builds/debian/unstable Debian] packages
* [http://cvc4.cs.nyu.edu/builds/x86_64-linux-opt/ Optimized] binaries (statically linked)
* [http://cvc4.cs.nyu.edu/builds/x86_64-linux-dbg/ Debug] binaries (statically linked)

==Obtaining source packages==

[http://cvc4.cs.nyu.edu/builds/src/ Sources are available] from the same site as the binaries.

==Source repository==
The [http://cvc4.cs.nyu.edu/builds/src/ CVC4 source repository] is currently hosted by [http://cims.nyu.edu/ CIMS] and requires a CIMS account. Please contact a member of the development team for access. Please see the additional instructions for [[#Building_CVC4 from_a_repository_checkout]] here.

==Building from source==

===Quick-start instructions===
To compile from a source package:
# Install antlr
# Configure cvc4
# Compile cvc4
# Install cvc4 [optional]
cd contrib
./get-antlr-3.4
cd ..
./configure --with-antlr-dir=`pwd`/antlr-3.4 ANTLR=`pwd`/antlr-3.4/bin/antlr3
make
make check [recommended]
make install [optional]

(To build from a repository checkout, see [[#Building_CVC4_from_a_repository_checkout|below]].)

===Common make Options===
* "''make install''" will install into the "--prefix" option you gave to
the configure script (''/usr/local'' by default).
./configure --prefix=~/install_targets/cvc4 ...
make install
* '''You should run "''make check''"''' before installation to ensure that CVC4 has been
built correctly. In particular, GCC version 4.5.1 seems to have a
bug in the optimizer that results in incorrect behavior (and wrong
results) in many builds. This is a known problem for Minisat, and
since Minisat is at the core of CVC4, a problem for CVC4. "''make check''"
easily detects this problem (by showing a number of FAILed test cases).
It is ok if the unit tests aren't run as part of "''make check''", but all
system tests and regression tests should pass without incident.
* To build API documentation, use "''make doc''". Documentation is produced
under ''builds/doc/'' but is not installed by "''make install''".

Examples and tutorials are not installed with "''make install''." See [[#Examples_and_tutorials_are_not_built_or_installed|below]].

For more information about the build system itself (probably not
necessary for casual users), see the [[#Appendix:_Build_architecture|Appendix]] at the bottom of this
file.

===Common configure Options===
*'''--prefix=PREFIX''' install architecture-independent files in PREFIX (by default /usr/local)
*'''--with-build={production,debug,default,competition}'''
*'''--with-antlr-dir=PATH'''
*'''--with-cln'''/'''--with-gmp''' selects the numbers package to use by default ([[#Optional requirements]])
*'''--enable-static-binary''' build a fully statically-linked binary. (This is recommended for Mac OS X users that want to be able to use gdb.)
*'''ANTLR=PATH''' location of the antlr3 script
*'''--with-boost=DIR''' installation location of the boost libraries (most users will not need this)

See '''./configure --help''' for more.

===Build dependencies===

The following tools and libraries are required to run CVC4. Versions
given are minimum versions; more recent versions should be compatible.

*'''GNU C and C++''' (gcc and g++), reasonably recent versions
*'''GNU Make'''
*'''GNU Bash'''
*'''GMP v4.2''' (GNU Multi-Precision arithmetic library)
*'''libantlr3c v3.2 or v3.4''' (ANTLR parser generator C support library)
*'''The Boost C++ base libraries'''
*'''MacPorts''' [highly recommended if on a Mac; see [[#MacPorts]]]

The hardest to obtain and install is the libantlr3c requirement, and
is explained [[#Installing libantlr3c: ANTLR parser generator C support library|next]].

If "make" is non-GNU on your system, make sure to invoke "gmake" (or
whatever GNU Make is installed as). If your usual shell is not Bash,
the configure script should auto-correct this. If it does not, you'll
see strange shell syntax errors, and you may need to explicitly set
SHELL or CONFIG_SHELL to the location of bash on your system.

====Installing libantlr3c: ANTLR parser generator C support library====

For libantlr3c, you can use the convenience script in
''contrib/get-antlr-3.4'' in the source distribution---this will download, patch, compile and install
libantlr3c into your cvc4 directory as ''cvc4/antlr-3.4/''.
cd contrib
./get-antlr-3.4

CVC4 must be configured with the antlr library installation directory, '''--with-antlr-dir''', and an antlr executable script file, '''ANTLR'''. If libantlr3c was installed via get-antlr-3.4, the following configure line should suffice for CVC44
./configure --with-antlr-dir=`pwd`/antlr-3.4 ANTLR=`pwd`/antlr-3.4/bin/antlr3

For 64 bit machines, libantlr3c needs to be configured with 64 bit explicitly
./configure --enable-64bit ...
The get-antlr-3.4 script makes a guess at whether the machine is 64 bit and adds the appropriate flag.
To force the script to compile 32 bit:
MACHINE_TYPE="x86" ./get-antlr3.4
To force the script to compile 64 bit:
MACHINE_TYPE="x86_64" ./get-antlr3.4

For a longer discussion, instructions for manual installation, and more in depth troubleshooting, see [[Developer's Guide#ANTLR3]].

====MacPorts====

On a Mac, it is '''highly''' recommended that you use MacPorts (see
http://www.macports.org/). Doing so is easy. Then, simply run the
script ''contrib/mac-build'', which installs a few ports from the MacPorts
repository, then compiles and installs antlr3c using the ''get-antlr-3.4''
script. The mac-build script should set you up
with all requirements, and will tell you how to configure CVC4 when it
completes successfully.

====Installing the Boost C++ base libraries====

A Boost package is available on most Linux distributions; check yours
for a package named something like libboost-dev or boost-devel. There
are a number of additional Boost packages in some distributions, but
this "basic" one should be sufficient for building CVC4.

Should you want to install Boost manually, or to learn more about the
Boost project, please visit http://www.boost.org/.

===Optional requirements===

None of these is required, but can improve CVC4 as described below:

*'''Optional: SWIG 2.0.x''' (Simplified Wrapper and Interface Generator)
*'''Optional: CLN v1.3 or newer''' (Class Library for Numbers)
*'''Optional: CUDD v2.4.2 or newer''' (Colorado University Decision Diagram package)
*'''Optional: GNU Readline library''' (for an improved interactive experience)
*'''Optional: The Boost C++ threading library''' (libboost_thread)
*'''Optional: CxxTest unit testing framework'''

SWIG is necessary to build the Java API (and of course a JDK is
necessary, too). SWIG 1.x won't work; you'll need 2.0, and the more
recent the better. On Mac, we've seen SWIG segfault when generating
CVC4 language bindings; version 2.0.8 or higher is recommended to
avoid this. See [[#Language_bindings|Language bindings]] below for build instructions.

CLN is an alternative multiprecision arithmetic package that can offer
better performance and memory footprint than GMP. CLN is covered by
the GNU General Public License, version 3; so if you choose to use
CVC4 with CLN support, you are licensing CVC4 under that same license.
(Usually CVC4's license is more permissive than GPL is; see the file
COPYING in the CVC4 source distribution for details.) Please visit
http://www.ginac.de/CLN/ for more details about CLN.

CUDD is a decision diagram package that changes the behavior of the
CVC4 arithmetic solver in some cases; it may or may not improve the
arithmetic solver's performance. See [[#Building_with_CUDD_(optional)|below]] for instructions on
obtaining and building CUDD.

The GNU Readline library is optionally used to provide command
editing, tab completion, and history functionality at the CVC prompt
(when running in interactive mode). Check your distribution for a
package named "libreadline-dev" or "readline-devel" or similar.

The Boost C++ threading library (often packaged independently of the
Boost base library) is needed to run CVC4 in "portfolio"
(multithreaded) mode. Check your distribution for a package named
"libboost-thread-dev" or similar.

CxxTest is necessary to run CVC4's unit tests (included with the
distribution). Running these is not really required for users of
CVC4; "make check" will skip unit tests if CxxTest isn't available,
and go on to run the extensive system- and regression-tests in the
source tree. However, if you're interested, you can download CxxTest
at http://cxxtest.com/ .

====Building with CUDD (optional)====

CUDD, if desired, must be installed delicately. The CVC4 configure
script attempts to auto-detect the locations and names of CUDD headers
and libraries the way that the Fedora RPMs install them, the way that
our NYU-provided Debian packages install them, and the way they exist
when you download and build the CUDD sources directly. If you install
from Fedora RPMs or our Debian packages, the process should be
completely automatic, since the libraries and headers are installed in
a standard location. If you download the sources yourself, you need
to build them in a special way. Fortunately, the
"contrib/build-cudd-2.4.2-with-libtool.sh" script in the CVC4 source
tree does exactly what you need: it patches the CUDD makefiles to use
libtool, builds the libtool libraries, then reverses the patch to
leave the makefiles as they were. Once you run this script on an
unpacked CUDD 2.4.2 source distribution, then CVC4's configure script
should pick up the libraries if you provide
--with-cudd-dir=/PATH/TO/CUDD/SOURCES.

If you want to force linking to CUDD, provide --with-cudd to the
configure script; this makes it a hard requirement rather than an
optional add-on.

The NYU-provided Debian packaging of CUDD 2.4.2 and CUDD 2.5.0 are
here (along with the CVC4 Debian packages):

deb http://cvc4.cs.nyu.edu/debian/ unstable/

On Debian (and Debian-derived distributions like Ubuntu), you only
need to drop that one line in your /etc/apt/sources.list file, then install with your favorite package manager.

The Debian source package "cudd", available from the same repository,
includes a diff of all changes made to cudd makefiles.

===Language bindings===

There are several options available for using CVC4 from the API.

First, CVC4 offers a complete and flexible API for manipulating
expressions, maintaining a stack of assertions, and checking
satisfiability, and related things. The C++ libraries (libcvc4.so and
libcvc4parser.so) and required headers are installed normally via a
"make install". This API is also available from Java (via CVC4.jar
and libcvc4jni.so) by configuring with --enable-language-bindings=java.
You'll also need SWIG 2.0 installed (and you might need to help
configure find it if you installed it in a nonstandard place with
--with-swig-dir=/path/to/swig/installation). You may also need to
give the configure script the path to your Java headers (in
particular, jni.h). You might do so with (for example):

./configure --enable-language-bindings=java \
JAVA_CPPFLAGS=-I/usr/lib/jvm/java-6-openjdk-amd64/include

There is also a "C++ compatibility API" (''#include <cvc4/cvc3_compat.h>''
and link against libcvc4compat.so) that attempts to maintain
source-level backwards-compatibility with the CVC3 C++ API. The
compatibility library is built by default, and
''--enable-language-bindings=java'' enables the Java compatibility library
(CVC4compat.jar and libcvc4compatjni.so).
''--enable-language-bindings=c'' enables the C compatibility library
(''#include <cvc4/bindings/compat/c/c_interface.h>'' and link against
libcvc4bindings_c_compat.so), and if you want both C and Java
bindings, use ''--enable-language-bindings=c,java''. These compatibility
language bindings do NOT require SWIG.

The ''examples/'' directory in the source distribution includes some basic examples (the "simple vc"
and "simple vc compat" family of examples) of all these interfaces.

In principle, since we use SWIG to generate the native Java API, we
could support other languages as well. However, using CVC4 from other
languages is not supported, nor expected to work, at this time. If
you're interested in helping to develop, maintain, and test a language
binding, please contact us via the users' mailing list at
cvc-users@cs.nyu.edu.

===Building CVC4 from a repository checkout===

The following tools and libraries are additionally required to build
CVC4 from from a repository checkout rather than from a prepared
source tarball.

*'''Automake v1.11'''
*'''Autoconf v2.61'''
*'''Libtool v2.2'''
*'''ANTLR3 v3.2 or v3.4'''
*'''Java Development Kit''' ([http://www.antlr.org/wiki/pages/viewpage.action?pageId=728 required for ANTLR3])

First, use "''./autogen.sh''" to create the configure script. Then
proceed as normal for any distribution tarball. The parsers are
pre-generated for the tarballs, but don't exist in the repository; hence the extra ANTLR3 and JDK requirements to
generate the source code for the parsers, when building from the
repository.

===Examples and tutorials are not built or installed===

Examples are not built by "''make''" or "''make install''". See
''examples/README'' in the source distribution for information on what to find in the ''examples/''
directory, as well as information about building and installing them.

===Appendix: Build architecture===

The build system is generated by automake, libtool, and autoconf. It
is somewhat nonstandard, though, which (for one thing) requires that
GNU Make be used. If you ./configure in the top-level source
directory, the objects will actually all appear in
builds/${arch}/${build_id}. This is to allow multiple, separate
builds in the same place (e.g., an assertions-enabled debugging build
alongside a production build), without changing directories at the
shell. The "current" build is maintained, and you can still use
(e.g.) "make -C src/main" to rebuild objects in just one subdirectory.

You can also create your own build directory inside or outside of the
source tree and configure from there. All objects will then be built
in that directory, and you'll ultimately find the "cvc4" binary in
src/main/, and the libraries under src/ and src/parser/.

=Using the CVC4 binary=

The CVC4 driver binary ("cvc4"), once installed, can be executed directly to enter into interactive mode:

$ cvc4
cvc4 1.0 assertions:off
CVC4>

You can then enter commands into CVC4 interactively:

CVC4> OPTION "incremental";
CVC4> OPTION "produce-models";
CVC4> TRANSFORM 25*25;
625
CVC4> x, y : INT;
CVC4> QUERY x = y;
invalid
CVC4> COUNTERMODEL;
x : INT = -1;
y : INT = 0;
CVC4> ASSERT x >= 0;
CVC4> QUERY x = y;
invalid
CVC4> COUNTERMODEL;
x : INT = 0;
y : INT = 1;
CVC4>

The above example shows two useful options, ''incremental'' and ''produce-models.''

* The ''incremental'' option allows you to issue multiple QUERY (or CHECKSAT) commands, and allows the use of the PUSH and POP commands. Without this option, CVC4 optimizes itself for a single QUERY or CHECKSAT command (though you may issue any number of ASSERT commands). The ''incremental'' option may also be given by passing the ''-i'' command line option to CVC4.
* The ''produce-models'' option allows you to query the model (here, with the COUNTERMODEL command) after an "invalid" QUERY (or "satisfiable" CHECK-SAT). Without it, CVC4 doesn't do the bookkeeping necessary to support model generation. The ''produce-models'' option may also be given by passing the ''-m'' command line option to CVC4.

So, if you invoke CVC4 with ''-im'', you don't need to pass those options at all:

$ cvc4 -im
cvc4 1.0 assertions:off
CVC4> x, y : INT;
CVC4> QUERY x = y;
invalid
CVC4> COUNTERMODEL;
x : INT = -1;
y : INT = 0;
CVC4> ASSERT x >= 0;
CVC4> QUERY x = y;
invalid
CVC4> COUNTERMODEL;
x : INT = 0;
y : INT = 1;
CVC4>

By default, CVC4 operates in [[#CVC4's native input language|CVC-language mode]]. If you enter something that looks like SMT-LIB, it will suggest that you use the "''--lang smt''" command-line option for SMT-LIB mode:

CVC4> (declare-fun x () Int)
Parse Error: <shell>:1.7: In CVC4 presentation language mode, but SMT-LIB format detected. Use --lang smt for SMT-LIB support.
CVC4>

==Verbosity==

CVC4 has various levels of verbosity. By default, CVC4 is pretty quiet, only reporting serious warnings and notices. If you're curious about what it's doing, you can pass CVC4 the ''-v'' option:

$ cvc4 -v file.smt2
Invoking: (set-logic AUFLIRA)
Invoking: (set-info :smt-lib-version 2.000000)
Invoking: (set-info :category "crafted")
Invoking: (set-info :status unsat)
Invoking: (declare-fun x () Real)
''etc...''

For even more verbosity, you can pass CVC4 an ''additional'' ''-v'':

$ cvc4 -vv file.smt2
Invoking: (set-logic AUFLIRA)
Invoking: (set-info :smt-lib-version 2.000000)
Invoking: (set-info :category "crafted")
Invoking: (set-info :status unsat)
Invoking: (declare-fun x () Real)
''etc...''
expanding definitions...
constraining subtypes...
applying substitutions...
simplifying assertions...
doing static learning...
''etc...''

Internally, verbosity is just an integer value. It starts at 0, and with every ''-v'' on the command line it is incremented; with every ''-q'', decremented. It can also be set directly. From CVC language:

CVC4> OPTION "verbosity" 2;

Or from SMT-LIB language:

CVC4> (set-option :verbosity 2)

==Getting statistics==

Statistics can be dumped on exit (both normal and abnormal exits) with the ''--statistics'' command line option.

$ cvc4 --statistics foo.smt2
sat
sat::decisions, 0
sat::propagations, 3
sat::starts, 1
theory::uf::TheoryUF::functionTermsCount, 2
theory::uf::TheoryUF::mergesCount, 2
theory::uf::TheoryUF::termsCount, 6
theory<THEORY_UF>::propagations, 1
driver::filename, foo.smt2
driver::sat/unsat, sat
driver::totalTime, 0.02015373
''[many others]''

Many statistics name-value pairs follow, one comma-separated pair per line.

==Exit status==

The exit status of CVC4 depends on the ''last'' QUERY or CHECK-SAT. If you wish to call CVC4 from a program (e.g., a shell script) and care only about the satisfiability or validity of a single formula, you can pass the ''-q'' option (as described [[#Verbosity|above, under verbosity]]) and check the exit code. With ''-q'', CVC4 should not produce any output unless it encounters a fatal error.

QUERY asks a validity question, and CHECK-SAT a satisfiability question, and these are dual problems; hence the terminology is different, but really "sat" and "invalid" are the same internally, as are "unsat" and "valid":

<table border="1">
<tr><th>Solver's last result</th><th>Exit code</th><th>Notes</th></tr>
<tr><td>'''sat''' or '''invalid'''</td><td>10</td></tr>
<tr><td>'''unsat''' or '''valid'''</td><td>20</td></tr>
<tr><td>'''unknown'''</td><td>0</td><td>could be for any reason: time limit exceeded, no memory, incompleteness..</td></tr>
<tr><td>''no result''</td><td>0</td><td>no query or check-sat command issued</td></tr>
<tr><td>parse errors</td><td>0 (in interactive mode)<br/>1 (otherwise)</td><td>see below</td></tr>
<tr><td>other errors</td><td>1 (usually)</td><td>see below</td></tr>
</table>

Most "normal errors" return a 1 as the exit code, but out of memory conditions, and others, can produce different exit codes. In interactive mode, parse errors are ignored and the next line read; so in interactive mode, you may see an exit code of 0 even in the presence of such an error.

In SMT-LIB mode, an SMT-LIB command script that sets its status via "set-info :status" also affects the exit code. So, for instance, the following SMT-LIB script returns an exit code of 10 even though it contains no "check-sat" command:

(set-logic QF_UF)
(set-info :status sat)
(exit)

Without the "set-info," it would have returned an exit code of 0.

=CVC4's native input language=

The native input language consists of a sequence of symbol declarations and commands, each followed by a semicolon (<code>;</code>).

Any text after the first occurrence of a percent character and to the end of the current line is a comment:

%%% This is a native language comment

== Type System ==

CVC4's type system includes a set of built-in types which can be expanded with additional user-defined types.

The type system consists of ''first-order'' types, ''subtypes'' of first-order types, and ''higher-order'' types, all of which are interpreted as sets.
For convenience, we will sometimes identify below the interpretation of a type with the type itself.

First-order types consist of basic types and structured types. The basic types are <math>\mathrm{BOOLEAN}</math>, <math>\mathrm{REAL}</math>, <math>\mathrm{BITVECTOR}(n)</math> for all <math>n > 0</math>, as well as user-defined basic types (also called uninterpreted types).
The structured types are array, tuple, record types, and ML-style user-defined (inductive) datatypes.

'''Note:''' Currently, subtypes consist only of the built-in subtype <math>\mathrm{INT}</math> of <math>\mathrm{REAL}</math>.

Support for CVC3-style user-defined subtypes will be added in a later release.

Function types are the only higher-order types.
More precisely, they are just second-order types
since function symbols in CVC4, both built-in and user-defined, can take as argument or return only values of
a first-order type.

=== Basic Types ===

==== The BOOLEAN Type ====

The <math>\mathrm{BOOLEAN}</math> type is interpreted as the two-element set of Boolean values
<math>\{\mathrm{TRUE},\; \mathrm{FALSE}\}</math>.

'''Note:''' CVC4's treatment of this type differs from CVC3's where <math>\mathrm{BOOLEAN}</math> is used only as the type of formulas, but not as value type. CVC3 follows the two-tiered structure of classical first-order logic
which distinguishes between formulas and terms, and allows terms to occur in formulas but not vice versa (with the exception of the IF-THEN-ELSE construct).
CVC4 drops the distinction between terms and formulas and defines the latter just as terms of type <math>\mathrm{BOOLEAN}</math>. As such, formulas can occur as subterms of possibly non-Boolean terms.

Example:

[To do]

==== The REAL Type ====

The <math>\mathrm{REAL}</math> type is interpreted as the set of real numbers.

Note that these are the (infinite precision) mathematical reals,
not the floating point numbers.
Support for floating point types is planned for future versions.

x, y : REAL;
QUERY (( x <= y ) AND ( y <= x )) => ( x = y );

==== The INT Type ====

The <math>\mathrm{INT}</math> type is interpreted as the set of integer numbers
and is considered as a subtype of <math>\mathrm{REAL}</math>.
The latter means in particular that it is possible to mix integer and real terms
in expressions without the need of an explicit ''upcasting'' operator.

Note that these are the (infinite precision) mathematical integers,
not the finite precision machine integers used in most programming languages.
The latter are models by [[ #Bitvectors | bit vector ]] types.

x, y : INT;
QUERY ((2 * x + 4 * y <= 1) AND ( y >= x)) => (x <= 0);
z : REAL;
QUERY (2 * x + z <= 3.5) AND (z >= 1);

==== Bit Vector Types ====

For every positive integer <math>n</math>, the type <math>\mathrm{BITVECTOR}(n)</math> is interpreted as the set of all bit vectors of size <math>n</math>.
A rich set of bit vector operators is supported.

==== User-defined Basic Types ====

Users can define new basic types
(often referred to as ''uninterpreted'' types in the SMT literature).
Each such type is interpreted as a set of unspecified cardinality
but disjoint from any other type.

User-defined basic types are created by declarations like the following:

% User declarations of basic types:

MyBrandNewType: TYPE;

Apples, Oranges: TYPE;

=== Structured Types ===

CVC4's structured types are divided in the following families.

==== Array Types ====

Array types are created by the mixfix type constructors <math>\mathrm{ARRAY}\ \_\ \mathrm{OF}\ \_</math>
whose arguments can be instantiated by any value type.

I : TYPE;

%% Array types:

% Arrays with indices from I and values from REAL
Array1: TYPE = ARRAY I OF REAL;

% Arrays with integer indices and array values
Array2: TYPE = ARRAY INT OF (ARRAY INT OF REAL);

% Arrays with integer pair indices and integer values
IntMatrix: TYPE = ARRAY [INT, INT] OF INT;

An array type of the form <math>\mathrm{ARRAY}\ T_1\ \mathrm{OF}\ T_2</math> is interpreted
as the set of all total maps from <math>T_1</math> to <math>T_2</math>.
The main difference with the function type <math>T_1 \to T_2</math> is that arrays,
contrary to functions, are first-class objects of the language, that is, values of an array
type can be arguments or results of functions.
Furthermore, array types come equipped with an update operation.

==== Tuple Types ====

Tuple types are created by the mixfix type constructors

<center>
<math>
\begin{array}{l} [\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ \ ,\ \_\ ] \\[1ex] \ldots \end{array}
</math>
</center>

whose arguments can be instantiated by any value type.

IntArray: TYPE = ARRAY INT OF INT;

% Tuple type declarations

RealPair: TYPE = [REAL, REAL]

MyTuple: TYPE = [ REAL, IntArray, [INT, INT] ];

A tuple type of the form <math>[T_1, \ldots, T_n]</math> is interpreted
as the Cartesian product <math>T_1 \times \cdots \times T_n</math>.

Note that while the types <math>(T_1, \ldots, T_n) \to T</math> and
<math>[T_1 \times \cdots \times T_n] \to T</math> are semantically equivalent,
they are operationally different in CVC4.
The first is the type of functions that take <math>n</math> arguments
of respective type <math>T_1</math>, <math>\ldots</math>, <math>T_n</math>,
while the second is the type of functions that take one argument of an <math>n</math>-tuple type.

==== Record Types ====

Similar to, but more general than tuple types, record types are created by type constructors of the form

<center>
<math>
[\#\ l_1: \_\ ,\ \ldots\ ,\ l_n: \_\ \#]
</math>
</center>

where <math>n > 0</math>, <math>l_1,\ldots, l_n</math> are field labels,
and the arguments can be instantiated with any first-order types.

MyType: TYPE;

% Record declaration

RecordType: TYPE = [# id: REAL, age: INT, info: MyType #];

The order of the fields in a record type is meaningful:
permuting the field names gives a different type.

Note that record types are non-recursive.
For instance, it is not possible to declare a record type called <code>Person</code> containing
a field of type <code>Person</code>.
Recursive types are provided in CVC4 by the more general inductive data types.
(As a matter of fact, both record and tuple types are implemented internally as inductive data types.)

==== Inductive Data Types ====

Inductive data types in CVC4 are similar to inductive data types of functional languages.
They can be parametric or not.

===== Non-Parametric Data Types =====

Non-parametric data types are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1 & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2 & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types, including any <math>A_i</math>.
Such declarations define the data types <math>A_1, \ldots, A_n</math>.
For each data type <math>A_i</math> they introduce:

* constructor symbols <math>cons</math> of type <math>(T_1, \ldots, T_k) \to \mathit{type\_name}_i</math>,
* selector symbols <math>\mathit{sel}_j</math> of type <math>\mathit{type\_name}_i \to T_j</math>, and
* tester symbols <math>\mathit{is\_cons}</math> of type <math>\mathit{type\_name}_i \to \mathrm{BOOLEAN}</math>.

Note that permitting more than one data type to be defined in the same declarations allows
the definition of mutually recursive types.

% simple enumeration type

% implicitly defined are the testers: is_red, is_yellow and is_blue
% (similarly for the other data types)

DATATYPE
PrimaryColor = red | yellow | blue
END;

% infinite set of pairwise distinct values ..., v(-1), v(0), v(1), ...

DATATYPE
Id = v (id: INT)
END;

% ML-style integer lists

DATATYPE
IntList = nil | ins (head: INT, tail: IntList)
END;

% AST for lamba calculus

DATATYPE
Term = var (index: INT)
| apply (arg_1: Term, arg_2: Term)
| lambda (arg: INT, body: Term)
END;

% Trees

DATATYPE
Tree = tree (value: REAL, children: TreeList),
TreeList = nil_tl
| ins_tl (first_t1: Tree, rest_t1: TreeList)
END;

Constructor, selector and tester symbols defined for a data type have global scope.
So, for example, it is not possible for two different data types to use
the same name for a constructor.

An inductive data type is interpreted as a term algebra constructed by the constructor symbols
over some sets of generators.
For example, the type <code>IntList</code> defined above is interpreted as the set
of all terms constructed with <code>nil</code> and <code>ins</code> over the integers.

===== Parametric Data Types =====

Parametric data types are infinite families of (non-parametric) data types
with each family parametrized by one or more type variables.
They are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE}\ [X_1, \ldots, X_p] \\
\begin{array}{ccc}
\ \ A_1 & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2 & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
<math>X_1, \ldots, X_p</math> are type variables,
each <math>A_i</math> is a type name parametrized by some of the variables <math>X_1, \ldots, X_p</math>
and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types,
possibly parametrized by <math>X_1, \ldots, X_p</math>, including any <math>A_i</math>.

% Parametric pairs
DATATYPE [X, Y]
Pair[X, Y] = pair (first: X, second: Y)
END;

% Parametric lists

DATATYPE [X]
List[X] = nil | cons (head: X, tail: List[X])
END;

% Parametric trees using the list type above

DATATYPE [X]
Tree[X] = node (value: X, children: List[Tree[X]]),
END;

The declarations above define infinitely many types of the form
Pair[S,T], List[T] and Tree[T] where S and T are first-order types.
Note that the identifier <code>List</code> above, for example, by itself does not denote a type.
In contrast, the terms <code>List[Real]</code>, <code>List[List[Real]]</code>, <code>List[Tree[INT]]</code>,
and so on do.

===== Restriction to Inductive Types =====

By adopting a term algebra semantics, CVC4 allows only ''inductive'' data types,
that is, data types whose values are essentially (labeled, ordered) finite trees.
Infinite structures such as streams or even finite but cyclic ones
such as circular lists are then excluded.
For instance, none of the following declarations define inductive data types,
and are rejected by CVC4:

DATATYPE
IntStream = s (first:INT, rest: IntStream)
END;

DATATYPE
RationalTree = node1 (child: RationalTree)
| node2 (left_child: RationalTree, right_child:RationalTree)
END;

DATATYPE
T1 = c1 (s1: T2),
T2 = c2 (s2: T1)
END;

In concrete, a declaration of <math>n \geq 1</math> datatypes <math>T_1, \ldots, T_n</math> will be rejected if for any one of the types <math>T_1, \ldots, T_n</math>, it is impossible to build a finite term of that type using only the constructors of <math>T_1, \ldots, T_n</math> and free constants of type other than <math>T_1, \ldots, T_n</math>.

Inductive data types are the only types where the user also chooses names for the built-in operations to:

* construct a value of the type (with the constructors),
* extract components from a value (with the selectors), or
* check if a value was constructed with a certain constructor or not (with the testers).

For all the other types, CVC4 provides predefined names for the built-in operations on the type.

=== Function Types ===

Function (<math>\to</math>) types are created by the mixfix type constructors
<center>
<math>
\begin{array}{l}
\_ \to \_ \\[1ex] (\ \_\ ,\ \_\ ) \to \_
\\[1ex] (\ \_\ ,\ \_\ ,\ \_\ ) \to \_
\\[1ex] \ldots
\end{array}
</math>
</center>
whose arguments can be instantiated by any first-order type.

% Function type declarations

UnaryFunType: TYPE = INT -> REAL;

BinaryFunType: TYPE = (REAL, REAL) -> ARRAY REAL OF REAL;

TernaryFunType: TYPE = (REAL, BITVECTOR(4), INT) -> BOOLEAN;

A function type of the form <math>(T_1, \ldots, T_n) \to T</math> with <math>n > 0</math> is interpreted as the set of all ''total'' functions from the Cartesian product <math>T_1 \times \cdots \times T_n</math> to <math>T</math>.

The example above also shows how to introduce type names.
A name like <code>UnaryFunType</code> above is just an abbreviation for the type <math>\mathrm{INT} \to \mathrm{REAL}</math> and can be used interchangeably with it.

In general, any type defined by a type expression <code>E</code> can be given a name with the declaration:

name : TYPE = E;

=== Type Checking ===

In CVC4, formulas and terms are statically typed at the level of types
(as opposed to subtypes) according to the usual rules of first-order many-sorted logic,
with the main difference that formulas are just terms of type <math>BOOLEAN</math>:

* each variable has one associated first-order type,
* each constant symbol has one or more associated first-order types,
* each function symbol has one or more associated function types,
* the type of a term consisting just of a variable is the type associated to that variable,
* the type of a term consisting just of a constant symbol is the type associated to that constant symbol,
* the term obtained by applying a function symbol <math>f</math> to the terms <math>t_1, \ldots, t_n</math> is <math>T</math> if <math>f</math> has type <math>(T_1, \ldots, T_n) \to T</math> and each <math>t_i</math> has type <math>T_i</math>.

Attempting to enter an ill-typed term will result in an error.

Another significant difference with standard many-sorted logic is that
some built-in symbols are parametrically polymorphic.
For instance, the function symbol for extracting the element of any array has
type <math>(\mathit{ARRAY}\ T_1\ \mathit{OF}\ T_2,\; T_1) \to T_2</math>
for all first-order types <math>T_1, T_2</math>.

==== Type Ascription ====

By the type inference rules above some terms might have more than one type.
This can happen with terms built with polymorphic data type constructors
that have more than one return type for the same input type.
In that case, a type ascription operator (<code>::</code>) must be applied
to the constructor to specify the intended return type.

DATATYPE [X]
List[X] = nil | cons (head: X, tail: List[X])
END;

ASSERT y = cons(1, nil::List[REAL]);

DATATYPE [X, Y]
Union[X, Y] = left(val_l: X) | right(val_r: Y)
END;

ASSERT y = left::Union[BOOLEAN, REAL](TRUE);

The constant symbol <math>\mathrm{nil}</math> declared above has infinitely many types
(<math>\mathrm{List}[\mathrm{REAL}]</math>, <math>\mathrm{List}[\mathrm{BOOLEAN}]</math>,
<math>\mathrm{List}[[\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{List}[\mathrm{List}[\mathrm{REAL}]]</math>, ...)
CVC4's type checker requires the user to indicate explicitly the type
of each occurrence of <code>nil</code> in a term.
Similarly,
the injection operator <code>left</code> has infinitely many return types
for the same input type, for instance:
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{REAL}]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, [\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{List}[\mathrm{REAL}]]</math>,
and so on.
Applications of <code>left</code> need to specify the intended returned typed, as shown above.

== Terms and Formulas ==

In addition to type expressions, CVC4 has expressions for terms and for formulas
(i.e., terms of type <math>\mathrm{BOOLEAN}</math>).
By and large, these are standard first-order terms built out of typed variables,
predefined theory-specific operators, free (i.e., user-defined) function symbols,
and quantifiers.
Extensions include an if-then-else operator, lambda abstractions, and local symbol
declarations, as illustrated below.
Note that these extensions still keep CVC4's language first-order.
In particular, lambda abstractions are restricted to take and return only terms of
a first-order type.
Similarly, variables can only be of a first-order type.

A number of built-in function symbols (for instance, the arithmetic ones) are used
as infix operators. All user-defined symbols are used as prefix ones.

User-defined, i.e., free, function symbols include ''constant symbols'' and
''predicate symbols'', respectively nullary function symbols and function symbols
with a <math>\mathrm{BOOLEAN}</math> return type.
These symbols are introduced with global declarations of the form
<math> f_1, \ldots, f_m: T;</math>
where <math>m > 0</math>, <math>f_i</math> are the names of the symbols and
<math>T</math> is their type:

% integer constants

a, b, c: INT;

% real constants

x, y, z: REAL;

% unary function

f1: REAL -> REAL;

% binary function

f2: (REAL, INT) -> REAL;

% unary function with a tuple argument

f3: [INT, REAL] -> BOOLEAN;

% binary predicate

p: (INT, REAL) -> BOOLEAN;

% Propositional "variables"

P, Q; BOOLEAN;

Like type declarations, function symbol declarations like the above have global scope
and must be unique.
In other words, it is not possible to declare a function symbol globally more than once
in the same lexical scope.
This entails among other things that globally-defined free symbols cannot be overloaded
with different types and that theory symbols cannot be redeclared globally as free symbols.

=== Global symbol definitions ===

As with types, a function symbol can be defined as the name of another term
of the corresponding type.
With constant symbols, this is done with a declaration of the form <math>f:T = t;</math> :

c: INT;

i: INT = 5 + 3*c; % i is effectively a shorthand for 5 + 3*c

j: REAL = 3/4;

t: [REAL, INT] = (2/3, -4);

r: [# key: INT, value: REAL #] = (# key := 4, value := (c + 1)/2 #);

f: BOOLEAN = FORALL (x:INT): x <= 0 OR x > c ;

A restriction on constants of type <math>\mathit{BOOLEAN}</math> is that their value
can only be a closed formula, that is, a formula with no free variables.

A term and its name can be used interchangeably in later expressions.
Named terms are often useful for shared subterms (terms used several times in different places)
since their use can make the input exponentially more concise.
Named terms are processed very efficiently by CVC4.
It is much more efficient to associate a complex term with a name directly rather than
to declare a constant and later assert that it is equal to the same term.
This point is explained in more detail later in section [[Commands | Commands]].

More generally, in CVC4 one can associate a term to function symbols of any arity.
For non-constant function symbols this is done with a declaration of the form

<center>
<math>f:(T_1, \ldots, T_n) \to T = \mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t\;;</math>
</center>

where <math>t</math> is any term of type <math>T</math> with free variables
in <math>\{x_1, \ldots, x_n\}</math>.
The lambda binder has the usual semantics and conforms to the usual lexical scoping rules:
within the term <math>t</math> the declaration of the symbols <math>x_1, \ldots, x_n</math>
as local variables of respective type <math>T_1, \ldots, T_n</math> hides any previous
declarations of those symbols that are in scope.

As a general shorthand, when <math>k</math> consecutive types
<math>T_i, \ldots, T_{i+k-1}</math> in the lambda expression
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t</math> are identical, the syntax
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x_i,\ldots, x_{i+k-1}:T_i,\ldots, x:T_n): t</math>
can also be used.

% Global declaration of x as a unary function symbol

x: REAL -> REAL;

% Local declarations of x as variable (hiding the global one)

f: REAL -> REAL = LAMBDA (x: REAL): 2*x + 3;

p: (INT, INT) -> BOOLEAN = LAMBDA (x,i: INT): i*x - 1 > 0;

g: (REAL, INT) -> [REAL, INT] = LAMBDA (x: REAL, i:INT): (x + 1, i - 3);

Note that lambda definitions are not recursive:
the symbol being defined cannot occur in the body of the lambda term.
They should be understood as macros.
For instance, any occurrence of the term <math>f(t)</math>
where <math>f</math> is as defined above will be treated
as if it was the term <math>(2*t + 3)</math>.

=== Local symbol definitions ===

Constant and function symbols can also be declared locally anywhere within a term
by means of a let binder.
This is done with a declaration of the form

<center>
<math>
\mathrm{LET}\ f = t \ \mathrm{IN}\ t' ;
</math>
</center>

where <math>t</math> is a term with no free variables, possibly a lambda term.
Let binders can be nested arbitrarily and follow the usual lexical scoping rules.
The following general form
<center>
<math>
\mathrm{LET}\ f_1 = t_1, f_2 = t_2, \ldots, f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>
can be use above can used as a shorthand for
<center>
<math>
\mathrm{LET}\ f_1 = t_1\ \mathrm{IN}\
\mathrm{LET}\ f_2 = t_2\ \mathrm{IN}\
\ldots \
\mathrm{LET}\ f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>

t: REAL =
LET x1 = 42,
g = LAMBDA(x:INT): x + 1,
x2 = 2*x1 + 7/2
IN
(LET x3 = g(x1) IN x3 + x2) / x1;

Note that the same symbol = is used, unambiguously, in the syntax of global declarations,
let declarations, and as a predicate symbol.

'''Note:'''
A <math>\mathrm{LET}</math> term with a multiple symbols defines them sequentially.
A parallel version of the <math>\mathrm{LET}</math> construct will be introduced in a later version.

== Built-in theories and their symbols ==

In addition to user-defined symbols, CVC4 terms can use a number of predefined symbols:
the logical symbols, such as <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, etc.,
as well as theory symbols, function symbols belonging to one of the built-in theories.
They are described next, with the theory symbols grouped by theory.

=== Logical Symbols ===

The logical symbols in CVC4's language include
the equality and disequality predicate symbols, respectively written as = and /=,
the multiarity disequality symbol <math>\mathrm{DISTINCT}</math>,
together with the logical constants <math>\mathrm{TRUE}</math>, <math>\mathrm{FALSE}</math>,
the connectives <math>\mathrm{NOT}</math>, <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, <math>\mathrm{XOR}</math>, <math>\Rightarrow</math>, <math>\Leftrightarrow</math>, and
the first-order quantifiers <math>\mathrm{EXISTS}</math> and <math>\mathrm{FORALL}</math>,
all with the standard many-sorted logic semantics.

The binary connectives have infix syntax and type
<math>(\mathrm{BOOLEAN},\mathrm{BOOLEAN}) \to \mathrm{BOOLEAN}</math>.
The symbols = and /=, which are also infix, are instead parametrically polymorphic,
having type <math>(T,T) \to \mathrm{BOOLEAN}</math>
for every first-order type <math>T</math>.
They are interpreted respectively as the identity relation and its complement.

The DISTINCT symbol is both overloaded and polymorphic.
It has type <math>(T,...,T) \to \mathrm{BOOLEAN}</math>
for every sequence <math>(T,...,T)</math> of length <math>n > 0</math>
and first-order type <math>T</math>.
For each <math>n > 0</math>, it is interpreted as the relation
that holds exactly for tuples of pairwise distinct elements.

The syntax for quantifiers is similar to that of the lambda binder.

Here is an example of a formula built just of these logical symbols and variables:

A, B: TYPE;

q: BOOLEAN = FORALL (x,y: A, i,j,k: B):
i = j AND i /= k => EXISTS (z: A): x /= z OR z /= y;

Binding and scoping of quantified variables follows the same rules as
in let expressions.
In particular, a quantifier will shadow in its scope any constant and function symbols
with the same name as one of the variables it quantifies:

A: TYPE;
i, j: INT;

% The first occurrence of i and of j in f are constant symbols,
% the others are variables.

f: BOOLEAN = i = j AND FORALL (i,j: A): i = j OR i /= j;

Optionally, it is also possible to specify instantiation patterns
for quantified variables.
The general syntax for a quantified formula <math>\psi</math> with patterns is

<center>
<math>
Q\;(x_1:T_1, \ldots, x_k:T_k):\; p_1: \ldots\; p_n:\; \varphi
</math>
</center>

where <math>n \geq 0</math>, <math>Q</math> is
either <math>\mathrm{FORALL}</math> or <math>\mathrm{EXISTS}</math>,
<math>\varphi</math> is a term of type <math>\mathrm{BOOLEAN}</math>,
and each of the <math>p_i</math>'s,
a pattern for the quantifier <math>Q\;(x_1:T_1, \ldots, x_k:T_k)</math>, has the form

<center>
<math>
\mathrm{PATTERN}\; (t_1, \ldots, t_m)
</math>
</center>

where <math>m > 0</math> and <math>t_1, \ldots, t_m</math> are
arbitrary binder-free terms (no lets, no quantifiers).
Those terms can contain (free) variables, typically, but not exclusively,
drawn from <math>x_1, \ldots, x_k</math>.
(Additional variables can occur if <math>\psi</math> occurs in a bigger formula
binding those variables.)

A: TYPE;
b, c: A;
p, q: A -> BOOLEAN;
r: (A, A) -> BOOLEAN;

ASSERT FORALL (x0, x1, x2: A):
PATTERN (r(x0, x1), r(x1, x2)):
(r(x0, x1) AND r(x1, x2)) => r(x0, x2) ;

ASSERT FORALL (x: A):
PATTERN (r(x, b)):
PATTERN (r(x, c)):
p(x) => q(x) ;

ASSERT EXISTS (y: A):
FORALL (x: A):
PATTERN (r(x, y), p(y)):
r(x, y) => q(x) ;

Patterns have no logical meaning:
adding them to a formula does not change its semantics.
Their purpose is purely operational, as explained in
the [[#Instantiation Patterns | Instantiation Patterns]] section.

In addition to these constructs, CVC4 also has a general mixfix conditional operator
of the form

<center>
<math>
\mathrm{IF}\ b\ \mathrm{THEN}\ t\ \mathrm{ELSIF}\ b_1\ \mathrm{THEN}\ t_1\ \ldots\ \mathrm{ELSIF}\ b_n\ \mathrm{THEN}\ t_n\ \mathrm{ELSE}\ t_{n+1}\ \mathrm{ENDIF}
</math>
</center>

with <math>n \geq 0</math> where
<math>b, b_1, \ldots, b_n</math> are terms of type <math>\mathrm{BOOLEAN}</math> and
<math>t, t_1, \ldots, t_n, t_{n+1}</math> are terms of the same first-order type <math>T</math>:

% Conditional term
x, y, z, w: REAL;

t: REAL =
IF x > 0 THEN y
ELSIF x >= 1 THEN z
ELSIF x > 2 THEN w
ELSE 2/3 ENDIF;

=== User-defined Functions and Types ===

The theory of user-defined functions,also know in the SMT literature as
the theory ''Equality over Uninterpreted Functions'', or ''EUF'', is in effect
a family of theories of equality parametrized by the basic types and the free symbols
a user can define during a run of CVC4.

This theory has no built-in symbols (other than the logical ones).
Its types consist of ''all and only'' the user-defined types.
Its function symbols consist of ''all and only'' the user-defined free symbols.

=== Arithmetic ===

The real arithmetic theory has two types:
<math>\mathrm{REAL}</math> and <math>\mathrm{INTEGER}</math>
with the latter a subtype of the first.
Its built-in symbols for the usual arithmetic constants
and operators over the type <math>\mathrm{REAL}</math>, each with the expected type:
all numerals 0, 1, ..., as well as - (both unary and binary), +, *, /, <, >, <=, >=.
Application of the binary symbols are in infix form.
Note that + is only binary, so a terms such as +4 is ill-formed.

Rational values can be expressed in decimal or fractional format:
e.g., 0.1, 23.243241, 1/2, 3/4, and so on.
A leading 0 is mandatory for decimal numbers smaller than one
(e.g., the syntax .3 is cannot be used as a shorthand for 0.3).
However, a trailing 0 is ''not'' required for decimals that are whole numbers
(e.g., 3. is allowed as a shorthand for 3.0).
The size of the numerals used in the representation of natural and rational numbers
is unbounded; more accurately, bounded only by the amount of available memory.

=== Bit vectors ===

=== Arrays ===

The theory of arrays is a parametric theory of (total) unary maps.
It comes equipped with mixfix polymorphic selection and update operators, respectively
<center>
<math>\_[\_]</math> and <math>\_\ \mathrm{WITH}\ [\_]\ := \_</math> .
</center>
The semantics of these operators is the expected one:
for all first-order types <math>T_1</math> and <math>T_2</math>,
if <math>a</math> is of type <math>\mathrm{ARRAY}\ T_1 \mathrm{OF}\ T_2</math>,
<math>i</math> is of type <math>T_1</math>, and
<math>v</math> is of type <math>T_2</math>,
* <math>a[i]</math> denotes the value that <math>a</math> associates to index <math>i</math>,
* <math>a\ \mathrm{WITH}\ [i]\ := v</math> denotes a map that associates <math>v</math> to index <math>i</math> and is otherwise identical to <math>a</math>.
Sequential updates can be chained with the shorthand syntax
<math>\_\ \mathrm{WITH}\ [\_]\ := \_, \ldots, [\_]\ := \_</math>.

A: TYPE = ARRAY INT OF REAL;
a: A;
i: INT = 4;

% selection:

elem: REAL = a[i];

% update

a1: A = a WITH [10] := 1/2;

% sequential update
% (syntactic sugar for (a WITH [10] := 2/3) WITH [42] := 3/2)

a2: A = a WITH [10] := 2/3, [42] := 3/2;

Since arrays are just maps, equality between them is extensional, that is,
for two arrays of the same type to be different they have to map at least one
index to differ values.

=== Data types ===

The theory of inductive data types is in fact a family of theories parametrized
by a data type declaration specifying constructors and selectors
for one or more user-defined data types.

No built-in operators other than equality and disequality are provided
for this family in the native language.
Each user-provided data type declaration, however, generates constructor, selector and tester operators
as described in the [[#Inductive Data Types | Inductive Data Types]] section.

=== Tuples and Records ===

Semantically both records and tuples can be seen as special instances
of inductive data types.
CVC4 implements them internally indeed as data types.
In essence, a record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math>
is encoded as a data type of the form

<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\ \ \mathrm{Record} = \mathit{rec}(l_0:T_0, \ldots, l_n:T_n) \\
\mathrm{END};
\end{array}
</math>
</center>

Tuples of length <math>n</math> are in turn special cases of records whose field names are
the numerals from <math>0</math> to <math>n-1</math>.

Externally, tuples and records have their own syntax for constructor and selector operators.
* Records of type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> have the associated record constructor <math>(\#\ l_0 := \_,\; \ldots,\; l_n := \_\ \#)</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.
* Tuples of type <math>[\ T_0, \ldots, T_n\ ]</math> have the associated tuple constructor <math>(\ \_,\; \ldots,\; \_\ )</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.

The selector operators on records and tuples follows a dot notation syntax.

% Record construction and field selection
Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);
k: INT = x.key;
v: REAL = x.weight;

% Tuple construction and projection
y: [REAL, INT, REAL] = ( 4/5, 9, 11/9 );
first_elem: REAL = y.0;
third_elem: REAL = y.2;

Differently from data types, records and tuples are also provided with built-in update operators similar in syntax and semantics to the update operator for arrays.
More precisely, for each record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .l_i\ := \_
</math>
</center>

The operator maps a record <math>r</math> of that type and a value <math>v</math>
of type <math>T_i</math> to the record that stores <math>v</math> in field <math>l_i</math>
and is otherwise identical to <math>r</math>.
Analogously, for each tuple type <math>[T_0, \ldots, T_n]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .i\ := \_
</math>
</center>

with similar semantics.

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = x WITH .weight := 48;

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = y WITH .1 := 3;

Updates to a nested component can be combined in a single WITH operator:

Cache: TYPE = ARRAY [0..100] OF [# addr: INT, data: REAL #];
State: TYPE = [# pc: INT, cache: Cache #];

s0: State;
s1: State = s0 WITH .cache[10].data := 2/3;

Note that, differently from updates on arrays, tuple and record updates are
just additional syntactic sugar.
For instance, the record <code>x1</code> and tuple <code>y1</code> defined above
could have been equivalently defined as follows:

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = (# key := x.key, weight := 48 #);

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = ( y.0, 3, y.1 );

== Commands ==

In addition to declarations of types and function symbols,
the CVC4 native language contains the following commands:

* <math>\mathrm{ASSERT}\ F</math> -- Add the formula <math>F</math> to the current logical context <math>\Gamma</math>.
* [[#CHECKSAT|<math>\mathrm{CHECKSAT}\ F</math>]] -- Check if the formula <math>F</math> is satisfiable in the current logical context (<math>\Gamma \not\models_T \mathrm{NOT}\ F</math>).
* <math>\mathrm{CONTINUE}</math> -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, search for a counter-example different from the current one.
* [[#COUNTEREXAMPLE|<math>\mathrm{COUNTEREXAMPLE}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print the context that is a witness for invalidity/satisfiability.
* [[#COUNTERMODEL|<math>\mathrm{COUNTERMODEL}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print a model that makes the formula invalid/satisfiable. The model is provided in terms of concrete values for each free symbol.
* <math>\mathrm{OPTION}\ o\ v</math> -- Set the command-line option flag <math>o</math> to value <math>v</math>. The argument <math>o</math> is provide as a string literal enclosed in double-quotes and <math>v</math> as an integer value.
* <math>\mathrm{POP}</math> -- Equivalent to <math>\mathrm{POPTO}\ 1</math>
* [[#POPTO|<math>\mathrm{POPTO}\ n</math>]] -- Restore the system to the state it was in right before the most recent call to <math>\mathrm{PUSH}</math> made from stack level <math>n</math>. Note that the current stack level is printed as part of the output of the <math>\mathrm{WHERE}</math> command.
* <math>\mathrm{PUSH}</math> -- Save (checkpoint) the current state of the system.
* [[#QUERY|<math>\mathrm{QUERY}\ F</math>]] -- Check if the formula <math>F</math> is valid in the current logical context (<math>\Gamma\models_T F</math>).
* [[#RESTART|<math>\mathrm{RESTART}\ F</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, repeat the check but with the additional assumption <math>F</math> in the context.
* <math>\mathrm{PRINT}\ t</math> -- Parse and print back the term <math>t</math>.
* <math>\mathrm{TRANSFORM}\ t</math> -- Simplify the term <math>t</math> and print the result.
* <math>\mathrm{WHERE}</math> -- Print all the formulas in the current logical context <math>\Gamma</math>.

The remaining commands take a single argument, given as a string literal enclosed in double-quotes.

* <math>\mathrm{ECHO}\ s</math> -- Print string <math>s</math>
* <math>\mathrm{INCLUDE}\ f</math> -- Read commands from file <math>f</math>.
* <math>\mathrm{TRACE}\ f</math> -- Turn on tracing for the debug flag <math>f</math>.
* <math>\mathrm{UNTRACE}\ f</math> -- Turn off tracing for the debug flag <math>f</math>.

Here, we explain some of the above commands in more detail.

=== QUERY ===

The command <math>\mathrm{QUERY}\ F</math> invokes the core functionality of CVC4 to check
the validity of the formula <math>F</math> with respect to the assertions made thus far,
which constitute the context <math>\Gamma</math>.
The argument <math>F</math> must be well typed term of type <math>\mathrm{BOOLEAN}</math>,
as described in [[#Terms and Formulas | Terms and Formulas]].

The execution of this command always terminates and produces one of three possible answers:
<code>valid</code>, <code>invalid</code>, and <code>unknown</code>.

* A <code>valid</code> answer indicates that <math>\Gamma \models_T F</math>. After a query returning such an answer, the logical context <math>\Gamma</math> is exactly as it was before the query.
* An <code>invalid</code> answer indicates that <math>\Gamma \not\models_T F</math>, that is, there is a model of the background theory <math>T</math> that satisfies <math>\Gamma \cup \{\mathrm{NOT}\ F\}</math>. When <math>\mathrm{QUERY}\ F</math> returns <code>invalid</code>, the logical context <math>\Gamma</math> is augmented with a set <math>\Delta</math> of ground (i.e., variable-free) literals such that <math>\Gamma\cup\Delta</math> is satisfiable in <math>T</math>, but <math>\Gamma\cup\Delta\models_T \mathrm{NOT}\ F</math>. In fact, in this case <math>\Delta</math> ''propositionally entails'' <math>\mathrm{NOT}\ F</math>, in the sense that, every truth assignment to the literals of <math>\Delta</math> that satisfies <math>\Delta</math> falsifies <math>F</math>. We call the new context <math>\Gamma\cup\Delta</math> a ''counterexample'' for <math>F</math>.
* An <code>unknown</code> answer is similar to an <code>invalid</code> answer in that additional literals are added to the context which propositionally entail <math>\mathrm{NOT}\ F</math>. The difference in this case is that CVC4 cannot guarantee that <math>\Gamma\cup\Delta</math> is actually satisfiable in <math>T</math>.

CVC4 may report <code>unknown</code> when the context or the query contains
non-linear arithmetic terms or quantifiers.
In all other cases, it is expected to be sound and complete,
i.e., to report <code>Valid</code> if <math>\Gamma \models_T F</math>
and <code>Invalid</code> otherwise.

After an <code>invalid</code> (resp. <code>unknown</code>) answer,
counterexamples (resp. possible counterexamples) can be obtained with
a <math>\mathrm{WHERE}</math>, <math>\mathrm{COUNTEREXAMPLE}</math>,
or <math>\mathrm{COUNTERMODEL}</math> command.


Since the <math>\mathrm{QUERY}</math> command may modify
the current context, if one needs to check several formulas in a row
in the same context, it is a good idea to surround every
query by a <math>\mathrm{PUSH}</math> and <math>\mathrm{POP}</math> invocation
in order to preserve the context:

PUSH;
QUERY <formula>;
POP;

=== CHECKSAT ===

The command <math>\mathrm{CHECKSAT}\ F</math> behaves identically
to <math>\mathrm{QUERY}\ \mathrm{NOT}\ F</math>.

=== RESTART ===

The command <math>\mathrm{RESTART}\ F</math> can only be invoked after an invalid query.
For example, in an interactive setting:

QUERY <formula>;

CVC4> invalid

RESTART <formula2>;

Functionally, the behavior of the above command sequence is identical to the following:

PUSH;
QUERY <formula>;
POP;
ASSERT <formula2>;
QUERY <formula>;

The advantage of using the <math>\mathrm{RESTART}</math> command is that
the first command sequence may be executed much more efficiently that the second.
The reason is that with <math>\mathrm{RESTART}</math> CVC4 will re-use
what it has learned while answering the previous query rather than starting
over from scratch.

=== COUNTERMODEL ===

[More]

=== COUNTEREXAMPLE ===

[More]

=== POPTO ===

[More]

== Instantiation Patterns ==

CVC4 processes each universally quantified formula in the current context
by adding instances of the formula obtained by replacing its universal variables
with ground terms.
Patterns restrict the choice of ground terms for the quantified variables,
with the goal of controlling the potential explosion of ground instances.
In essence, adding patterns to a formula is a way for the user to tell CVC4
to focus only on certain instances which, in the user's opinion, will be
most helpful during a proof.

In more detail, patterns have the following effect on formulas that are found
in the logical context or get added to it later while CVC4 is trying to prove
the validity of some formula <math>F</math>.

If a formula in the current context starts with an existential quantifier,
CVC4 ''Skolemizes'' it, that is, replaces it in the context with the formula
obtained by substituting the existentially quantified variables
by fresh constants and dropping the quantifier.
Any patterns for the existential quantifier are simply ignored.

If a formula starts with a universal quantifier
<math>\mathrm{FORALL}\; (x_1:T_1, \ldots, x_n:T_n)</math>,
CVC4 adds to the context a number of instances of the formula,
with the goal of using them to prove the query <math>F</math> valid.
An instance is obtained by replacing each <math>x_i</math> with a ground term
of the same type occurring in one of the formulas in the context,
and dropping the universal quantifier.
If <math>x_i</math> occurs in a pattern
<math>\mathrm{PATTERN}\; (t_1, \ldots, t_m)</math> for the quantifier,
it will be instantiated only with terms obtained by simultaneously matching
all the terms in the pattern against ground terms in the current context
<math>\Gamma</math>.

Specifically, the matching process produces one or more substitutions
<math>\sigma</math> for the variables in <math>(t_1, \ldots, t_m)</math>
which satisfy the following invariant:
for each <math>i = 1, \ldots, m</math>, <math>\sigma(t_i)</math> is
a ground term and there is a ground term <math>s_i</math> in <math>\Gamma</math>
such that <math>\Gamma \models_T \sigma(t_i) = s_i</math>.
The variables of <math>(x_1:T_1, \ldots, x_n:T_n)</math> that occur
in the pattern are instantiated only with those substitutions
(while any remaining variables are instantiated arbitrarily).

The Skolemized version or the added instances of a context formula may themselves
start with a quantifier.
The same instantiation process is applied to them too, recursively.

Note that the matching mechanism is not limited to syntactic matching
but is modulo the equations asserted in the context.
Because of decidability and/or efficiency limitations, the matching process
is not exhaustive.
CVC4 will typically miss some substitutions that satisfy the invariant above.
As a consequence, it might fail to prove the validity of the query formula
<math>F</math>, which makes CVC4 incomplete for contexts containing
quantified formulas.
It should be noted though that exhaustive matching, which can be achieved
simply by not specifying any patterns, does not yield completeness anyway
since the instantiation of universal variables is still restricted
to just the ground terms in the context,
whereas in general additional ground terms might be needed.



=CVC4's support for the SMT-LIB language=

==SMT-LIB compliance==

Every effort has been made to make CVC4 compliant with the SMT-LIB 2.0
standard (http://smtlib.org/). However, when parsing SMT-LIB input,
certain default settings don't match what is stated in the official
standard. To make CVC4 adhere more strictly to the standard, use the
"--smtlib" command-line option. Even with this setting, CVC4 is
somewhat lenient; some non-conforming input may still be parsed and
processed.

=The CVC4 library interface (API)=
==Using CVC4 in a C++ project==
==Using CVC4 from Java==
==The compatibility interface==

=Upgrading from CVC3 to CVC4=

==Features not supported by CVC4 (yet)==

===Type Correctness Conditions (TCCs)===

Type Correctness Conditions (TCCs), and the checking of such, are not
supported by CVC4 1.0. Thus, a function defined only on integers can be
applied to REAL (as INT is a subtype of REAL), and CVC4 will not complain,
but may produce strange results. For example:

f : INT -> INT;
ASSERT f(1/3) = 0;
ASSERT f(2/3) = 1;
CHECKSAT;
% sat
COUNTEREXAMPLE;
% f : (INT) -> INT = LAMBDA(x1:INT) : 0;

CVC3 can be used to produce TCCs for this input (with the +dump-tcc option).
The TCC can be checked by CVC3 or another solver. (CVC3 can also check
TCCs while solving with +tcc.)

==If you were using the text interfaces of CVC3==

The native language of all solvers in the CVC family, referred to as the
"presentation language," has undergone some revisions for CVC4. The
most notable is that CVC4 does _not_ add counterexample assertions to
the current assertion set after a SAT/INVALID result. For example:

x, y : INT;
ASSERT x = 1 OR x = 2;
ASSERT y = 1 OR y = 2;
ASSERT x /= y;
CHECKSAT;
% sat
QUERY x = 1;
% invalid
QUERY x = 2;
% invalid

Here, CVC4 responds "invalid" to the second and third queries, because
each has a counterexample (x=2 is a counterexample to the first, and
x=1 is a counterexample to the second). However, CVC3 will respond
with "valid" to one of these two, as the first query (the CHECKSAT)
had the side-effect of locking CVC3 into one of the two cases; the
later queries are effectively querying the counterexample that was
found by the first. CVC4 removes this side-effect of the CHECKSAT and
QUERY commands.

CVC4 supports rational literals (of type REAL) in decimal; CVC3 did not
support decimals.

CVC4 does not have support for the IS_INTEGER predicate.

==If you were using the library ("in-memory") interface of CVC3==
===If you were using CVC3 from C===
===If you were using CVC3 from Java===

=Useful command-line options=

==Statistics==

Statistics can be dumped on exit (both normal and abnormal exits) with
the --statistics command line option.

==Time and resource limits==

CVC4 can be made to self-timeout after a given number of milliseconds.
Use the --tlimit command line option to limit the entire run of
CVC4, or use --tlimit-per to limit each individual query separately.
Preprocessing time is not counted by the time limit, so for some large
inputs which require aggressive preprocessing, you may notice that
--tlimit does not work very well. If you suspect this might be the
case, you can use "-vv" (double verbosity) to see what CVC4 is doing.

Time-limited runs are not deterministic; two consecutive runs with the
same time limit might produce different results (i.e., one may time out
and responds with "unknown", while the other completes and provides an
answer). To ensure that results are reproducible, use --rlimit or
--rlimit-per. These options take a "resource count" (presently, based on
the number of SAT conflicts) that limits the search time. A word of
caution, though: there is no guarantee that runs of different versions of
CVC4 or of different builds of CVC4 (e.g., two CVC4 binaries with different
features enabled, or for different architectures) will interpret the resource
count in the same manner.

CVC4 does not presently have a way to limit its memory use; you may opt
to run it from a shell after using "ulimit" to limit the size of the
heap.

=Dumping API calls or preprocessed output=

=Changing the output language=

=Proof support=

CVC4 1.0 has limited support for proofs, and they are disabled by default.
(Run the configure script with --enable-proof to enable proofs). Proofs
are exported in LFSC format and are limited to the propositional backbone
of the discovered proof (theory lemmas are stated without proof in this
release).

=Portfolio solving=

If enabled at configure-time (./configure --with-portfolio), a second
CVC4 binary will be produced ("pcvc4"). This binary has support for
running multiple instances of CVC4 in different threads. Use --threads=N
to specify the number of threads, and use --thread0="options for thread 0"
--thread1="options for thread 1", etc., to specify a configuration for the
threads. Lemmas are *not* shared between the threads by default; to adjust
this, use the --filter-lemma-length=N option to share lemmas of N literals
(or smaller). (Some lemmas are ineligible for sharing because they include
literals that are "local" to one thread.)

Currently, the portfolio **does not work** with quantifiers or with
the theory of inductive datatypes. These limitations will be addressed
in a future release.

=Emacs support=

For a suggestion of editing CVC4 source code with emacs, see the file
contrib/editing-with-emacs. For a CVC language mode (the native input
language for CVC4), see contrib/cvc-mode.el.

User Manual

2012-11-26T04:29:23Z

Tinelli: /* Arithmetic */

This manual includes lots of information about how to use CVC4.

It is a work in-progress.

= What is CVC4? =

CVC4 is the last of a long line of SMT solvers that started with SVC and includes CVC, CVC-Lite and CVC3.
Technically, it is an automated validity checker for a many-sorted (i.e., typed) first-order logic with built-in theories.
The current built-in theories are the theories of:

* equality over free (aka uninterpreted) function and predicate symbols,
* real and integer linear arithmetic (with some support for non-linear arithmetic),
* bit vectors,
* arrays,
* tuples,
* records,
* user-defined inductive data types.

CVC4 checks whether a given formula <math>\phi</math> is valid in the built-in theories under a given set <math>\Gamma</math> of assumptions, a ''context''.
More precisely, it checks whether

<center>
<math>\Gamma\models_T \phi</math>
</center>

that is, whether <math>\phi</math> is a logical consequence in <math>T</math> of the set of formulas <math>\Gamma</math>, where <math>T</math> is the union of CVC4's built-in theories.

Roughly speaking, when <math>\phi</math> is a universal formula and <math>\Gamma</math> is a set of existential formulas (i.e., when <math>\phi</math> and <math>\Gamma</math> contain at most universal, respectively existential, quantifiers), CVC4 is a decision procedure:
it is guaranteed (modulo bugs and memory limits) to return a correct "valid" or "invalid" answer eventually.
In all other cases, CVC4 is deductively sound but incomplete:
it will never say that an invalid formula is valid,
but it may either never return or give up and return "unknown" for some formulas.

Currently, when CVC4 returns "valid" for a query formula <math>\phi</math> under a context <math>\Gamma</math>
it provides no evidence to back its claim.
Future versions will also return a ''proof certificate'',
a formal proof that <math>\Gamma'\models_T \phi</math> for some subset <math>\Gamma'</math> of <math>\Gamma</math>.

When CVC4 returns "invalid" it can return
both a ''counter-example'' to <math>\phi</math>'s validity under the context <math>\Gamma</math> and a ''counter-model''.
Both a counter-example and a counter-model are a set <math>\Delta</math> of additional formulas consistent with <math>\Gamma</math> in <math>T</math>, but entailing the negation of <math>\phi</math>.
Formally:

<center>
<math>\Gamma \cup \Delta \not\models_T \mathit{false}</math>
and
<math>\Gamma \cup \Delta \models_T \lnot \phi</math>.
</center>

The difference is that a counter-model is given as a set of equations providing a concrete assignment of values for the free symbols in <math>\Gamma</math> and <math>\phi</math>
(see the section on [[#CVC4's native input language|CVC4's native input language]] for more details).

=Obtaining and compiling CVC4=

CVC4 is distributed in the following ways:
* [[#Obtaining_binary_packages|Binary packages]]
* [[#Obtaining_source_packages|Source packages]]
* [[#Source_repository|Source repository checkout]]

==Obtaining binary packages==

[http://cvc4.cs.nyu.edu/builds/ Binary packages are available] for CVC4.
Nightly builds:
* [http://cvc4.cs.nyu.edu/builds/debian/unstable Debian] packages
* [http://cvc4.cs.nyu.edu/builds/x86_64-linux-opt/ Optimized] binaries (statically linked)
* [http://cvc4.cs.nyu.edu/builds/x86_64-linux-dbg/ Debug] binaries (statically linked)

==Obtaining source packages==

[http://cvc4.cs.nyu.edu/builds/src/ Sources are available] from the same site as the binaries.

==Source repository==
The [http://cvc4.cs.nyu.edu/builds/src/ CVC4 source repository] is currently hosted by [http://cims.nyu.edu/ CIMS] and requires a CIMS account. Please contact a member of the development team for access. Please see the additional instructions for [[#Building_CVC4 from_a_repository_checkout]] here.

==Building from source==

===Quick-start instructions===
To compile from a source package:
# Install antlr
# Configure cvc4
# Compile cvc4
# Install cvc4 [optional]
cd contrib
./get-antlr-3.4
cd ..
./configure --with-antlr-dir=`pwd`/antlr-3.4 ANTLR=`pwd`/antlr-3.4/bin/antlr3
make
make check [recommended]
make install [optional]

(To build from a repository checkout, see [[#Building_CVC4_from_a_repository_checkout|below]].)

===Common make Options===
* "''make install''" will install into the "--prefix" option you gave to
the configure script (''/usr/local'' by default).
./configure --prefix=~/install_targets/cvc4 ...
make install
* '''You should run "''make check''"''' before installation to ensure that CVC4 has been
built correctly. In particular, GCC version 4.5.1 seems to have a
bug in the optimizer that results in incorrect behavior (and wrong
results) in many builds. This is a known problem for Minisat, and
since Minisat is at the core of CVC4, a problem for CVC4. "''make check''"
easily detects this problem (by showing a number of FAILed test cases).
It is ok if the unit tests aren't run as part of "''make check''", but all
system tests and regression tests should pass without incident.
* To build API documentation, use "''make doc''". Documentation is produced
under ''builds/doc/'' but is not installed by "''make install''".

Examples and tutorials are not installed with "''make install''." See [[#Examples_and_tutorials_are_not_built_or_installed|below]].

For more information about the build system itself (probably not
necessary for casual users), see the [[#Appendix:_Build_architecture|Appendix]] at the bottom of this
file.

===Common configure Options===
*'''--prefix=PREFIX''' install architecture-independent files in PREFIX (by default /usr/local)
*'''--with-build={production,debug,default,competition}'''
*'''--with-antlr-dir=PATH'''
*'''--with-cln'''/'''--with-gmp''' selects the numbers package to use by default ([[#Optional requirements]])
*'''--enable-static-binary''' build a fully statically-linked binary. (This is recommended for Mac OS X users that want to be able to use gdb.)
*'''ANTLR=PATH''' location of the antlr3 script
*'''--with-boost=DIR''' installation location of the boost libraries (most users will not need this)

See '''./configure --help''' for more.

===Build dependencies===

The following tools and libraries are required to run CVC4. Versions
given are minimum versions; more recent versions should be compatible.

*'''GNU C and C++''' (gcc and g++), reasonably recent versions
*'''GNU Make'''
*'''GNU Bash'''
*'''GMP v4.2''' (GNU Multi-Precision arithmetic library)
*'''libantlr3c v3.2 or v3.4''' (ANTLR parser generator C support library)
*'''The Boost C++ base libraries'''
*'''MacPorts''' [highly recommended if on a Mac; see [[#MacPorts]]]

The hardest to obtain and install is the libantlr3c requirement, and
is explained [[#Installing libantlr3c: ANTLR parser generator C support library|next]].

If "make" is non-GNU on your system, make sure to invoke "gmake" (or
whatever GNU Make is installed as). If your usual shell is not Bash,
the configure script should auto-correct this. If it does not, you'll
see strange shell syntax errors, and you may need to explicitly set
SHELL or CONFIG_SHELL to the location of bash on your system.

====Installing libantlr3c: ANTLR parser generator C support library====

For libantlr3c, you can use the convenience script in
''contrib/get-antlr-3.4'' in the source distribution---this will download, patch, compile and install
libantlr3c into your cvc4 directory as ''cvc4/antlr-3.4/''.
cd contrib
./get-antlr-3.4

CVC4 must be configured with the antlr library installation directory, '''--with-antlr-dir''', and an antlr executable script file, '''ANTLR'''. If libantlr3c was installed via get-antlr-3.4, the following configure line should suffice for CVC44
./configure --with-antlr-dir=`pwd`/antlr-3.4 ANTLR=`pwd`/antlr-3.4/bin/antlr3

For 64 bit machines, libantlr3c needs to be configured with 64 bit explicitly
./configure --enable-64bit ...
The get-antlr-3.4 script makes a guess at whether the machine is 64 bit and adds the appropriate flag.
To force the script to compile 32 bit:
MACHINE_TYPE="x86" ./get-antlr3.4
To force the script to compile 64 bit:
MACHINE_TYPE="x86_64" ./get-antlr3.4

For a longer discussion, instructions for manual installation, and more in depth troubleshooting, see [[Developer's Guide#ANTLR3]].

====MacPorts====

On a Mac, it is '''highly''' recommended that you use MacPorts (see
http://www.macports.org/). Doing so is easy. Then, simply run the
script ''contrib/mac-build'', which installs a few ports from the MacPorts
repository, then compiles and installs antlr3c using the ''get-antlr-3.4''
script. The mac-build script should set you up
with all requirements, and will tell you how to configure CVC4 when it
completes successfully.

====Installing the Boost C++ base libraries====

A Boost package is available on most Linux distributions; check yours
for a package named something like libboost-dev or boost-devel. There
are a number of additional Boost packages in some distributions, but
this "basic" one should be sufficient for building CVC4.

Should you want to install Boost manually, or to learn more about the
Boost project, please visit http://www.boost.org/.

===Optional requirements===

None of these is required, but can improve CVC4 as described below:

*'''Optional: SWIG 2.0.x''' (Simplified Wrapper and Interface Generator)
*'''Optional: CLN v1.3 or newer''' (Class Library for Numbers)
*'''Optional: CUDD v2.4.2 or newer''' (Colorado University Decision Diagram package)
*'''Optional: GNU Readline library''' (for an improved interactive experience)
*'''Optional: The Boost C++ threading library''' (libboost_thread)
*'''Optional: CxxTest unit testing framework'''

SWIG is necessary to build the Java API (and of course a JDK is
necessary, too). SWIG 1.x won't work; you'll need 2.0, and the more
recent the better. On Mac, we've seen SWIG segfault when generating
CVC4 language bindings; version 2.0.8 or higher is recommended to
avoid this. See [[#Language_bindings|Language bindings]] below for build instructions.

CLN is an alternative multiprecision arithmetic package that can offer
better performance and memory footprint than GMP. CLN is covered by
the GNU General Public License, version 3; so if you choose to use
CVC4 with CLN support, you are licensing CVC4 under that same license.
(Usually CVC4's license is more permissive than GPL is; see the file
COPYING in the CVC4 source distribution for details.) Please visit
http://www.ginac.de/CLN/ for more details about CLN.

CUDD is a decision diagram package that changes the behavior of the
CVC4 arithmetic solver in some cases; it may or may not improve the
arithmetic solver's performance. See [[#Building_with_CUDD_(optional)|below]] for instructions on
obtaining and building CUDD.

The GNU Readline library is optionally used to provide command
editing, tab completion, and history functionality at the CVC prompt
(when running in interactive mode). Check your distribution for a
package named "libreadline-dev" or "readline-devel" or similar.

The Boost C++ threading library (often packaged independently of the
Boost base library) is needed to run CVC4 in "portfolio"
(multithreaded) mode. Check your distribution for a package named
"libboost-thread-dev" or similar.

CxxTest is necessary to run CVC4's unit tests (included with the
distribution). Running these is not really required for users of
CVC4; "make check" will skip unit tests if CxxTest isn't available,
and go on to run the extensive system- and regression-tests in the
source tree. However, if you're interested, you can download CxxTest
at http://cxxtest.com/ .

====Building with CUDD (optional)====

CUDD, if desired, must be installed delicately. The CVC4 configure
script attempts to auto-detect the locations and names of CUDD headers
and libraries the way that the Fedora RPMs install them, the way that
our NYU-provided Debian packages install them, and the way they exist
when you download and build the CUDD sources directly. If you install
from Fedora RPMs or our Debian packages, the process should be
completely automatic, since the libraries and headers are installed in
a standard location. If you download the sources yourself, you need
to build them in a special way. Fortunately, the
"contrib/build-cudd-2.4.2-with-libtool.sh" script in the CVC4 source
tree does exactly what you need: it patches the CUDD makefiles to use
libtool, builds the libtool libraries, then reverses the patch to
leave the makefiles as they were. Once you run this script on an
unpacked CUDD 2.4.2 source distribution, then CVC4's configure script
should pick up the libraries if you provide
--with-cudd-dir=/PATH/TO/CUDD/SOURCES.

If you want to force linking to CUDD, provide --with-cudd to the
configure script; this makes it a hard requirement rather than an
optional add-on.

The NYU-provided Debian packaging of CUDD 2.4.2 and CUDD 2.5.0 are
here (along with the CVC4 Debian packages):

deb http://cvc4.cs.nyu.edu/debian/ unstable/

On Debian (and Debian-derived distributions like Ubuntu), you only
need to drop that one line in your /etc/apt/sources.list file, then install with your favorite package manager.

The Debian source package "cudd", available from the same repository,
includes a diff of all changes made to cudd makefiles.

===Language bindings===

There are several options available for using CVC4 from the API.

First, CVC4 offers a complete and flexible API for manipulating
expressions, maintaining a stack of assertions, and checking
satisfiability, and related things. The C++ libraries (libcvc4.so and
libcvc4parser.so) and required headers are installed normally via a
"make install". This API is also available from Java (via CVC4.jar
and libcvc4jni.so) by configuring with --enable-language-bindings=java.
You'll also need SWIG 2.0 installed (and you might need to help
configure find it if you installed it in a nonstandard place with
--with-swig-dir=/path/to/swig/installation). You may also need to
give the configure script the path to your Java headers (in
particular, jni.h). You might do so with (for example):

./configure --enable-language-bindings=java \
JAVA_CPPFLAGS=-I/usr/lib/jvm/java-6-openjdk-amd64/include

There is also a "C++ compatibility API" (''#include <cvc4/cvc3_compat.h>''
and link against libcvc4compat.so) that attempts to maintain
source-level backwards-compatibility with the CVC3 C++ API. The
compatibility library is built by default, and
''--enable-language-bindings=java'' enables the Java compatibility library
(CVC4compat.jar and libcvc4compatjni.so).
''--enable-language-bindings=c'' enables the C compatibility library
(''#include <cvc4/bindings/compat/c/c_interface.h>'' and link against
libcvc4bindings_c_compat.so), and if you want both C and Java
bindings, use ''--enable-language-bindings=c,java''. These compatibility
language bindings do NOT require SWIG.

The ''examples/'' directory in the source distribution includes some basic examples (the "simple vc"
and "simple vc compat" family of examples) of all these interfaces.

In principle, since we use SWIG to generate the native Java API, we
could support other languages as well. However, using CVC4 from other
languages is not supported, nor expected to work, at this time. If
you're interested in helping to develop, maintain, and test a language
binding, please contact us via the users' mailing list at
cvc-users@cs.nyu.edu.

===Building CVC4 from a repository checkout===

The following tools and libraries are additionally required to build
CVC4 from from a repository checkout rather than from a prepared
source tarball.

*'''Automake v1.11'''
*'''Autoconf v2.61'''
*'''Libtool v2.2'''
*'''ANTLR3 v3.2 or v3.4'''
*'''Java Development Kit''' ([http://www.antlr.org/wiki/pages/viewpage.action?pageId=728 required for ANTLR3])

First, use "''./autogen.sh''" to create the configure script. Then
proceed as normal for any distribution tarball. The parsers are
pre-generated for the tarballs, but don't exist in the repository; hence the extra ANTLR3 and JDK requirements to
generate the source code for the parsers, when building from the
repository.

===Examples and tutorials are not built or installed===

Examples are not built by "''make''" or "''make install''". See
''examples/README'' in the source distribution for information on what to find in the ''examples/''
directory, as well as information about building and installing them.

===Appendix: Build architecture===

The build system is generated by automake, libtool, and autoconf. It
is somewhat nonstandard, though, which (for one thing) requires that
GNU Make be used. If you ./configure in the top-level source
directory, the objects will actually all appear in
builds/${arch}/${build_id}. This is to allow multiple, separate
builds in the same place (e.g., an assertions-enabled debugging build
alongside a production build), without changing directories at the
shell. The "current" build is maintained, and you can still use
(e.g.) "make -C src/main" to rebuild objects in just one subdirectory.

You can also create your own build directory inside or outside of the
source tree and configure from there. All objects will then be built
in that directory, and you'll ultimately find the "cvc4" binary in
src/main/, and the libraries under src/ and src/parser/.

=Using the CVC4 binary=

The CVC4 driver binary ("cvc4"), once installed, can be executed directly to enter into interactive mode:

$ cvc4
cvc4 1.0 assertions:off
CVC4>

You can then enter commands into CVC4 interactively:

CVC4> OPTION "incremental";
CVC4> OPTION "produce-models";
CVC4> TRANSFORM 25*25;
625
CVC4> x, y : INT;
CVC4> QUERY x = y;
invalid
CVC4> COUNTERMODEL;
x : INT = -1;
y : INT = 0;
CVC4> ASSERT x >= 0;
CVC4> QUERY x = y;
invalid
CVC4> COUNTERMODEL;
x : INT = 0;
y : INT = 1;
CVC4>

The above example shows two useful options, ''incremental'' and ''produce-models.''

* The ''incremental'' option allows you to issue multiple QUERY (or CHECKSAT) commands, and allows the use of the PUSH and POP commands. Without this option, CVC4 optimizes itself for a single QUERY or CHECKSAT command (though you may issue any number of ASSERT commands). The ''incremental'' option may also be given by passing the ''-i'' command line option to CVC4.
* The ''produce-models'' option allows you to query the model (here, with the COUNTERMODEL command) after an "invalid" QUERY (or "satisfiable" CHECK-SAT). Without it, CVC4 doesn't do the bookkeeping necessary to support model generation. The ''produce-models'' option may also be given by passing the ''-m'' command line option to CVC4.

So, if you invoke CVC4 with ''-im'', you don't need to pass those options at all:

$ cvc4 -im
cvc4 1.0 assertions:off
CVC4> x, y : INT;
CVC4> QUERY x = y;
invalid
CVC4> COUNTERMODEL;
x : INT = -1;
y : INT = 0;
CVC4> ASSERT x >= 0;
CVC4> QUERY x = y;
invalid
CVC4> COUNTERMODEL;
x : INT = 0;
y : INT = 1;
CVC4>

By default, CVC4 operates in [[#CVC4's native input language|CVC-language mode]]. If you enter something that looks like SMT-LIB, it will suggest that you use the "''--lang smt''" command-line option for SMT-LIB mode:

CVC4> (declare-fun x () Int)
Parse Error: <shell>:1.7: In CVC4 presentation language mode, but SMT-LIB format detected. Use --lang smt for SMT-LIB support.
CVC4>

==Verbosity==

CVC4 has various levels of verbosity. By default, CVC4 is pretty quiet, only reporting serious warnings and notices. If you're curious about what it's doing, you can pass CVC4 the ''-v'' option:

$ cvc4 -v file.smt2
Invoking: (set-logic AUFLIRA)
Invoking: (set-info :smt-lib-version 2.000000)
Invoking: (set-info :category "crafted")
Invoking: (set-info :status unsat)
Invoking: (declare-fun x () Real)
''etc...''

For even more verbosity, you can pass CVC4 an ''additional'' ''-v'':

$ cvc4 -vv file.smt2
Invoking: (set-logic AUFLIRA)
Invoking: (set-info :smt-lib-version 2.000000)
Invoking: (set-info :category "crafted")
Invoking: (set-info :status unsat)
Invoking: (declare-fun x () Real)
''etc...''
expanding definitions...
constraining subtypes...
applying substitutions...
simplifying assertions...
doing static learning...
''etc...''

Internally, verbosity is just an integer value. It starts at 0, and with every ''-v'' on the command line it is incremented; with every ''-q'', decremented. It can also be set directly. From CVC language:

CVC4> OPTION "verbosity" 2;

Or from SMT-LIB language:

CVC4> (set-option :verbosity 2)

==Getting statistics==

Statistics can be dumped on exit (both normal and abnormal exits) with the ''--statistics'' command line option.

$ cvc4 --statistics foo.smt2
sat
sat::decisions, 0
sat::propagations, 3
sat::starts, 1
theory::uf::TheoryUF::functionTermsCount, 2
theory::uf::TheoryUF::mergesCount, 2
theory::uf::TheoryUF::termsCount, 6
theory<THEORY_UF>::propagations, 1
driver::filename, foo.smt2
driver::sat/unsat, sat
driver::totalTime, 0.02015373
''[many others]''

Many statistics name-value pairs follow, one comma-separated pair per line.

==Exit status==

The exit status of CVC4 depends on the ''last'' QUERY or CHECK-SAT. If you wish to call CVC4 from a program (e.g., a shell script) and care only about the satisfiability or validity of a single formula, you can pass the ''-q'' option (as described [[#Verbosity|above, under verbosity]]) and check the exit code. With ''-q'', CVC4 should not produce any output unless it encounters a fatal error.

QUERY asks a validity question, and CHECK-SAT a satisfiability question, and these are dual problems; hence the terminology is different, but really "sat" and "invalid" are the same internally, as are "unsat" and "valid":

<table border="1">
<tr><th>Solver's last result</th><th>Exit code</th><th>Notes</th></tr>
<tr><td>'''sat''' or '''invalid'''</td><td>10</td></tr>
<tr><td>'''unsat''' or '''valid'''</td><td>20</td></tr>
<tr><td>'''unknown'''</td><td>0</td><td>could be for any reason: time limit exceeded, no memory, incompleteness..</td></tr>
<tr><td>''no result''</td><td>0</td><td>no query or check-sat command issued</td></tr>
<tr><td>parse errors</td><td>0 (in interactive mode)<br/>1 (otherwise)</td><td>see below</td></tr>
<tr><td>other errors</td><td>1 (usually)</td><td>see below</td></tr>
</table>

Most "normal errors" return a 1 as the exit code, but out of memory conditions, and others, can produce different exit codes. In interactive mode, parse errors are ignored and the next line read; so in interactive mode, you may see an exit code of 0 even in the presence of such an error.

In SMT-LIB mode, an SMT-LIB command script that sets its status via "set-info :status" also affects the exit code. So, for instance, the following SMT-LIB script returns an exit code of 10 even though it contains no "check-sat" command:

(set-logic QF_UF)
(set-info :status sat)
(exit)

Without the "set-info," it would have returned an exit code of 0.

=CVC4's native input language=

The native input language consists of a sequence of symbol declarations and commands, each followed by a semicolon (<code>;</code>).

Any text after the first occurrence of a percent character and to the end of the current line is a comment:

%%% This is a native language comment

== Type System ==

CVC4's type system includes a set of built-in types which can be expanded with additional user-defined types.

The type system consists of ''first-order'' types, ''subtypes'' of first-order types, and ''higher-order'' types, all of which are interpreted as sets.
For convenience, we will sometimes identify below the interpretation of a type with the type itself.

First-order types consist of basic types and structured types. The basic types are <math>\mathrm{BOOLEAN}</math>, <math>\mathrm{REAL}</math>, <math>\mathrm{BITVECTOR}(n)</math> for all <math>n > 0</math>, as well as user-defined basic types (also called uninterpreted types).
The structured types are array, tuple, record types, and ML-style user-defined (inductive) datatypes.

'''Note:''' Currently, subtypes consist only of the built-in subtype <math>\mathrm{INT}</math> of <math>\mathrm{REAL}</math>.

Support for CVC3-style user-defined subtypes will be added in a later release.

Function types are the only higher-order types.
More precisely, they are just second-order types
since function symbols in CVC4, both built-in and user-defined, can take as argument or return only values of
a first-order type.

=== Basic Types ===

==== The BOOLEAN Type ====

The <math>\mathrm{BOOLEAN}</math> type is interpreted as the two-element set of Boolean values
<math>\{\mathrm{TRUE},\; \mathrm{FALSE}\}</math>.

'''Note:''' CVC4's treatment of this type differs from CVC3's where <math>\mathrm{BOOLEAN}</math> is used only as the type of formulas, but not as value type. CVC3 follows the two-tiered structure of classical first-order logic
which distinguishes between formulas and terms, and allows terms to occur in formulas but not vice versa (with the exception of the IF-THEN-ELSE construct).
CVC4 drops the distinction between terms and formulas and defines the latter just as terms of type <math>\mathrm{BOOLEAN}</math>. As such, formulas can occur as subterms of possibly non-Boolean terms.

Example:

[To do]

==== The REAL Type ====

The <math>\mathrm{REAL}</math> type is interpreted as the set of real numbers.

Note that these are the (infinite precision) mathematical reals,
not the floating point numbers.
Support for floating point types is planned for future versions.

x, y : REAL;
QUERY (( x <= y ) AND ( y <= x )) => ( x = y );

==== The INT Type ====

The <math>\mathrm{INT}</math> type is interpreted as the set of integer numbers
and is considered as a subtype of <math>\mathrm{REAL}</math>.
The latter means in particular that it is possible to mix integer and real terms
in expressions without the need of an explicit ''upcasting'' operator.

Note that these are the (infinite precision) mathematical integers,
not the finite precision machine integers used in most programming languages.
The latter are models by [[ #Bitvectors | bit vector ]] types.

x, y : INT;
QUERY ((2 * x + 4 * y <= 1) AND ( y >= x)) => (x <= 0);
z : REAL;
QUERY (2 * x + z <= 3.5) AND (z >= 1);

==== Bit Vector Types ====

For every positive integer <math>n</math>, the type <math>\mathrm{BITVECTOR}(n)</math> is interpreted as the set of all bit vectors of size <math>n</math>.
A rich set of bit vector operators is supported.

==== User-defined Basic Types ====

Users can define new basic types
(often referred to as ''uninterpreted'' types in the SMT literature).
Each such type is interpreted as a set of unspecified cardinality
but disjoint from any other type.

User-defined basic types are created by declarations like the following:

% User declarations of basic types:

MyBrandNewType: TYPE;

Apples, Oranges: TYPE;

=== Structured Types ===

CVC4's structured types are divided in the following families.

==== Array Types ====

Array types are created by the mixfix type constructors <math>\mathrm{ARRAY}\ \_\ \mathrm{OF}\ \_</math>
whose arguments can be instantiated by any value type.

I : TYPE;

%% Array types:

% Arrays with indices from I and values from REAL
Array1: TYPE = ARRAY I OF REAL;

% Arrays with integer indices and array values
Array2: TYPE = ARRAY INT OF (ARRAY INT OF REAL);

% Arrays with integer pair indices and integer values
IntMatrix: TYPE = ARRAY [INT, INT] OF INT;

An array type of the form <math>\mathrm{ARRAY}\ T_1\ \mathrm{OF}\ T_2</math> is interpreted
as the set of all total maps from <math>T_1</math> to <math>T_2</math>.
The main difference with the function type <math>T_1 \to T_2</math> is that arrays,
contrary to functions, are first-class objects of the language, that is, values of an array
type can be arguments or results of functions.
Furthermore, array types come equipped with an update operation.

==== Tuple Types ====

Tuple types are created by the mixfix type constructors

<center>
<math>
\begin{array}{l} [\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ \ ,\ \_\ ] \\[1ex] \ldots \end{array}
</math>
</center>

whose arguments can be instantiated by any value type.

IntArray: TYPE = ARRAY INT OF INT;

% Tuple type declarations

RealPair: TYPE = [REAL, REAL]

MyTuple: TYPE = [ REAL, IntArray, [INT, INT] ];

A tuple type of the form <math>[T_1, \ldots, T_n]</math> is interpreted
as the Cartesian product <math>T_1 \times \cdots \times T_n</math>.

Note that while the types <math>(T_1, \ldots, T_n) \to T</math> and
<math>[T_1 \times \cdots \times T_n] \to T</math> are semantically equivalent,
they are operationally different in CVC4.
The first is the type of functions that take <math>n</math> arguments
of respective type <math>T_1</math>, <math>\ldots</math>, <math>T_n</math>,
while the second is the type of functions that take one argument of an <math>n</math>-tuple type.

==== Record Types ====

Similar to, but more general than tuple types, record types are created by type constructors of the form

<center>
<math>
[\#\ l_1: \_\ ,\ \ldots\ ,\ l_n: \_\ \#]
</math>
</center>

where <math>n > 0</math>, <math>l_1,\ldots, l_n</math> are field labels,
and the arguments can be instantiated with any first-order types.

MyType: TYPE;

% Record declaration

RecordType: TYPE = [# id: REAL, age: INT, info: MyType #];

The order of the fields in a record type is meaningful:
permuting the field names gives a different type.

Note that record types are non-recursive.
For instance, it is not possible to declare a record type called <code>Person</code> containing
a field of type <code>Person</code>.
Recursive types are provided in CVC4 by the more general inductive data types.
(As a matter of fact, both record and tuple types are implemented internally as inductive data types.)

==== Inductive Data Types ====

Inductive data types in CVC4 are similar to inductive data types of functional languages.
They can be parametric or not.

===== Non-Parametric Data Types =====

Non-parametric data types are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1 & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2 & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types, including any <math>A_i</math>.
Such declarations define the data types <math>A_1, \ldots, A_n</math>.
For each data type <math>A_i</math> they introduce:

* constructor symbols <math>cons</math> of type <math>(T_1, \ldots, T_k) \to \mathit{type\_name}_i</math>,
* selector symbols <math>\mathit{sel}_j</math> of type <math>\mathit{type\_name}_i \to T_j</math>, and
* tester symbols <math>\mathit{is\_cons}</math> of type <math>\mathit{type\_name}_i \to \mathrm{BOOLEAN}</math>.

Note that permitting more than one data type to be defined in the same declarations allows
the definition of mutually recursive types.

% simple enumeration type

% implicitly defined are the testers: is_red, is_yellow and is_blue
% (similarly for the other data types)

DATATYPE
PrimaryColor = red | yellow | blue
END;

% infinite set of pairwise distinct values ..., v(-1), v(0), v(1), ...

DATATYPE
Id = v (id: INT)
END;

% ML-style integer lists

DATATYPE
IntList = nil | ins (head: INT, tail: IntList)
END;

% AST for lamba calculus

DATATYPE
Term = var (index: INT)
| apply (arg_1: Term, arg_2: Term)
| lambda (arg: INT, body: Term)
END;

% Trees

DATATYPE
Tree = tree (value: REAL, children: TreeList),
TreeList = nil_tl
| ins_tl (first_t1: Tree, rest_t1: TreeList)
END;

Constructor, selector and tester symbols defined for a data type have global scope.
So, for example, it is not possible for two different data types to use
the same name for a constructor.

An inductive data type is interpreted as a term algebra constructed by the constructor symbols
over some sets of generators.
For example, the type <code>IntList</code> defined above is interpreted as the set
of all terms constructed with <code>nil</code> and <code>ins</code> over the integers.

===== Parametric Data Types =====

Parametric data types are infinite families of (non-parametric) data types
with each family parametrized by one or more type variables.
They are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE}\ [X_1, \ldots, X_p] \\
\begin{array}{ccc}
\ \ A_1 & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2 & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
<math>X_1, \ldots, X_p</math> are type variables,
each <math>A_i</math> is a type name parametrized by some of the variables <math>X_1, \ldots, X_p</math>
and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types,
possibly parametrized by <math>X_1, \ldots, X_p</math>, including any <math>A_i</math>.

% Parametric pairs
DATATYPE [X, Y]
Pair[X, Y] = pair (first: X, second: Y)
END;

% Parametric lists

DATATYPE [X]
List[X] = nil | cons (head: X, tail: List[X])
END;

% Parametric trees using the list type above

DATATYPE [X]
Tree[X] = node (value: X, children: List[Tree[X]]),
END;

The declarations above define infinitely many types of the form
Pair[S,T], List[T] and Tree[T] where S and T are first-order types.
Note that the identifier <code>List</code> above, for example, by itself does not denote a type.
In contrast, the terms <code>List[Real]</code>, <code>List[List[Real]]</code>, <code>List[Tree[INT]]</code>,
and so on do.

===== Restriction to Inductive Types =====

By adopting a term algebra semantics, CVC4 allows only ''inductive'' data types,
that is, data types whose values are essentially (labeled, ordered) finite trees.
Infinite structures such as streams or even finite but cyclic ones
such as circular lists are then excluded.
For instance, none of the following declarations define inductive data types,
and are rejected by CVC4:

DATATYPE
IntStream = s (first:INT, rest: IntStream)
END;

DATATYPE
RationalTree = node1 (child: RationalTree)
| node2 (left_child: RationalTree, right_child:RationalTree)
END;

DATATYPE
T1 = c1 (s1: T2),
T2 = c2 (s2: T1)
END;

In concrete, a declaration of <math>n \geq 1</math> datatypes <math>T_1, \ldots, T_n</math> will be rejected if for any one of the types <math>T_1, \ldots, T_n</math>, it is impossible to build a finite term of that type using only the constructors of <math>T_1, \ldots, T_n</math> and free constants of type other than <math>T_1, \ldots, T_n</math>.

Inductive data types are the only types where the user also chooses names for the built-in operations to:

* construct a value of the type (with the constructors),
* extract components from a value (with the selectors), or
* check if a value was constructed with a certain constructor or not (with the testers).

For all the other types, CVC4 provides predefined names for the built-in operations on the type.

=== Function Types ===

Function (<math>\to</math>) types are created by the mixfix type constructors
<center>
<math>
\begin{array}{l}
\_ \to \_ \\[1ex] (\ \_\ ,\ \_\ ) \to \_
\\[1ex] (\ \_\ ,\ \_\ ,\ \_\ ) \to \_
\\[1ex] \ldots
\end{array}
</math>
</center>
whose arguments can be instantiated by any first-order type.

% Function type declarations

UnaryFunType: TYPE = INT -> REAL;

BinaryFunType: TYPE = (REAL, REAL) -> ARRAY REAL OF REAL;

TernaryFunType: TYPE = (REAL, BITVECTOR(4), INT) -> BOOLEAN;

A function type of the form <math>(T_1, \ldots, T_n) \to T</math> with <math>n > 0</math> is interpreted as the set of all ''total'' functions from the Cartesian product <math>T_1 \times \cdots \times T_n</math> to <math>T</math>.

The example above also shows how to introduce type names.
A name like <code>UnaryFunType</code> above is just an abbreviation for the type <math>\mathrm{INT} \to \mathrm{REAL}</math> and can be used interchangeably with it.

In general, any type defined by a type expression <code>E</code> can be given a name with the declaration:

name : TYPE = E;

=== Type Checking ===

In CVC4, formulas and terms are statically typed at the level of types
(as opposed to subtypes) according to the usual rules of first-order many-sorted logic,
with the main difference that formulas are just terms of type <math>BOOLEAN</math>:

* each variable has one associated first-order type,
* each constant symbol has one or more associated first-order types,
* each function symbol has one or more associated function types,
* the type of a term consisting just of a variable is the type associated to that variable,
* the type of a term consisting just of a constant symbol is the type associated to that constant symbol,
* the term obtained by applying a function symbol <math>f</math> to the terms <math>t_1, \ldots, t_n</math> is <math>T</math> if <math>f</math> has type <math>(T_1, \ldots, T_n) \to T</math> and each <math>t_i</math> has type <math>T_i</math>.

Attempting to enter an ill-typed term will result in an error.

Another significant difference with standard many-sorted logic is that
some built-in symbols are parametrically polymorphic.
For instance, the function symbol for extracting the element of any array has
type <math>(\mathit{ARRAY}\ T_1\ \mathit{OF}\ T_2,\; T_1) \to T_2</math>
for all first-order types <math>T_1, T_2</math>.

==== Type Ascription ====

By the type inference rules above some terms might have more than one type.
This can happen with terms built with polymorphic data type constructors
that have more than one return type for the same input type.
In that case, a type ascription operator (<code>::</code>) must be applied
to the constructor to specify the intended return type.

DATATYPE [X]
List[X] = nil | cons (head: X, tail: List[X])
END;

ASSERT y = cons(1, nil::List[REAL]);

DATATYPE [X, Y]
Union[X, Y] = left(val_l: X) | right(val_r: Y)
END;

ASSERT y = left::Union[BOOLEAN, REAL](TRUE);

The constant symbol <math>\mathrm{nil}</math> declared above has infinitely many types
(<math>\mathrm{List}[\mathrm{REAL}]</math>, <math>\mathrm{List}[\mathrm{BOOLEAN}]</math>,
<math>\mathrm{List}[[\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{List}[\mathrm{List}[\mathrm{REAL}]]</math>, ...)
CVC4's type checker requires the user to indicate explicitly the type
of each occurrence of <code>nil</code> in a term.
Similarly,
the injection operator <code>left</code> has infinitely many return types
for the same input type, for instance:
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{REAL}]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, [\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{List}[\mathrm{REAL}]]</math>,
and so on.
Applications of <code>left</code> need to specify the intended returned typed, as shown above.

== Terms and Formulas ==

In addition to type expressions, CVC4 has expressions for terms and for formulas
(i.e., terms of type <math>\mathrm{BOOLEAN}</math>).
By and large, these are standard first-order terms built out of typed variables,
predefined theory-specific operators, free (i.e., user-defined) function symbols,
and quantifiers.
Extensions include an if-then-else operator, lambda abstractions, and local symbol
declarations, as illustrated below.
Note that these extensions still keep CVC4's language first-order.
In particular, lambda abstractions are restricted to take and return only terms of
a first-order type.
Similarly, variables can only be of a first-order type.

A number of built-in function symbols (for instance, the arithmetic ones) are used
as infix operators. All user-defined symbols are used as prefix ones.

User-defined, i.e., free, function symbols include ''constant symbols'' and
''predicate symbols'', respectively nullary function symbols and function symbols
with a <math>\mathrm{BOOLEAN}</math> return type.
These symbols are introduced with global declarations of the form
<math> f_1, \ldots, f_m: T;</math>
where <math>m > 0</math>, <math>f_i</math> are the names of the symbols and
<math>T</math> is their type:

% integer constants

a, b, c: INT;

% real constants

x, y, z: REAL;

% unary function

f1: REAL -> REAL;

% binary function

f2: (REAL, INT) -> REAL;

% unary function with a tuple argument

f3: [INT, REAL] -> BOOLEAN;

% binary predicate

p: (INT, REAL) -> BOOLEAN;

% Propositional "variables"

P, Q; BOOLEAN;

Like type declarations, function symbol declarations like the above have global scope
and must be unique.
In other words, it is not possible to declare a function symbol globally more than once
in the same lexical scope.
This entails among other things that globally-defined free symbols cannot be overloaded
with different types and that theory symbols cannot be redeclared globally as free symbols.

=== Global symbol definitions ===

As with types, a function symbol can be defined as the name of another term
of the corresponding type.
With constant symbols, this is done with a declaration of the form <math>f:T = t;</math> :

c: INT;

i: INT = 5 + 3*c; % i is effectively a shorthand for 5 + 3*c

j: REAL = 3/4;

t: [REAL, INT] = (2/3, -4);

r: [# key: INT, value: REAL #] = (# key := 4, value := (c + 1)/2 #);

f: BOOLEAN = FORALL (x:INT): x <= 0 OR x > c ;

A restriction on constants of type <math>\mathit{BOOLEAN}</math> is that their value
can only be a closed formula, that is, a formula with no free variables.

A term and its name can be used interchangeably in later expressions.
Named terms are often useful for shared subterms (terms used several times in different places)
since their use can make the input exponentially more concise.
Named terms are processed very efficiently by CVC4.
It is much more efficient to associate a complex term with a name directly rather than
to declare a constant and later assert that it is equal to the same term.
This point is explained in more detail later in section [[Commands | Commands]].

More generally, in CVC4 one can associate a term to function symbols of any arity.
For non-constant function symbols this is done with a declaration of the form

<center>
<math>f:(T_1, \ldots, T_n) \to T = \mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t\;;</math>
</center>

where <math>t</math> is any term of type <math>T</math> with free variables
in <math>\{x_1, \ldots, x_n\}</math>.
The lambda binder has the usual semantics and conforms to the usual lexical scoping rules:
within the term <math>t</math> the declaration of the symbols <math>x_1, \ldots, x_n</math>
as local variables of respective type <math>T_1, \ldots, T_n</math> hides any previous
declarations of those symbols that are in scope.

As a general shorthand, when <math>k</math> consecutive types
<math>T_i, \ldots, T_{i+k-1}</math> in the lambda expression
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t</math> are identical, the syntax
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x_i,\ldots, x_{i+k-1}:T_i,\ldots, x:T_n): t</math>
can also be used.

% Global declaration of x as a unary function symbol

x: REAL -> REAL;

% Local declarations of x as variable (hiding the global one)

f: REAL -> REAL = LAMBDA (x: REAL): 2*x + 3;

p: (INT, INT) -> BOOLEAN = LAMBDA (x,i: INT): i*x - 1 > 0;

g: (REAL, INT) -> [REAL, INT] = LAMBDA (x: REAL, i:INT): (x + 1, i - 3);

Note that lambda definitions are not recursive:
the symbol being defined cannot occur in the body of the lambda term.
They should be understood as macros.
For instance, any occurrence of the term <math>f(t)</math>
where <math>f</math> is as defined above will be treated
as if it was the term <math>(2*t + 3)</math>.

=== Local symbol definitions ===

Constant and function symbols can also be declared locally anywhere within a term
by means of a let binder.
This is done with a declaration of the form

<center>
<math>
\mathrm{LET}\ f = t \ \mathrm{IN}\ t' ;
</math>
</center>

where <math>t</math> is a term with no free variables, possibly a lambda term.
Let binders can be nested arbitrarily and follow the usual lexical scoping rules.
The following general form
<center>
<math>
\mathrm{LET}\ f_1 = t_1, f_2 = t_2, \ldots, f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>
can be use above can used as a shorthand for
<center>
<math>
\mathrm{LET}\ f_1 = t_1\ \mathrm{IN}\
\mathrm{LET}\ f_2 = t_2\ \mathrm{IN}\
\ldots \
\mathrm{LET}\ f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>

t: REAL =
LET x1 = 42,
g = LAMBDA(x:INT): x + 1,
x2 = 2*x1 + 7/2
IN
(LET x3 = g(x1) IN x3 + x2) / x1;

Note that the same symbol = is used, unambiguously, in the syntax of global declarations,
let declarations, and as a predicate symbol.

'''Note:'''
A <math>\mathrm{LET}</math> term with a multiple symbols defines them sequentially.
A parallel version of the <math>\mathrm{LET}</math> construct will be introduced in a later version.

== Built-in theories and their symbols ==

In addition to user-defined symbols, CVC4 terms can use a number of predefined symbols:
the logical symbols, such as <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, etc.,
as well as theory symbols, function symbols belonging to one of the built-in theories.
They are described next, with the theory symbols grouped by theory.

=== Logical Symbols ===

The logical symbols in CVC4's language include
the equality and disequality predicate symbols, respectively written as = and /=,
the multiarity disequality symbol <math>\mathrm{DISTINCT}</math>,
together with the logical constants <math>\mathrm{TRUE}</math>, <math>\mathrm{FALSE}</math>,
the connectives <math>\mathrm{NOT}</math>, <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, <math>\mathrm{XOR}</math>, <math>\Rightarrow</math>, <math>\Leftrightarrow</math>, and
the first-order quantifiers <math>\mathrm{EXISTS}</math> and <math>\mathrm{FORALL}</math>,
all with the standard many-sorted logic semantics.

The binary connectives have infix syntax and type
<math>(\mathrm{BOOLEAN},\mathrm{BOOLEAN}) \to \mathrm{BOOLEAN}</math>.
The symbols = and /=, which are also infix, are instead parametrically polymorphic,
having type <math>(T,T) \to \mathrm{BOOLEAN}</math>
for every first-order type <math>T</math>.
They are interpreted respectively as the identity relation and its complement.

The DISTINCT symbol is both overloaded and polymorphic.
It has type <math>(T,...,T) \to \mathrm{BOOLEAN}</math>
for every sequence <math>(T,...,T)</math> of length <math>n > 0</math>
and first-order type <math>T</math>.
For each <math>n > 0</math>, it is interpreted as the relation
that holds exactly for tuples of pairwise distinct elements.

The syntax for quantifiers is similar to that of the lambda binder.

Here is an example of a formula built just of these logical symbols and variables:

A, B: TYPE;

q: BOOLEAN = FORALL (x,y: A, i,j,k: B):
i = j AND i /= k => EXISTS (z: A): x /= z OR z /= y;

Binding and scoping of quantified variables follows the same rules as
in let expressions.
In particular, a quantifier will shadow in its scope any constant and function symbols
with the same name as one of the variables it quantifies:

A: TYPE;
i, j: INT;

% The first occurrence of i and of j in f are constant symbols,
% the others are variables.

f: BOOLEAN = i = j AND FORALL (i,j: A): i = j OR i /= j;

Optionally, it is also possible to specify instantiation patterns
for quantified variables.
The general syntax for a quantified formula <math>\psi</math> with patterns is

<center>
<math>
Q\;(x_1:T_1, \ldots, x_k:T_k):\; p_1: \ldots\; p_n:\; \varphi
</math>
</center>

where <math>n \geq 0</math>, <math>Q</math> is
either <math>\mathrm{FORALL}</math> or <math>\mathrm{EXISTS}</math>,
<math>\varphi</math> is a term of type <math>\mathrm{BOOLEAN}</math>,
and each of the <math>p_i</math>'s,
a pattern for the quantifier <math>Q\;(x_1:T_1, \ldots, x_k:T_k)</math>, has the form

<center>
<math>
\mathrm{PATTERN}\; (t_1, \ldots, t_m)
</math>
</center>

where <math>m > 0</math> and <math>t_1, \ldots, t_m</math> are
arbitrary binder-free terms (no lets, no quantifiers).
Those terms can contain (free) variables, typically, but not exclusively,
drawn from <math>x_1, \ldots, x_k</math>.
(Additional variables can occur if <math>\psi</math> occurs in a bigger formula
binding those variables.)

A: TYPE;
b, c: A;
p, q: A -> BOOLEAN;
r: (A, A) -> BOOLEAN;

ASSERT FORALL (x0, x1, x2: A):
PATTERN (r(x0, x1), r(x1, x2)):
(r(x0, x1) AND r(x1, x2)) => r(x0, x2) ;

ASSERT FORALL (x: A):
PATTERN (r(x, b)):
PATTERN (r(x, c)):
p(x) => q(x) ;

ASSERT EXISTS (y: A):
FORALL (x: A):
PATTERN (r(x, y), p(y)):
r(x, y) => q(x) ;

Patterns have no logical meaning:
adding them to a formula does not change its semantics.
Their purpose is purely operational, as explained in
the [[#Instantiation Patterns | Instantiation Patterns]] section.

In addition to these constructs, CVC4 also has a general mixfix conditional operator
of the form

<center>
<math>
\mathrm{IF}\ b\ \mathrm{THEN}\ t\ \mathrm{ELSIF}\ b_1\ \mathrm{THEN}\ t_1\ \ldots\ \mathrm{ELSIF}\ b_n\ \mathrm{THEN}\ t_n\ \mathrm{ELSE}\ t_{n+1}\ \mathrm{ENDIF}
</math>
</center>

with <math>n \geq 0</math> where
<math>b, b_1, \ldots, b_n</math> are terms of type <math>\mathrm{BOOLEAN}</math> and
<math>t, t_1, \ldots, t_n, t_{n+1}</math> are terms of the same first-order type <math>T</math>:

% Conditional term
x, y, z, w: REAL;

t: REAL =
IF x > 0 THEN y
ELSIF x >= 1 THEN z
ELSIF x > 2 THEN w
ELSE 2/3 ENDIF;

=== User-defined Functions and Types ===

The theory of user-defined functions,also know in the SMT literature as
the theory ''Equality over Uninterpreted Functions'', or ''EUF'', is in effect
a family of theories of equality parametrized by the basic types and the free symbols
a user can define during a run of CVC4.

This theory has no built-in symbols (other than the logical ones).
Its types consist of ''all and only'' the user-defined types.
Its function symbols consist of ''all and only'' the user-defined free symbols.

=== Arithmetic ===

The real arithmetic theory has two types:
<math>\mathrm{REAL}</math> and <math>\mathrm{INTEGER}</math>
with the latter a subtype of the first.
Its built-in symbols for the usual arithmetic constants
and operators over the type <math>\mathrm{REAL}</math>, each with the expected type:
all numerals 0, 1, ..., as well as - (both unary and binary), +, *, /, <, >, <=, >=.
Application of the binary symbols are in infix form.
Note that + is only binary, so a terms such as <math>{+}1</math> is ill-formed.

Rational values can be expressed in decimal or fractional format:
e.g., 0.1, 23.243241, 1/2, 3/4, and so on.
A leading 0 is mandatory for decimal numbers smaller than one
(e.g., the syntax .3 is cannot be used as a shorthand for 0.3).
However, a trailing 0 is ''not'' required for decimals that are whole numbers
(e.g., 3. is allowed as a shorthand for 3.0).
The size of the numerals used in the representation of natural and rational numbers
is unbounded; more accurately, bounded only by the amount of available memory.

=== Bit vectors ===

=== Arrays ===

The theory of arrays is a parametric theory of (total) unary maps.
It comes equipped with mixfix polymorphic selection and update operators, respectively
<center>
<math>\_[\_]</math> and <math>\_\ \mathrm{WITH}\ [\_]\ := \_</math> .
</center>
The semantics of these operators is the expected one:
for all first-order types <math>T_1</math> and <math>T_2</math>,
if <math>a</math> is of type <math>\mathrm{ARRAY}\ T_1 \mathrm{OF}\ T_2</math>,
<math>i</math> is of type <math>T_1</math>, and
<math>v</math> is of type <math>T_2</math>,
* <math>a[i]</math> denotes the value that <math>a</math> associates to index <math>i</math>,
* <math>a\ \mathrm{WITH}\ [i]\ := v</math> denotes a map that associates <math>v</math> to index <math>i</math> and is otherwise identical to <math>a</math>.
Sequential updates can be chained with the shorthand syntax
<math>\_\ \mathrm{WITH}\ [\_]\ := \_, \ldots, [\_]\ := \_</math>.

A: TYPE = ARRAY INT OF REAL;
a: A;
i: INT = 4;

% selection:

elem: REAL = a[i];

% update

a1: A = a WITH [10] := 1/2;

% sequential update
% (syntactic sugar for (a WITH [10] := 2/3) WITH [42] := 3/2)

a2: A = a WITH [10] := 2/3, [42] := 3/2;

Since arrays are just maps, equality between them is extensional, that is,
for two arrays of the same type to be different they have to map at least one
index to differ values.

=== Data types ===

The theory of inductive data types is in fact a family of theories parametrized
by a data type declaration specifying constructors and selectors
for one or more user-defined data types.

No built-in operators other than equality and disequality are provided
for this family in the native language.
Each user-provided data type declaration, however, generates constructor, selector and tester operators
as described in the [[#Inductive Data Types | Inductive Data Types]] section.

=== Tuples and Records ===

Semantically both records and tuples can be seen as special instances
of inductive data types.
CVC4 implements them internally indeed as data types.
In essence, a record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math>
is encoded as a data type of the form

<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\ \ \mathrm{Record} = \mathit{rec}(l_0:T_0, \ldots, l_n:T_n) \\
\mathrm{END};
\end{array}
</math>
</center>

Tuples of length <math>n</math> are in turn special cases of records whose field names are
the numerals from <math>0</math> to <math>n-1</math>.

Externally, tuples and records have their own syntax for constructor and selector operators.
* Records of type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> have the associated record constructor <math>(\#\ l_0 := \_,\; \ldots,\; l_n := \_\ \#)</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.
* Tuples of type <math>[\ T_0, \ldots, T_n\ ]</math> have the associated tuple constructor <math>(\ \_,\; \ldots,\; \_\ )</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.

The selector operators on records and tuples follows a dot notation syntax.

% Record construction and field selection
Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);
k: INT = x.key;
v: REAL = x.weight;

% Tuple construction and projection
y: [REAL, INT, REAL] = ( 4/5, 9, 11/9 );
first_elem: REAL = y.0;
third_elem: REAL = y.2;

Differently from data types, records and tuples are also provided with built-in update operators similar in syntax and semantics to the update operator for arrays.
More precisely, for each record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .l_i\ := \_
</math>
</center>

The operator maps a record <math>r</math> of that type and a value <math>v</math>
of type <math>T_i</math> to the record that stores <math>v</math> in field <math>l_i</math>
and is otherwise identical to <math>r</math>.
Analogously, for each tuple type <math>[T_0, \ldots, T_n]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .i\ := \_
</math>
</center>

with similar semantics.

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = x WITH .weight := 48;

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = y WITH .1 := 3;

Updates to a nested component can be combined in a single WITH operator:

Cache: TYPE = ARRAY [0..100] OF [# addr: INT, data: REAL #];
State: TYPE = [# pc: INT, cache: Cache #];

s0: State;
s1: State = s0 WITH .cache[10].data := 2/3;

Note that, differently from updates on arrays, tuple and record updates are
just additional syntactic sugar.
For instance, the record <code>x1</code> and tuple <code>y1</code> defined above
could have been equivalently defined as follows:

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = (# key := x.key, weight := 48 #);

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = ( y.0, 3, y.1 );

== Commands ==

In addition to declarations of types and function symbols,
the CVC4 native language contains the following commands:

* <math>\mathrm{ASSERT}\ F</math> -- Add the formula <math>F</math> to the current logical context <math>\Gamma</math>.
* [[#CHECKSAT|<math>\mathrm{CHECKSAT}\ F</math>]] -- Check if the formula <math>F</math> is satisfiable in the current logical context (<math>\Gamma \not\models_T \mathrm{NOT}\ F</math>).
* <math>\mathrm{CONTINUE}</math> -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, search for a counter-example different from the current one.
* [[#COUNTEREXAMPLE|<math>\mathrm{COUNTEREXAMPLE}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print the context that is a witness for invalidity/satisfiability.
* [[#COUNTERMODEL|<math>\mathrm{COUNTERMODEL}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print a model that makes the formula invalid/satisfiable. The model is provided in terms of concrete values for each free symbol.
* <math>\mathrm{OPTION}\ o\ v</math> -- Set the command-line option flag <math>o</math> to value <math>v</math>. The argument <math>o</math> is provide as a string literal enclosed in double-quotes and <math>v</math> as an integer value.
* <math>\mathrm{POP}</math> -- Equivalent to <math>\mathrm{POPTO}\ 1</math>
* [[#POPTO|<math>\mathrm{POPTO}\ n</math>]] -- Restore the system to the state it was in right before the most recent call to <math>\mathrm{PUSH}</math> made from stack level <math>n</math>. Note that the current stack level is printed as part of the output of the <math>\mathrm{WHERE}</math> command.
* <math>\mathrm{PUSH}</math> -- Save (checkpoint) the current state of the system.
* [[#QUERY|<math>\mathrm{QUERY}\ F</math>]] -- Check if the formula <math>F</math> is valid in the current logical context (<math>\Gamma\models_T F</math>).
* [[#RESTART|<math>\mathrm{RESTART}\ F</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, repeat the check but with the additional assumption <math>F</math> in the context.
* <math>\mathrm{PRINT}\ t</math> -- Parse and print back the term <math>t</math>.
* <math>\mathrm{TRANSFORM}\ t</math> -- Simplify the term <math>t</math> and print the result.
* <math>\mathrm{WHERE}</math> -- Print all the formulas in the current logical context <math>\Gamma</math>.

The remaining commands take a single argument, given as a string literal enclosed in double-quotes.

* <math>\mathrm{ECHO}\ s</math> -- Print string <math>s</math>
* <math>\mathrm{INCLUDE}\ f</math> -- Read commands from file <math>f</math>.
* <math>\mathrm{TRACE}\ f</math> -- Turn on tracing for the debug flag <math>f</math>.
* <math>\mathrm{UNTRACE}\ f</math> -- Turn off tracing for the debug flag <math>f</math>.

Here, we explain some of the above commands in more detail.

=== QUERY ===

The command <math>\mathrm{QUERY}\ F</math> invokes the core functionality of CVC4 to check
the validity of the formula <math>F</math> with respect to the assertions made thus far,
which constitute the context <math>\Gamma</math>.
The argument <math>F</math> must be well typed term of type <math>\mathrm{BOOLEAN}</math>,
as described in [[#Terms and Formulas | Terms and Formulas]].

The execution of this command always terminates and produces one of three possible answers:
<code>valid</code>, <code>invalid</code>, and <code>unknown</code>.

* A <code>valid</code> answer indicates that <math>\Gamma \models_T F</math>. After a query returning such an answer, the logical context <math>\Gamma</math> is exactly as it was before the query.
* An <code>invalid</code> answer indicates that <math>\Gamma \not\models_T F</math>, that is, there is a model of the background theory <math>T</math> that satisfies <math>\Gamma \cup \{\mathrm{NOT}\ F\}</math>. When <math>\mathrm{QUERY}\ F</math> returns <code>invalid</code>, the logical context <math>\Gamma</math> is augmented with a set <math>\Delta</math> of ground (i.e., variable-free) literals such that <math>\Gamma\cup\Delta</math> is satisfiable in <math>T</math>, but <math>\Gamma\cup\Delta\models_T \mathrm{NOT}\ F</math>. In fact, in this case <math>\Delta</math> ''propositionally entails'' <math>\mathrm{NOT}\ F</math>, in the sense that, every truth assignment to the literals of <math>\Delta</math> that satisfies <math>\Delta</math> falsifies <math>F</math>. We call the new context <math>\Gamma\cup\Delta</math> a ''counterexample'' for <math>F</math>.
* An <code>unknown</code> answer is similar to an <code>invalid</code> answer in that additional literals are added to the context which propositionally entail <math>\mathrm{NOT}\ F</math>. The difference in this case is that CVC4 cannot guarantee that <math>\Gamma\cup\Delta</math> is actually satisfiable in <math>T</math>.

CVC4 may report <code>unknown</code> when the context or the query contains
non-linear arithmetic terms or quantifiers.
In all other cases, it is expected to be sound and complete,
i.e., to report <code>Valid</code> if <math>\Gamma \models_T F</math>
and <code>Invalid</code> otherwise.

After an <code>invalid</code> (resp. <code>unknown</code>) answer,
counterexamples (resp. possible counterexamples) can be obtained with
a <math>\mathrm{WHERE}</math>, <math>\mathrm{COUNTEREXAMPLE}</math>,
or <math>\mathrm{COUNTERMODEL}</math> command.


Since the <math>\mathrm{QUERY}</math> command may modify
the current context, if one needs to check several formulas in a row
in the same context, it is a good idea to surround every
query by a <math>\mathrm{PUSH}</math> and <math>\mathrm{POP}</math> invocation
in order to preserve the context:

PUSH;
QUERY <formula>;
POP;

=== CHECKSAT ===

The command <math>\mathrm{CHECKSAT}\ F</math> behaves identically
to <math>\mathrm{QUERY}\ \mathrm{NOT}\ F</math>.

=== RESTART ===

The command <math>\mathrm{RESTART}\ F</math> can only be invoked after an invalid query.
For example, in an interactive setting:

QUERY <formula>;

CVC4> invalid

RESTART <formula2>;

Functionally, the behavior of the above command sequence is identical to the following:

PUSH;
QUERY <formula>;
POP;
ASSERT <formula2>;
QUERY <formula>;

The advantage of using the <math>\mathrm{RESTART}</math> command is that
the first command sequence may be executed much more efficiently that the second.
The reason is that with <math>\mathrm{RESTART}</math> CVC4 will re-use
what it has learned while answering the previous query rather than starting
over from scratch.

=== COUNTERMODEL ===

[More]

=== COUNTEREXAMPLE ===

[More]

=== POPTO ===

[More]

== Instantiation Patterns ==

CVC4 processes each universally quantified formula in the current context
by adding instances of the formula obtained by replacing its universal variables
with ground terms.
Patterns restrict the choice of ground terms for the quantified variables,
with the goal of controlling the potential explosion of ground instances.
In essence, adding patterns to a formula is a way for the user to tell CVC4
to focus only on certain instances which, in the user's opinion, will be
most helpful during a proof.

In more detail, patterns have the following effect on formulas that are found
in the logical context or get added to it later while CVC4 is trying to prove
the validity of some formula <math>F</math>.

If a formula in the current context starts with an existential quantifier,
CVC4 ''Skolemizes'' it, that is, replaces it in the context with the formula
obtained by substituting the existentially quantified variables
by fresh constants and dropping the quantifier.
Any patterns for the existential quantifier are simply ignored.

If a formula starts with a universal quantifier
<math>\mathrm{FORALL}\; (x_1:T_1, \ldots, x_n:T_n)</math>,
CVC4 adds to the context a number of instances of the formula,
with the goal of using them to prove the query <math>F</math> valid.
An instance is obtained by replacing each <math>x_i</math> with a ground term
of the same type occurring in one of the formulas in the context,
and dropping the universal quantifier.
If <math>x_i</math> occurs in a pattern
<math>\mathrm{PATTERN}\; (t_1, \ldots, t_m)</math> for the quantifier,
it will be instantiated only with terms obtained by simultaneously matching
all the terms in the pattern against ground terms in the current context
<math>\Gamma</math>.

Specifically, the matching process produces one or more substitutions
<math>\sigma</math> for the variables in <math>(t_1, \ldots, t_m)</math>
which satisfy the following invariant:
for each <math>i = 1, \ldots, m</math>, <math>\sigma(t_i)</math> is
a ground term and there is a ground term <math>s_i</math> in <math>\Gamma</math>
such that <math>\Gamma \models_T \sigma(t_i) = s_i</math>.
The variables of <math>(x_1:T_1, \ldots, x_n:T_n)</math> that occur
in the pattern are instantiated only with those substitutions
(while any remaining variables are instantiated arbitrarily).

The Skolemized version or the added instances of a context formula may themselves
start with a quantifier.
The same instantiation process is applied to them too, recursively.

Note that the matching mechanism is not limited to syntactic matching
but is modulo the equations asserted in the context.
Because of decidability and/or efficiency limitations, the matching process
is not exhaustive.
CVC4 will typically miss some substitutions that satisfy the invariant above.
As a consequence, it might fail to prove the validity of the query formula
<math>F</math>, which makes CVC4 incomplete for contexts containing
quantified formulas.
It should be noted though that exhaustive matching, which can be achieved
simply by not specifying any patterns, does not yield completeness anyway
since the instantiation of universal variables is still restricted
to just the ground terms in the context,
whereas in general additional ground terms might be needed.



=CVC4's support for the SMT-LIB language=

==SMT-LIB compliance==

Every effort has been made to make CVC4 compliant with the SMT-LIB 2.0
standard (http://smtlib.org/). However, when parsing SMT-LIB input,
certain default settings don't match what is stated in the official
standard. To make CVC4 adhere more strictly to the standard, use the
"--smtlib" command-line option. Even with this setting, CVC4 is
somewhat lenient; some non-conforming input may still be parsed and
processed.

=The CVC4 library interface (API)=
==Using CVC4 in a C++ project==
==Using CVC4 from Java==
==The compatibility interface==

=Upgrading from CVC3 to CVC4=

==Features not supported by CVC4 (yet)==

===Type Correctness Conditions (TCCs)===

Type Correctness Conditions (TCCs), and the checking of such, are not
supported by CVC4 1.0. Thus, a function defined only on integers can be
applied to REAL (as INT is a subtype of REAL), and CVC4 will not complain,
but may produce strange results. For example:

f : INT -> INT;
ASSERT f(1/3) = 0;
ASSERT f(2/3) = 1;
CHECKSAT;
% sat
COUNTEREXAMPLE;
% f : (INT) -> INT = LAMBDA(x1:INT) : 0;

CVC3 can be used to produce TCCs for this input (with the +dump-tcc option).
The TCC can be checked by CVC3 or another solver. (CVC3 can also check
TCCs while solving with +tcc.)

==If you were using the text interfaces of CVC3==

The native language of all solvers in the CVC family, referred to as the
"presentation language," has undergone some revisions for CVC4. The
most notable is that CVC4 does _not_ add counterexample assertions to
the current assertion set after a SAT/INVALID result. For example:

x, y : INT;
ASSERT x = 1 OR x = 2;
ASSERT y = 1 OR y = 2;
ASSERT x /= y;
CHECKSAT;
% sat
QUERY x = 1;
% invalid
QUERY x = 2;
% invalid

Here, CVC4 responds "invalid" to the second and third queries, because
each has a counterexample (x=2 is a counterexample to the first, and
x=1 is a counterexample to the second). However, CVC3 will respond
with "valid" to one of these two, as the first query (the CHECKSAT)
had the side-effect of locking CVC3 into one of the two cases; the
later queries are effectively querying the counterexample that was
found by the first. CVC4 removes this side-effect of the CHECKSAT and
QUERY commands.

CVC4 supports rational literals (of type REAL) in decimal; CVC3 did not
support decimals.

CVC4 does not have support for the IS_INTEGER predicate.

==If you were using the library ("in-memory") interface of CVC3==
===If you were using CVC3 from C===
===If you were using CVC3 from Java===

=Useful command-line options=

==Statistics==

Statistics can be dumped on exit (both normal and abnormal exits) with
the --statistics command line option.

==Time and resource limits==

CVC4 can be made to self-timeout after a given number of milliseconds.
Use the --tlimit command line option to limit the entire run of
CVC4, or use --tlimit-per to limit each individual query separately.
Preprocessing time is not counted by the time limit, so for some large
inputs which require aggressive preprocessing, you may notice that
--tlimit does not work very well. If you suspect this might be the
case, you can use "-vv" (double verbosity) to see what CVC4 is doing.

Time-limited runs are not deterministic; two consecutive runs with the
same time limit might produce different results (i.e., one may time out
and responds with "unknown", while the other completes and provides an
answer). To ensure that results are reproducible, use --rlimit or
--rlimit-per. These options take a "resource count" (presently, based on
the number of SAT conflicts) that limits the search time. A word of
caution, though: there is no guarantee that runs of different versions of
CVC4 or of different builds of CVC4 (e.g., two CVC4 binaries with different
features enabled, or for different architectures) will interpret the resource
count in the same manner.

CVC4 does not presently have a way to limit its memory use; you may opt
to run it from a shell after using "ulimit" to limit the size of the
heap.

=Dumping API calls or preprocessed output=

=Changing the output language=

=Proof support=

CVC4 1.0 has limited support for proofs, and they are disabled by default.
(Run the configure script with --enable-proof to enable proofs). Proofs
are exported in LFSC format and are limited to the propositional backbone
of the discovered proof (theory lemmas are stated without proof in this
release).

=Portfolio solving=

If enabled at configure-time (./configure --with-portfolio), a second
CVC4 binary will be produced ("pcvc4"). This binary has support for
running multiple instances of CVC4 in different threads. Use --threads=N
to specify the number of threads, and use --thread0="options for thread 0"
--thread1="options for thread 1", etc., to specify a configuration for the
threads. Lemmas are *not* shared between the threads by default; to adjust
this, use the --filter-lemma-length=N option to share lemmas of N literals
(or smaller). (Some lemmas are ineligible for sharing because they include
literals that are "local" to one thread.)

Currently, the portfolio **does not work** with quantifiers or with
the theory of inductive datatypes. These limitations will be addressed
in a future release.

=Emacs support=

For a suggestion of editing CVC4 source code with emacs, see the file
contrib/editing-with-emacs. For a CVC language mode (the native input
language for CVC4), see contrib/cvc-mode.el.

CVC4 - User contributions [en]

Sets

About CVC4

User Registration

CVC4's native language

CVC4's native language

Strings

Strings

Strings

Strings

Strings

Strings

Strings

Strings

Strings

CVC4's native language

CVC4's native language

CVC4's native language

CVC4's native language

CVC4's native language

CVC4's native language

CVC4's native language

CVC4's native language

CVC4's native language

CVC4's native language

CVC4's native language

CVC4's native language

User Manual

Related Links

User Manual

User Manual

User Manual

User Manual

User Manual

User Manual