7 Conclusion

Abstract

identity of ΣA and ABS, program fragments are returned in the language ofΣC. A decision procedure replaces deductive inference on the axioms in DT. As in DRAT, the library is organized hierarchically; a new portion of the library is shown in Figure 1. Each node in the hierarchy is a 6-tuple where the first four elements are the index,DP is a decision procedure schema (implemented as a common lisp object class), and I is a procedure for instantiating a decision procedure schema given an instantiation of the 4-tuple index. When the theory resolution interface gives an instantiated decision procedure a set of literals in the language of ΣA and ABS,the decision procedure returns terms in the language of ΣC as bindings for existential variables in the literals (universal variables when considered as an unsatisfiability problem). The decision procedure can also return a set of residual literals, if it is unable to completely resolve the literals given as input. More formally, given a set φ of literals in the language of ΣA and ABS, the decision procedure returns a set of literals φ ’ and set of terms t in the language of ΣC, such that ( outsare variables, DTI is the instantiated theory for the decision procedure): As an example, consider the decision procedures indexed under the Graph taxonomy in Figure 1. These decision procedures generate terms representing paths in a graph. The specification language ( ΣA) sort ‘nodes’ consist of the node labels of the graph, and the concrete language ( ΣC) sort ‘edges’ consist of the edge labels of the graph. The properties of the graph determine which decision procedure in the taxonomy is used. A decision procedure is applicable if an instantiation of its theory (i.e., DTI) is implied by the domain theory defining a graph; the decision procedure with the most specific such theory is best. Instantiated decision procedures from the Graph taxonomy take as input conjunctions of literals and build internal graph data structures representing those conjunctions. These decision procedures decide satisfiability of the conjunctions (with respect to the instantiated theory for the decision procedure) by manipulating the graphs. They also determine when variables in the conjunction are connected in the graph to constants (program input variables) and construct ground terms for those variables by traversing the graph. Instantiated decision procedures can be composed horizontally or vertically (where the concrete language for one decision procedure is the same as the abstract language for the following decision procedure). When decision procedures are combined, they communicate by passing variable bindings back and forth [7]. In addition, decision procedures can be nested —one decision procedure can take another as a parameter in order to solve subproblems. Each decision procedure in the Graph taxonomy is parameterized by a path algebra; this parameter is instantiated by a decision procedure in the hierarchy below Category (Path Algebra) in the Algebra taxonomy. Graphbased procedures invoke their procedure parameter to check the consistency of paths in graphs they are constructing and to determine if there are shorter equivalent paths. If an inconsistent path is found, the graph-based procedure signals unsatisfiability. If the path algebra procedure determines that there is a shorter equivalent path between two nodes than the existing path, the existing path is replaced by the shorter one. This ensures that the terms constructed by traversing a graph are always the simplest terms possible. 6.3 DSDRAT’s design algorithm DSDRAT’s design algorithm is an extension of DRAT’s design algorithm. The top-level control loop is similar to the pseudo-code description in Section 4. Given a structured AMPHION domain theory, DSDRAT begins by classifying the symbols in ΣA andABS. Relation symbols and some function symbols (those whose semantics are not given by implementation equations that can be converted to rewrite rules) in ΣA are classified. In addition, in order to connect the decision procedures at the abstract level to procedures at the concrete level, DSDRAT classifies the parameterized abstraction functions in ABS. The leftmost taxonomy in Figure 1 is used for this purpose. In the hierarchy in Figure 1, there are three taxonomies labeled Parameterized Abstraction Function, Graph, and Algebra. Each taxonomy is an and-or tree with downward links labeled by properties in roman, such as associativity of an algebra with a binary relation. Links with incompatible properties have an arc drawn between them. Nodes are theories that accumulate their axioms (properties) along the paths leading to them. Nodes with a bold label have an associated decision procedure schema. The dotted lines are definitional extensions and reformulation links. Parts of a domain theory are classified by constructing theory morphisms from the theories in the library hierarchy to parts of the domain theory. Theory morphisms are the generalization of DRAT’s instantiation of individual function, relation, and sort symbols. A theory morphism is a map from the language of one theory to the language of another theory such that the axioms of the first theory are mapped to theorems in the second theory. DSDRAT invokes AMPHION to prove such theorems. Constructing theory morphisms from the nodes in the top of the decision procedure hierarchy is mainly syntactic, since there are relatively few axioms associated with such nodes. However, constructing these morphisms can involve simple syntactic reformulations, such as tupling together sorts and currying functions. These reformulations are handled through decision procedures for several different kinds of axiom sets. To test the effectiveness of these procedures, we developed a test suite of forty specifications to compare total proof steps and run-times for three different configurations of the theorem-prover: without the strategy described in section 2, with that strategy, and with the combination of the strategy and decision procedures. Attempts to prove specifications without either the strategy or decision procedures ended in failure to find any proofs in under 100 minutes, so this configuration was abandoned. All of the forty problems were proved with the strategy-only configuration and the strategy/decision procedure configuration. On average, the strategy/decision procedure configuration found proofs in an order of magnitude less time than the strategy-only configuration. For example, in the proof of one specification the strategy-only configuration took 430 steps and 289 seconds. On the same specification, the strategy/decision procedure configuration took 58 steps in 15 seconds (Each step is a resolution or a paramodulation). Perhaps more important than the above results is that, because these procedures take advantage of well-defined mathematical structures in a domain theory, as did DRAT, this approach is amenable to automation. The next section describes the design of our system DSDRAT, which extends DRAT from analytical reasoning problems to deductive synthesis problems. We are currently implementing these extensions of DRAT. 6.Automating domain theory operationalization 6.1 ExtendingDRAT to deductive synthesis Scaling up from analytical reasoning problems to deductive synthesis problems requires extensions for: 1) the kinds of problems that are solved, 2) the outputs of the proof process, 3) the complexity of the domain theories. Technically, analytical reasoning problems are ground (un)satisfiability questions (i.e., is a ground formula (un)satisfiable in a given theory). In contrast, deductive synthesis problems for A MPHION are specifications given as preand post-conditions: whereDT is the domain theory, ins is a vector of input variables and outs is a vector of output variables. In order to simplify the exposition, we will assume the precondition (R(ins) is always true. There is a special subset of the concrete part of the domain theory language, called the output language, whose symbols name components of the target software library. Deductive synthesis proves a theorem by constructing substitutions for the output variables that are terms in the output language. The variables in these terms are input variables; hence these terms represent program fragments that compute the value of an output variable from the values of input variables. (Technically, deductive synthesis through resolution theorem-proving solves the non-ground unsatisfiability question: “is unsatisfiable?” The decision procedures designed by DSDRAT also solve unsatisfiability questions and work in conjunction with the resolution proof process through theory resolution.) In contrast to analytical reasoning problems, for deductive synthesis problems an important consideration is the algebraic structure of output terms, e.g., the equivalence classes of these terms. Inferences on this structure provide KBPS some of its advantage over the context-free, macroexpansion code-generation process used in application generators. Besides correctness we usually want to place additional requirements on these output terms for deductive synthesis, such as that they represent the best program in their equivalence class, by some measure. So far in this research we have made the assumption that the best programs satisfying a post-condition are represented by the ground terms with the smallest number of function applications. In addition to these differences in the problem types and proof-process outputs, A MPHION domain theories also differ from analytical reasoning task domain theories. The latter are unstructured and primarily relational. In contrast, AMPHION domain theories are structured into an abstract and a concrete level, with abstraction maps between these levels. DRAT for deductive synthesis (DSDRAT) extends DRAT according to these differences. DSDRAT takes a structured AMPHION domain