Abstract

Debugging tools are a practical need for helping programmers to understand why their programs do not work as intended. Declarative programming paradigms involving complex operational details, such as constraint solving and lazy evaluation, do not fit well to traditional debugging techniques relying on the inspection of low-level computation traces. As a solution to this problem, and following a seminal idea by Shapiro (Shapiro, 1982), declarative debugging (a.k.a. declarative diagnosis or algorithmic debugging) uses Computation Trees (shortly, CTs) in place of traces. CTs are built a posteriori to represent the structure of a computation whose top-level outcome is regarded as a symptom of the unexpected behavior by the user. Each node in a CT represents the computation of some observable result, depending on the results of its children nodes, using a program fragment also attached to the node. Declarative diagnosis explores a CT looking for a so-called buggy node which computes an unexpected result from children whose results are all expected. Each buggy node points to a program fragment responsible for the unexpected behavior. The search for a buggy node can be implemented with the help of an external oracle (usually the user with some semiautomatic support) who has a reliable declarative knowledge of the expected program semantics, the so-called intended interpretation.

Full Text
Published version (Free)

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call