Functional programs that explain their work

Abstract

We present techniques that enable higher-order functional computations to "explain" their work by answering questions about how parts of their output were calculated. As explanations, we consider the traditional notion of program slices, which we show can be inadequate, and propose a new notion: trace slices. We present techniques for specifying flexible and rich slicing criteria based on partial expressions, parts of which have been replaced by holes. We characterise program slices in an algorithm-independent fashion and show that a least slice for a given criterion exists. We then present an algorithm, called unevaluation, for computing least program slices from computations reified as traces. Observing a limitation of program slices, we develop a notion of trace slice as another form of explanation and present an algorithm for computing them. The unevaluation algorithm can be applied to any subtrace of a trace slice to compute a program slice whose evaluation generates that subtrace. This close correspondence between programs, traces, and their slices can enable the programmer to understand a computation interactively, in terms of the programming language in which the computation is expressed. We present an implementation in the form of a tool, discuss some important practical implementation concerns and present some techniques for addressing them.

Lineage-driven Fault Injection

“…Languages like Erlang [9] and Akka [68] are attractive candidates because of their explicit communication, while aspect-oriented programming [47] could be used with a language such as Java to facilitate both trace extraction and communication interposition. Backwards slicing techniques [66] could be used to recover fine-grained lineage from the executions of programs written in a functional language.…”

Resugaring

“…These uses tend to be static, rather than addressing the inverse-mapping problem in the context of system execution (see the survey by Stevens [24]). When the problem we address does arise in this area, it is typically the case that either (i) both the source and target models have implementations, so that surface-level execution traces can be obtained by evaluating in the surface language directly [21], or (ii) the surface information sought is more limited than the reduction sequence we provide (in the same ways as for debuggers for optimizing compilers, as described earlier). Applying our results to this area is future work.…”

Resugaring

“…These uses tend to be static, rather than addressing the inverse-mapping problem in the context of sys-tem execution (see the survey by Stevens [24]). When the problem we address does arise in this area, it is typically the case that either (i) both the source and target models have implementations, so that surface-level execution traces can be obtained by evaluating in the surface language directly [21], or (ii) the surface information sought is more limited than the reduction sequence we provide (in the same ways as for debuggers for optimizing compilers, as described earlier). Applying our results to this area is future work.…”