June 21, 2004 1

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 www.cs.kun.nl/~marko/research)

Not NIII-R 0408, 0415, 0416, 0427, …

June 21, 2004 2

Lazy semantics need to be extendedOverview• The Sparkle project:

integrating programming and theorem provingfocus 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, 2004 3

The Sparkle Project: Theorem Proving for Programmers

Clean Compiler

Function(s)

Properties

Sparkle:dedicated

proof assistant

Programwith proof

certificate

Semantic reasoning level is the semantics of the programming language

June 21, 2004 4

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, 2004 5

Due to laziness an extra base step for the undefined case is required.y[A]: P (y)

• P()• P([])xAxs[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, 2004 6

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, 2004 7

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, 2004 8

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 FalseLogical or: True is True

True is True

Basic lazy-strict reasoning - 1

June 21, 2004 9

Basic lazy-strict reasoning - 2Consider 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, 2004 10

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, 2004 11

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, 2004 12

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

June 21, 2004 13

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, 2004 14

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, 2004 15

Launchbury’s semantics

June 21, 2004 16

Extra rule for mixed semantics

June 21, 2004 17

Basic Idea

June 21, 2004 18

Define Meaning

Extra rule for mixed semantics:

Lazy Semantics:

June 21, 2004 19

Proving Mixed Semantics

Correctness

Computational Adequacy

June 21, 2004 20

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, 2004 21

Expressions:

Switching from Mixed to Lazy Semantics

Environments:

June 21, 2004 22

Formal Strictness Knowledge

June 21, 2004 23

Distinguishing different terms

• In Launchbury’s lazy semantics and

have a different meaningbut they can not be distinguished.

• With mixed semantics and

are different and they can be distinguished.

June 21, 2004 24

Conclusions/Future WorkConclusions• Mixed semantics are needed for reasoning

in Haskell and Clean• Mixed semantics essentially extend lazy

semanticsFuture Work• Extend mixed graph rewriting semantics

extend the logic with single step semantics• Full Integration of prover and language

towards programming with proven properties