Lazy and Enforceable Assertions for Functional Logic Programs

Abstract

Abstract. Assertions or contracts are an important technique to improve the quality of software. Thus, assertions are also desirable for functional logic programming. Unfortunately, there is no established meaning of assertions in languages with a demand-driven evaluation strategy. Strict assertions are immediately checked but may influence the behavior of programs. Lazy assertions do not modify the behavior but may not be faithful since some assertions might not be checked at all. In order to avoid the disadvantages of strict and lazy assertions, we propose enforceable assertions that are delayed as lazy assertions but can be explicitly enforced at some point where faith is required, e.g., at the end of the program execution or before irrevocable I/O actions. We describe a prototypical implementation of this idea in the functional logic language Curry where the programmer can choose between lazy and enforceable assertions.

A semantics for lazy assertions

“…For lazy functional logic languages Hanus [16] proposed to allow the user to choose for each assertion whether it should be eager or lazy, depending on whether meaning preservation or faithfulness are essential. Assertion checking can even be delayed until a point in the program execution, e.g.…”

Contracts and Specifications for Functional Logic Programming

“…Note that the pre-and postcondition checkers are constraints rather than Boolean operations. This is useful for lazy assertion checking [16] since constraints can be concurrently evaluated.…”

“…Lazy assertions do not modify the behavior, but a lazily computed result cannot be trusted as long as some assertion has not been checked. As a compromise between these conflicting goals, enforceable assertions are proposed in [16]. These assertions behave like lazy assertions, but they can also be checked upon an explicit request of the programmer, e.g., at the end of a program run or at key intermediate execution points.…”

“…Similarly to other proposals for assertions or contracts for functional (logic) programs (e.g., [7,9,16]), we define pre-and postconditions as Boolean functions. An exception is [4] where constraints are used as conditions which was motivated by the use of postconditions as specifications instead of an explicit specification as in this work.…”

“…Thus, it is debatable whether full assertion checking should be avoided in order to preserve the behavior of programs [9,16]. Lazy assertions do not modify the behavior, but a lazily computed result cannot be trusted as long as some assertion has not been checked.…”