Constraints as control

Abstract

We present an extension of Scala that supports constraint programming over bounded and unbounded domains. The resulting language, Kaplan, provides the benefits of constraint programming while preserving the existing features of Scala. Kaplan integrates constraint and imperative programming by using constraints as an advanced control structure; the developers use the monadic 'for' construct to iterate over the solutions of constraints or branch on the existence of a solution. The constructs we introduce have simple semantics that can be understood as explicit enumeration of values, but are implemented more efficiently using symbolic reasoning.Kaplan programs can manipulate constraints at run-time, with the combined benefits of type-safe syntax trees and first-class functions. The language of constraints is a functional subset of Scala, supporting arbitrary recursive function definitions over algebraic data types, sets, maps, and integers.Our implementation runs on a platform combining a constraint solver with a standard virtual machine. For constraint solving we use an algorithm that handles recursive function definitions through fair function unrolling and builds upon the state-of-the art SMT solver Z3. We evaluate Kaplan on examples ranging from enumeration of data structures to execution of declarative specifications. We found Kaplan promising because it is expressive, supporting a range of problem domains, while enabling full-speed execution of programs that do not rely on constraint programming.

Reductions for Synthesis Procedures

“…Our contribution fills an unexplored area between two approaches: running SMT solvers at run time [7] and using quantifier-elimination-like algorithms to compile specifications. In this paper we have shown that for two important theories supported by SMT solvers, compilation of constraints is also feasible.…”

“…. ,v n forx and add to φ an additional conjunct n i=1x =v n , see [7]. One possible approach to compile this process is to enrich Presburger arithmetic with finite uninterpreted relations as parameters.…”

“…the synthesis procedure computes T * as a finite set of solutions 2. the synthesis procedure computes T * as a solved form of φ, that allows us to access solutions iteratively (like mentioned in Sect. 3; this is also possible if there are infinitely many possible solutions at compile time) 3. the synthesis procedure produces code T * , representing a specialized solver for the index theory, that is instantiated with φ and allows to add more constraints ψ to obtain solutions satisfying φ ∧ ψ (in the limit this means integrating a constraint solver procedure into the generated code [7]). …”

Developing Verified Software Using Leon

“…functions without body, given only by postconditions), by invoking a constraint solver at run time [13]. This mechanism reuses counterexample-finding ability as a computation mechanism [11]. Leon thus supports an expressive form of constraint programming with computable functions as constraints.…”

αRby—An Embedding of Alloy in Ruby

“…In this case, declarative specifications are executed 'by magic', as if, in a conventional setting, the interpreter could execute a program assertion by making it true despite the lack of any explicit code to establish it [10,9]. Alternatively, flipping the precedence of the two paradigms, the interpreter can be viewed as a declarative model finder that uses imperative code to setup a declarative specification to be solved.…”