Comprehending finite maps for algorithmic debugging of higher-order functional programs

Abstract

Abstract. Bernie Pope introduced the idea of representing functional values as finite maps instead of partial applications into algorithmic debugging of higher-order functional languages. He implemented it in his Haskell debugger Buddha. Here we give an implementation-independent formal definition of algorithmic debugging for both representation in a single framework, even though the computation trees for the two representations have rather different structures. On this basis we prove the soundness of algorithmic debugging with finite maps. Our model shows how a single implementation can support both forms of algorithmic debugging. The proof exposed that algorithmic debugging with finite maps does not handle arbitrary functional programs, but in current practice the problematic ones are excluded by Haskell's type system. Both model and proof suggests variations of algorithmic debugging with finite maps and thus are tools for further improvement of this form of debugging.

A Lightweight Hat

“…Buddha can represent functional values as nite maps and Pope stated that a computation tree with functional values as nite maps has to have a structure that is di erent from the EDT. Subsequently Chitil and Davie (2008) de ned the new computation tree structure formally by relating it to the ART, named it the function dependence tree (FDT), and proved its soundness for algorithmic debugging.…”

Algorithmic debugging of real-world haskell programs: deriving dependencies from the cost centre stack

“…The expected result of the program is the ordered list [3,4,5], but when executed the program prints [3,5,4] instead. The program uses many standard library functions such as ++ and foldr that are trusted, that is, assumed to be correct.…”

“…Values such as integers and lists are given in familiar syntax, but functional values have an extensional representation as finite maps, from observed arguments to observed results. 3 Note that only the observed expression is annotated. Other parts of the program that actually produce the value, in particular the definitions of helper functions such as span and ++, are left unchanged.…”

“…Chitil and Davie [3] make the point that there are several structurally different computation trees for the same computation. They study two choices for making a computation statement f v f = v ′ f the parent of a computation statement g vg = v ′ g : either function identifier g appears in the definition of function f , or the application of g to vg appears in the definition of function f .…”

Algorithmic debugging of real-world haskell programs: deriving dependencies from the cost centre stack

“…Hence we omit monadic IO elsewhere in the paper 3. Parts of values, for example list elements, that are not demanded in the computation are just shown as underscore .…”