Observing Functional Logic Computations

Abstract

Abstract. A lightweight approach to debugging functional logic programs by observations is presented, implemented for the language Curry. The Curry Object Observation System (COOSy) comprises a portable library plus a viewing tool. A programmer can observe data structures and functions by annotating expressions in his program. The possibly partial values of observed expressions that are computed during program execution are recorded in a trace file, including information on non-deterministic choices and logical variables. A separate viewing tool displays the trace content. COOSy covers all aspects of modern functional logic multiparadigm languages such as lazy evaluation, higher order functions, non-deterministic search, logical variables, concurrency and constraints. Both use and implementation of COOSy are described.

Type Generic Observing

“…Thus with these frameworks we would need to provide type descriptions or a set of functions to every observe application. Previous research has shown that this approach gives problems with values of polymorphic types [1].…”

“…Most other Haskell compilers do not provide run-time type information. It would therefore be hard to implement the Hugs debugging primitives in these compilers [1]. HugsHood also extends Hood with an interesting "breakpoint" feature that shows the development of observations over time.…”

“…COOSy's observe function takes a type description, somewhat similar to the list of types we specify in our Partial Observe from Template approach (see Section 5.1). Partly this was done because Curry lacks a class system, but like our extension it also enables the user to specify per observation up to which type values are observed [1]. However unlike COOSy, we also allow to observe into a polymorphic value, at the cost of needing to add a class predicate to the type signature of the value under observation.…”

Lazy and Enforceable Assertions for Functional Logic Programs

“…Therefore, they are not parametrically polymorphic but their behavior depends on the structure of the concrete type. Hence, we adopt a technique used in observation debugging tools for functional (logic) languages [5,11] and put some information about the considered types as an additional argument of type "Assert a". 2 Furthermore, we also add a string argument that is used to identify the violated assertion when an exception is raised.…”

“…Although this test function is non-declarative (it has been introduced in [5] for a similar purpose), it is necessary to check the state of the argument in order to avoid its unintended instantiation. If the argument e evaluates to a free variable, it is unified (by the equational constraint "=:=") with the argument x and returned.…”