A semantics for lazy assertions

Olaf Chitil
2011 Proceedings of the 20th ACM SIGPLAN workshop on Partial evaluation and program manipulation - PERM '11  
Lazy functional programming languages need lazy assertions to ensure that assertions preserve the meaning of programs. Examples in this paper demonstrate that previously proposed lazy assertions nonetheless break basic semantic equivalences, because they include a non-deterministic disjunction combinator. The objective of this paper is to determine "correct" definitions for lazy assertions. The starting point is our formalisation of basic properties such as laziness, taking them as axioms of
more » ... design space. We develop the first denotational semantics for lazy assertions; assertions denote subdomains. We define a weak disjunction combinator and together with a conjunction combinator assertions form a bounded distributive lattice. From the established laws we derive an efficient prototype implementation of lazy assertions for Haskell as a library. let x = assert equal (True,False) in (fst x, snd x) raises an exception when evaluated. However, let us apply the basic program transformation of let-inlining and we get (fst (assert equal (True,False)), snd (assert equal (True,False))) Evaluating this snippet yields (True,False). No assertion exception is raised! The simple reason is that each of the two assertions only sees a partial value and both (True,⊥) and (⊥,False) have to be accepted by a lazy assertion as they are approximations of the functionalisation, which can improve performance. However, considering assertions as data that is interpreted by assert makes the implementation design easier, because definitions of interpreters are generally easier to understand than higher-order functions.
doi:10.1145/1929501.1929527 dblp:conf/pepm/Chitil11 fatcat:wl6o2i4ehbgudji34vdqclcufq