A query is a user-guided mechanism to directly communicate and extract results from the solver.

Run a custom query

Similar to freshVar, except creates unnamed variable.

Create a fresh variable in query mode. You should prefer creating input variables using sBool, sInt32, etc., which act as primary inputs to the model and can be existential or universal. Use freshVar only in query mode for anonymous temporary variables. Such variables are always existential. Note that freshVar should hardly be needed: Your input variables and symbolic expressions should suffice for most major use cases.

Similar to freshArray, except creates unnamed array.

Create a fresh array in query mode. Again, you should prefer creating arrays before the queries start using newArray, but this method can come in handy in occasional cases where you need a new array after you start the query based interaction.

Result of a checkSat or checkSatAssuming call.

Check for satisfiability.

Check for satisfiability with a custom check-sat-using command.

Check for satisfiability, under the given conditions. Similar to checkSat except it allows making further assumptions as captured by the first argument of booleans. (Also see checkSatAssumingWithUnsatisfiableSet for a variant that returns the subset of the given assumptions that led to the Unsat conclusion.)

Check for satisfiability, under the given conditions. Returns the unsatisfiable set of assumptions. Similar to checkSat except it allows making further assumptions as captured by the first argument of booleans. If the result is Unsat, the user will also receive a subset of the given assumptions that led to the Unsat conclusion. Note that while this set will be a subset of the inputs, it is not necessarily guaranteed to be minimal.

You must have arranged for the production of unsat assumptions first via

    setOption $ ProduceUnsatAssumptions True

for this call to not error out!

Usage note: getUnsatCore is usually easier to use than checkSatAssumingWithUnsatisfiableSet, as it allows the use of named assertions, as obtained by namedConstraint. If getUnsatCore fills your needs, you should definitely prefer it over checkSatAssumingWithUnsatisfiableSet.

A class which allows for sexpr-conversion to values

Get the value of a term.

Get the value of an uninterpreted sort, as a String

Collect model values. It is implicitly assumed that we are in a check-sat context. See getSMTResult for a variant that issues a check-sat first and returns an SMTResult.

Retrieve the assignment. This is a lightweight version of getValue, where the solver returns the truth value for all named subterms of type Bool.

You must have first arranged for assignments to be produced via

    setOption $ ProduceAssignments True

for this call to not error out!

Issue check-sat and get an SMT Result out.

Get the reason unknown. Only internally used.

Retrieve the unsat-core. Note you must have arranged for unsat cores to be produced first via

    setOption $ ProduceUnsatCores True

for this call to not error out!

NB. There is no notion of a minimal unsat-core, in case unsatisfiability can be derived in multiple ways. Furthermore, Z3 does not guarantee that the generated unsat core does not have any redundant assertions either, as doing so can incur a performance penalty. (There might be assertions in the set that is not needed.) To ensure all the assertions in the core are relevant, use:

    setOption $ OptionKeyword ":smt.core.minimize" ["true"]

Note that this only works with Z3.

Retrieve the proof. Note you must have arranged for proofs to be produced first via

    setOption $ ProduceProofs True

for this call to not error out!

A proof is simply a String, as returned by the solver. In the future, SBV might provide a better datatype, depending on the use cases. Please get in touch if you use this function and can suggest a better API.

Retrieve an interpolant after an Unsat result is obtained. Note you must have arranged for interpolants to be produced first via

    setOption $ ProduceInterpolants True

for this call to not error out!

To get an interpolant for a pair of formulas A and B, use a constrainWithAttribute call to attach interplation groups to A and B. Then call getInterpolant ["A"], assuming those are the names you gave to the formulas in the A group.

An interpolant for A and B is a formula I such that:

       A ==> I
   and B ==> not I

That is, it's evidence that A and B cannot be true together since A implies I but B implies not I; establishing that A and B cannot be satisfied at the same time. Furthermore, I will have only the symbols that are common to A and B.

N.B. As of Z3 version 4.8.0; Z3 no longer supports interpolants. Use the MathSAT backend for extracting interpolants. See Documentation.SBV.Examples.Queries.Interpolants for an example.

Retrieve assertions. Note you must have arranged for assertions to be available first via

    setOption $ ProduceAssertions True

for this call to not error out!

Note that the set of assertions returned is merely a list of strings, just like the case for getProof. In the future, SBV might provide a better datatype, depending on the use cases. Please get in touch if you use this function and can suggest a better API.

Collectable information from the solver.

Behavior of the solver for errors.

Collectable information from the solver.

Ask solver for info.

Retrieve the value of an 'SMTOption.' The curious function argument is on purpose here, simply pass the constructor name. Example: the call getOption ProduceUnsatCores will return either Nothing or Just (ProduceUnsatCores True) or Just (ProduceUnsatCores False).

Result will be Nothing if the solver does not support this option.

The current assertion stack depth, i.e., pops after start. Always non-negative.

Push the context, entering a new one. Pushes multiple levels if n > 1.

Pop the context, exiting a new one. Pops multiple levels if n > 1. It's an error to pop levels that don't exist.

Run the query in a new assertion stack. That is, we push the context, run the query commands, and pop it back.

Search for a result via a sequence of case-splits, guided by the user. If one of the conditions lead to a satisfiable result, returns Just that result. If none of them do, returns Nothing. Note that we automatically generate a coverage case and search for it automatically as well. In that latter case, the string returned will be Coverage. The first argument controls printing progress messages See Documentation.SBV.Examples.Queries.CaseSplit for an example use case.

Reset the solver, by forgetting all the assertions. However, bindings are kept as is, as opposed to a full reset of the solver. Use this variant to clean-up the solver state while leaving the bindings intact. Pops all assertion levels. Declarations and definitions resulting from the setLogic command are unaffected. Note that SBV implicitly uses global-declarations, so bindings will remain intact.

Make an assignment. The type Assignment is abstract, the result is typically passed to mkSMTResult:

 mkSMTResult [ a |-> 332
             , b |-> 2.3
             , c |-> True
             ]

End users should use getModel for automatically constructing models from the current solver state. However, an explicit Assignment might be handy in complex scenarios where a model needs to be created manually.

Produce the query result from an assignment.

Exit the solver. This action will cause the solver to terminate. Needless to say, trying to communicate with the solver after issuing "exit" will simply fail.

If true, we shall ignore the exit code upon exit. Otherwise we require ExitSuccess.

Timeout a query action, typically a command call to the underlying SMT solver. The duration is in microseconds (1/10^6 seconds). If the duration is negative, then no timeout is imposed. When specifying long timeouts, be careful not to exceed maxBound :: Int. (On a 64 bit machine, this bound is practically infinite. But on a 32 bit machine, it corresponds to about 36 minutes!)

Semantics: The call timeout n q causes the timeout value to be applied to all interactive calls that take place as we execute the query q. That is, each call that happens during the execution of q gets a separate time-out value, as opposed to one timeout value that limits the whole query. This is typically the intended behavior. It is advisible to apply this combinator to calls that involve a single call to the solver for finer control, as opposed to an entire set of interactions. However, different use cases might call for different scenarios.

If the solver responds within the time-out specified, then we continue as usual. However, if the backend solver times-out using this mechanism, there is no telling what the state of the solver will be. Thus, we raise an error in this case.

If verbose is True, print the message, useful for debugging messages in custom queries. Note that redirectVerbose will be respected: If a file redirection is given, the output will go to the file.

Echo a string. Note that the echoing is done by the solver, not by SBV.

Perform an arbitrary IO action.

Option values that can be set in the solver, following the SMTLib specification http://smtlib.cs.uiowa.edu/language.shtml.

Note that not all solvers may support all of these!

Furthermore, SBV doesn't support the following options allowed by SMTLib.

• :interactive-mode (Deprecated in SMTLib, use ProduceAssertions instead.)
• :print-success (SBV critically needs this to be True in query mode.)
• :produce-models (SBV always sets this option so it can extract models.)
• :regular-output-channel (SBV always requires regular output to come on stdout for query purposes.)
• :global-declarations (SBV always uses global declarations since definitions are accumulative.)

Note that SetLogic and SetInfo are, strictly speaking, not SMTLib options. However, we treat it as such here uniformly, as it fits better with how options work.