June 21, Reasoning about explicit strictness in a lazy language using mixed lazy/strict semantics Marko van Eekelen Maarten de Mol Nijmegen University, NL Technical Report NIII-R0402 (Revised Version at Not NIII-R 0408, 0415, 0416, 0427, …

June 21, Lazy semantics need to be extended Overview The Sparkle project: integrating programming and theorem proving focus on functional programming Some lazy/strict reasoning principles with  The strictness gap: programmers versus theoreticians Some basic reasoning examples The basis of strictness constructs in lazy languages Mixed lazy/strict semantics Conclusions and Future work

June 21, The Sparkle Project: Theorem Proving for Programmers Clean Compiler Function(s) Properties Sparkle: dedicated proof assistant Program with proof certificate Semantic reasoning level is the semantics of the programming language

June 21, Extensionality: However, is in head normal form and is undefined: So, and are not equal. An extra condition is needed (Abramsky): Now: Since the meaning of both and is undefined. So, and are semantically equal for each.

June 21, Due to laziness an extra base step for the undefined case is required.  y  [A]: P (y) P(  ) P([])  x  A  xs  [A]: P (xs)  P([x:xs]) Without this extra step we could e.g. easily prove that every list is finite. Induction Furthermore, P has to be admissible (Paulson).

June 21, The strictness gap Theoreticians view on strictness: A derived formal property –Mathematical property of semantic function definitions –Undecidable property, approximated via a safe analysis using abstract interpretation, abstract reduction or some type inference system Programmers view on strictness: A programming decision –Essential for efficiency of data structures –Essential for efficiency of evaluation –Essential for enforcing the evaluation order in interfaces But programmer defined strictness has an effect on definedness.

June 21, Closing the gap Mathematical view on strictness: x =   f x =  Operational view on strictness: Reduce argument to weak head normal form before evaluating the function application Notation for Strictness: Merely annotation, no semantics Mixed semantics: Notationally strict => operationally strict => mathematically strict For reasoning a mixed strict/lazy graph rewriting semantics is needed

June 21, Reasoning about Clean functions: Strict equality:  == True is  True==  is  Lazy and:  && False is  False&&  is False Lazy or:  || True is  True||  is True Reasoning on the predicate level: Logical identity:   True is False True   is False Logical and:  True is ill-formed but used as shorthand for:  = True  True is False True   is False Logical or:  True is True True   is True Basic lazy-strict reasoning - 1

June 21, Basic lazy-strict reasoning - 2 Consider the following property It is not valid if both x and y are  ! What does hold is the following: Many properties do hold unconditionally, e.g:

June 21, A property of isMember x = , xs  [ ], p y = False x  , xs = [ , x], p y = False x = 2, xs = [2:xs], p y = False x = 2, xs = [3], p y = if (y == 2) True (p y)...

June 21, A case for which P does not hold x = 2, xs = [3], p y = if (y == 2) True (p y) Then: p x = True isMember x xs = False filter p xs = [  ] isMember x (filter p xs) =  So, P (x,xs,p) :=  = False && True Hence P does not hold in this case.

June 21, How to express this in Sparkle, which is first order?

June 21, Expressing Properties The auxiliary function to express finiteness of lists: Definedness of an object x: Totality of a predicate p: Finiteness of lists:

June 21, The basic construct: let! (partially) strict data structures user annotated function arguments unboxed arrays special primitives like seq or #! They can all be expressed easily with a single construct, the let!-construct: Lazy semantics must be extended to express the meaning of let!.

June 21, Launchbury’s semantics

June 21, Extra rule for mixed semantics

June 21, Basic Idea

June 21, Define Meaning Extra rule for mixed semantics: Lazy Semantics:

June 21, Proving Mixed Semantics Correctness Computational Adequacy

June 21, Folklore Strictness Knowledge A.Expressions that are bottom lazily, will also be bottom when we make something strict. B.When strictness is added to an expression that is non-bottom lazily, either the result stays the same or it becomes bottom. C.Expressions that are non-bottom using strictness will (after !-removal) also be non-bottom lazily with the same result.

June 21, Expressions: Switching from Mixed to Lazy Semantics Environments :

June 21, Formal Strictness Knowledge

June 21, Distinguishing different terms In Launchbury’s lazy semantics and have a different meaning but they can not be distinguished. With mixed semantics and are different and they can be distinguished.

June 21, Conclusions/Future Work Conclusions Mixed semantics are needed for reasoning in Haskell and Clean Mixed semantics essentially extend lazy semantics Future Work Extend mixed graph rewriting semantics extend the logic with single step semantics Full Integration of prover and language towards programming with proven properties