In z3 is it possible to declare a function that takes another function as an argument? For instance, this
(declare-fun foo ( ((Int) Bool) ) Int)
doesn't quite seem to work. Thanks.
As Leonardo mentioned, SMT-Lib does not allow higher-order functions. This is not merely a syntactic restriction: Reasoning with higher-order functions is (generally) beyond what SMT solvers can deal with. (Although uninterpreted functions can be used in some special cases.)
If you do need to reason with higher-order functions, then interactive theorem provers are the main weapon of choice: Isabelle, HOL, Coq being some of the examples.
However, sometimes you want the higher-order functions not to reason about them, but rather merely to simplify programming tasks. SMT-Lib input language is not suitable for high-level programming that end-users typically need in practical situations. If that is your use case, then I'd recommend not using SMT-Lib directly, but rather working with a programming language that gives you access to Z3 (or other SMT solvers). There are several choices, depending on what host language is most suitable for your use case:
If you are a Python user, Z3Py that just shipped with Z3 4.0 is the way to go,
If you are a Scala user, then look into Scala^Z3.
If Haskell is your preferred language, then take a look at SBV.
Each binding has its own feature set, Z3Py probably being the most versatile since it's directly supported by the Z3 folks. (It also provides access to Z3 internals that remain inaccessible for the other choices, at least for the time being.)
No, this is not possible. However, you can define a function that takes an array as an argument.
(declare-fun foo ((Array Int Bool)) Int)
You can use this trick to simulate high-order functions like the one in your question.
Here is an example: http://rise4fun.com/Z3/qsED
The Z3 guide contains more information about Z3 and SMT.
Related
I'm using the Z3_parse_smtlib2_string function from the Z3 C API (via Haskell's Z3 lib) to parse an SMTLIB file and apply some tactics to simplify its content, however I notice that any push, pop and check-sat commands appear to be swallowed by this function and do not appear in the resulting AST.
Is there anyway that I can parse this without losing these commands (and then apply the required tactics, once again without losing them)?
I don't think it's possible to do this with Z3_parse_smtlib2_string. As you can see in the documentation "It returns a formula comprising of the conjunction of assertions in the scope (up to push/pop) at the end of the string." See: https://z3prover.github.io/api/html/group__capi.html#ga7905ebec9289b9fe5debcad965f6267e
Note that the reason for this is not just mere "not-implemented" or "buggy." Look at the return type of the function you're using. It returns a Z3_ast_vector, and Z3_ast only captures "expressions" in the SMTLib language. But push/pop etc. are not considered expressions by Z3, but rather commands; i.e., they are internally represented differently. (Whether this was a conscious choice or historical is something I'm not sure about.)
I don't think there's a function to do what you're asking; i.e., can return both expressions and commands. You can ask at https://github.com/Z3Prover/z3/discussions to see if the developers can provide an alternative API, or if they already have something exposed to the users that achieves this.
Say for modeling the haskell map function, which takes in a "mapper" function that is applied to all elements of a list. How can I declare map in smtlib?
No; SMTLib is essentially a first-order theory; higher order functions are simply not supported.
Z3, however, allows mapping functions over arrays, with the (_ map f) extension. See https://rise4fun.com/Z3/tutorial/guide, search for "Mapping Functions on Arrays." This doesn't give you arbitrary higher-order functions, but can be used to simulate those that operate on SMTLib arrays.
If you do intend to reason about higher-order functions, then SMTLib is arguably the wrong logic for you. Use of a more traditional theorem prover like HOL/Isabelle, or modern incarnations in Agda/Coq would be more suitable. You can also take a look at Lean, which has a good compromise of features and automation.
As previously asked Z3 can not provide a model for recursive functions. However, is it possible to tell Z3 (preferably via the Java API) that a model without a definition for recursive functions is sufficient (or indeed choose the functions I am interested in, essentially I do not need a model for non-constant functions)? Obviously, that might lead to queries that return sat although some functions do not have a model. Basically, the user then has to ensure that these functions do have some model.
However, I would assume this is not really realizable the way Z3 or SMT solvers work, i.e., I would assume Z3 needs a (partial) model of recursive functions to evalutate expressions.
The MBQI implementation for quantifiers doesn't really work nicely with recursive functions.
There is one thing that might do the trick for you: replace recursive function definitions by bounded-recursive functions. You add an extra argument that counts the number of unfoldings you are willing to explore of the function. Whenever you apply the recursive function in the rest of the input, set the depth parameter. You can use either algebraic data-type Peano numbers or integers.
The symbolic automata toolkit uses this approach, for example.
I found one paper that explores the idea given in Nikolaj Bjorner's answer further: "Computing with an SMT solver" by Amin, Leino and Rompf (2014).
Furthermore, I found "Satisfiability Modulo Recursive Programs" by Suter, Köksal and Kuncak (2011) which unfolds calls to recursive functions successively until the satisfiability can be decided.
I have precise and validated descriptions of the behaviors of many X86 instructions in terms amenable to encoding in QF_ABV and solving directly with the standard solver (using no special solving strategies). I wrote an SMT-LIB script whose interface matches my ultimate goal perfectly:
X86State, a record sort describing x86 machine state (registers and flags as bitvectors, and memory as an array).
X86Instr, a record sort describing x86 instructions (enumerated mnemonics, operands as an ML-like discriminated union describing registers, memory expressions, etc.)
A function x86-translate taking an X86State and an X86Instr, and returning a new X86State. It decodes the X86Instr and produces a new X86State in terms of the symbolic effects of the given X86Instr on the input X86State.
It's great for prototyping: the user can write x86 easily and directly. After simplifying a formula built using the library, all functions and extraneous data types are eliminated, leaving a QF_ABV expression. I hoped that users could simply (set-logic QF_ABV) and #include my script (alas, neither the SMT-LIB standard nor Z3 support #include).
Unfortunately, by defining functions and types, the script requires theories such as uninterpreted functions, thus requiring a logic other than QF_ABV (or even QF_AUFBV due to the types). My experience with SMT solvers dictates that the lowest acceptable logic should be specified for best solving time. Also, it is unclear whether I can reuse my SMT-LIB script in a programmatic context (e.g. OCaml, Python, C) as I desire. Finally, the script is a bit verbose given the lack of higher-order functions, and my lack of access to par leading to code duplication.
Thus, despite having accomplished my technical goals, I think that SMT-LIB might be the wrong approach. Is there a more natural avenue for interacting with Z3 to implement my x86 instruction description / QF_ABV translation scheme? Is the SMT-LIB script re-usable at all in these avenues? For example, you can build "custom OCaml top-levels", i.e. interpreters with scripts "burned into them". Something like that could be nice. Or do I have to re-implement the functionality in another language, in a program that interacts with Z3 via a theory extension (C DLL)? What's the best option here?
Well, I don't think that people write .smt2 files by hand. These are usually generated automatically by some program.
I find the Z3 Python interface quite nice, so I guess you could give it a try. But you can always write a simple .smt2 dumper from any language.
BTW, do you plan releasing the specification you wrote for X86? I would be really interested!
Click to see the file
Is this file compliant with the SMT2.0 standard? At least, z3 can accpet it. By the way, what's the difference between 'declare-const' and 'declare-fun'? For example, in order to declare a Bool variable I can write declare-const a Bool or declare-fun a() Bool.
I am unable to locate the file you mention in the post, but to answer your question about declare-const:
(declare-const a Bool)
means the same as
(declare-fun a () Bool)
declare-const is not part of standard SMT-LIB2.
It is a command added to Z3 for the convenience of
entering SMT-LIB2 benchmarks manually. You can
always use declare-fun instead to be compatible
across solvers.
While Z3 can process SMT-LIB2 compliant files.
On the other hand, there are several other extensions in Z3's input format
that are not part of SMT-LIB2 standard.
To mention some:
declare-datatypes. Declaration of algebraic datatypes is a Z3 specific extension.
tactics and solvers. Creation, composition and application of tactics is specific to Z3.
declare-rel, declare-var, rule, query. These commands are used by the fixedpoint solver for the convenience of entering benchmarks as Horn formulas.