Abstracting definitional interpreters (functional pearl)

Abstract

In this functional pearl, we examine the use of definitional interpreters as a basis for abstract interpretation of higher-order programming languages. As it turns out, definitional interpreters, especially those written in monadic style, can provide a nice basis for a wide variety of collecting semantics, abstract interpretations, symbolic executions, and their intermixings.But the real insight of this story is a replaying of an insight from Reynold's landmark paper, Definitional Interpreters for Higher-Order Programming Languages, in which he observes definitional interpreters enable the defined-language to inherit properties of the defining-language. We show the same holds true for definitional abstract interpreters. Remarkably, we observe that abstract definitional interpreters can inherit the so-called "pushdown control flow" property, wherein function calls and returns are precisely matched in the abstract semantics, simply by virtue of the function call mechanism of the defining-language.The first approaches to achieve this property for higher-order languages appeared within the last ten years, and have since been the subject of many papers. These approaches start from a state-machine semantics and uniformly involve significant technical engineering to recover the precision of pushdown control flow. In contrast, starting from a definitional interpreter, the pushdown control flow property is inherent in the metalanguage and requires no further technical mechanism to achieve.

Size-change termination as a contract: dynamically and statically enforcing termination for higher-order programs

“…Although symbolic execution has traditionally been used to find bugs [7,26,30,38,39] as opposed to verifying programs as correct, we can apply a well studied technique for abstracting the operational semantics through finitizing the program's dynamic components [15,49] and obtain a verification that particular errors cannot occur at run-time.…”

Sound and reusable components for abstract interpretation

“…These arrow transformers are well-known and we borrowed their definition from the arrow transformer libraries arrows and atl on Hackage. 2 Furthermore, some of these arrow transformers appeared in form of monad transformers in [Darais et al 2017[Darais et al , 2015], which we took inspiration from. Environment Components To implement environment components, we created the type class ArrowEnv with an operation getEnv to fetch an environment, localEnv to set a new environment in a local context, extendEnv to extend the given environment with a new binding and lookup to look up a binding in the current environment: Based on this interface, we created two components for environments.…”

“…Based on this interface we implemented a fixpoint component ⟨Fix, Fix⟩ ArrowFix , whose concrete fix operation calculates the standard fixpoint fix f = f (fix f). The abstract fix operation implements a parallel/sequential fixpoint algorithm [Darais et al 2017]. We parameterized this fixpoint algorithm by a widening operator [Cousot and Cousot 1992] for the codomain y that ensures that the fixpoint iteration terminates and a second operator on the domain x that joins recursive calls to avoid infinitely deep chains of recursive calls.…”

Verification of high-level transformations with inductive refinement types

“…Definitional interpreters have been suggested as a technique for building compositional abstract interpreters [20]. The idea is to rely on a monad transformer stack to share the implementation of the concrete and abstract interpreters.…”