Proving properties of lazy functional programs with Sparkle

Marko van Eekelen

2008

visibility

…

description

308 pages

link

1 file

Abstract

This tutorial paper aims to provide the necessary expertise for working with the proof assistant Sparkle, which is dedicated to the lazy functional programming language Clean. The purpose of a proof assistant is to use formal reasoning to verify the correctness of a computer program. Formal reasoning is very powerful, but is unfortunately also difficult to carry out. Due to their mathematical nature, functional programming languages are well suited for formal reasoning.

Figures (40)

Fig. 1. An elemental Int iTask when started (left) and finished (right)

Fig. 2. An (Int,Real) iTask when started (left) and finished (right) simple :: Task Person HtmlDate is a predefined algebraic data type for which an editor is created that allows the user to manipulate dates with separate editors for the year, month, and day. The only thing we need to do is to change the signature of simple into:

Fig. 3. A Person iTask when started (left) and finished (right)

Fig. 4. A Person iTask attributed to be a ‘classic’ form editor 2.4 Sequencing with Monads: Wadler’s Exercise

4.5 Reasoning Style in SPARKLE

Fig. 2. Screen shot of the SPARKLE proof window at the same proof state as in Fig.

Fig. 3. The diamond property

Fig. 6. An implementation of the list The list of expressions E,, E,-1,..., Ey is denoted by [E,, En-1,..., 1]. It is . recursive data structure. A possible representation uses pairs: a list is a pair. vhere the first element is true, if it is an empty list and false otherwise. The econd element of the pair is relevant only in case of non-empty lists: this is alsc . pair consisting of the element and the representation of the tail of the list. vhich contains all but the first element of the list. Figure[6]shows the graphica epresentation of this structure.

Fig. 7. An implementation of the simple numeral system The definition of the functions are as follows:

Fig. 1. Sequence of steps that reduces a nested application @ @ @ AAA ep e1 e2 €3

The lower abstraction o accomplished application. the cut matches each abstractor with an apply node. part (b) shows a corner in which the lambs sequence is longer thai the apps sequence, i.e., we have a partial application that (-reduces to a nev f lesser arity, which would be 2 in the particular case. This can b by means of an 7-extension-in-the-large, as also introduced in th preceding subsection, that transforms the entire apps — lambs corner into a ful The added apply nodes have the deBruijn indices #0 and #1 in their tails, and all free occurrences of deBruijn indices in the head and the tail of the origina apps sequence are stepped up by 2, as annotated at the respectiv edges, to account for the two A-nodes introduced by the 7-extension.

Fig. 6. (@-distributing cuts over the branches of the spine

represents a full application (the graph in the upper part of the figure). Distributing this cut over the next corner of the spine squeezes it in front of the tails and the head of its apps-sequence. This corner must be 7-extended by two A|@ pairs to form another cut B for a full application (the graph in the middle of the figure), which in turn is 3-distributed over the head and the tails of the remaining corner of the spine (the graph at the bottom). This corner consti- tutes a full application as it is, forming a cut C. This cut is trivially distributed just in front of the head index #1, i.e., it remains in place. If in cut C we now expand the copy of cut B that makes up its left-hand eorner and likewise in eut BR eynand the eonny of cut A an the left we ohtain This spine features a leading lambs-sequence to which have been lifted the A-abstractors that have been introduced by 7-extensions. It is followed by a single left-hand corner that connects an apps sequence of length 10 with a lambs sequence of length 9, i.e., we have in fact unfolded, by means of repeated 1- xtensions and (-distributions (...-in-the-large) what was the original cut C to nine G-redices. This new cut C includes cut B which, in turn, includes cut A|!° Having thus straightened the original spine, we can finally contract, in one conceptual step to which we may refer as (-reduction-in-the-large, all (-redices of the original spine that have now accumulated in a single cut C’, thereby com- dletely consuming it. The resulting reductum depends on the deBruijn index #i n the head of the spine, which happens to be the entire body of the abstraction ormed by the lambs-sequence preceding it.

Fig. 8. The spine of fig. [7] 7-extended by another cut L for the leading As, and showing ULC values replacing all 7-extended deBruijn indices

Fig. 11. Traversing the expression k a & bc from stack C' to S' via stack M

Organizing the environment as a structure of linked frames is due to the need to share, as a matter of efficiency, common parts among environments that belong to different contexts. A typical example is a tail suspension that comes with an environment £ contained in a larger environment £2 of which the suspension is an entry. Substituting this suspension for a head index and evaluating it in this place means that new environment frames must be created on top of E2 but linked up to the environment FE by a pointer that bridges the zap between the tops of Ey and Fj. WA so Bn as i a es ee a or ee ee a ec a ee ee

The graph pointer then advances down the spine along the chain of head pointers p;, and pushes into the trace stack pointers to suspensions for tail ex- pressions until the next A-cell is reached. This A-cell now controls the creation of an environment frame by filling it from the trace stack either with suspension pointers as the cell’s arity parameter demands or until these pointers are prema- turely exhausted, in which case the topmost A-cell (the pointer to which is at the bottom of the trace stack) pops to the top, indicating unapplied As. In this atter case, the remaining frame entries are filled with ULCs and the number of ULCs pushed is added to the arity of the A-cell in the trace stack, thus in fact completing an 7-extension. Fig. 15. Trace stack and environment after having reached the head of the spine

Fig. 16. Linking up to a head-normalized suspension in the head of a spine

Fig. 1. The level hierarchy for some of the examples in the paper 2 A Simple Example

The expected types are taken from the type declaration accompanying the func- tion definition. The computed type is computed from the known types of the constructors and functions in the definition. The equalities are generasted by equating the expected type and the computed type. The left-hand-side equali- ties (to the left of the =) let us assume n= S b. The right-hand-side equalities, require us to establish that {plus n m} = S{plus b m}. Using the assump- tion that n = S b, we are left with the requirement that {plus (S b) m} = S{plus b m}, which is easy to prove using the definition of plus. The different levels of the objects introduced in this example (and elsewhere in the paper) are plotted in Figure[I] The reader may wish to consult the figure

We now define the type Nat’, which is identical structurally to the type SNat. As such, the type Nat’ is also a singleton type representing the natural numbers, but it relies on a feature of the (Qmega type system. In Qmega (as in Haskell) the name space for values is separate from the name space for types. Thus it is possible to have the same name stand for two things. One in the value space, and the other in the type space. The pun is because we use the names S and Z in both the value and type name spaces. We exploit this ability by writing:

Balancing Constructors. The algorithms for insertion and deletion each fol- low the same basic pattern: First do the insertion (or deletion) as you would fo1 any other binary search tree. Then re-balance any subtree that became unbal- anced in the process. The tool used for re-balancing is tree rotation, which is best described visually.

The code for del is an elaborate case analysis. The first decision to make is whether we’re at the right spot for deletion. If so, then do the deletion (or not, depending on whether the value exists in the tree) and return. If not, make the appropriate recursive call and then rebalance. Most of the work goes into determining how to rebuild a balanced tree by choosing the correct Balance value or rebalancing constructor.

Under the assumptions, both parts of the equality in the requirements for the right-hand-side reduce to (Binary Bit t2 2t), so the clause is well typed. Iterating add3Bits, we can construct a ripple carry adder, whose type states that it is really an addition function!

‘ig. 4. Merging occurrences of Nr+1 3.2 Merge Expression Duplicates The next transformation is somewhat similar to Extract Function. The idea is again the reduction of redundancy in the code. Within a function definition, multiple occurrences of the same expression should be localized, and a fresh variable should be introduced which will hold the pre-computed value of the expression. All the occurrences of the expression should than be replaced with a reference to the variable. This technique is illustrated in Fig. [4] where the occurrences of Nr+1 in loop/3 are replaced with the fresh variable NextNr. Tha tarm “miltinle nrerirrancee nf the cama evnreeann” noaede anmea mnra

Fig. 5. Eliminating variable MoreUsers 3.4 Rename Variable

expression. It is also possible that the same unbound variable occurs more than once in a pattern: in that case the same value should be bound to it at every occur- rence, otherwise the matching fails. For example, if X is an unbound variable, the pattern {X,X} matches the expression {1,1}, but it does not match {1, 2}. One could interpret this mechanism in an alternative way, as follows. When a pattern is matched against matched a subpattern which is an unbound variable is matched, the variable becomes bound; next time when the already corresponding subexpression. The problem with this alternative interpretation is t the are firs suc ing on able application). 1 bind ow it is possible the applied occurrence of Z (that is on t hat it against the subex bound, so its bound is not possible to 12] The varia tern are considered binding occurrences, is more rationa h a variable in a special way: althoug ble Z is bound by an expression, the subpatterns of the pattern are pressions of the expression in some order. Whenever variable, being another subpattern, is matched, it is value should merely be compared to the value of the tell which occurrence of the variable in the pattern is ing occurrence, because the order in which the su processed is not specified (it might bpatterns of a pattern be compiler-dependent). Therefore the t interpretation, namely that all occurrences of an unbound variable in a pat- . RefactorErl handles h the variable has more than one bind- occurrences inside the pattern, the pattern as a whole is considered a single binding place for the variable. This can be illustrated on the left-hand side of Fig. branch of the case-expression, and Z has The only applied occurrence of Z is the one in the body of the same case-branch. to apply the Merge Expression Duplicates transformation on he expression made up of a single vari- This expression appears only once in the code, so it is a rather the function definition the pattern of the first two binding occurrences in this pattern. Fig. 12. Computing the greatest common divisor of two positive integers

.2. Performance of the Basic Compiler In Fig. I] we compare the performance of the basic compiler with that of the interpreter and of the GHC and Clean compilers. If we compare the basic com- piler with the interpreter we see that the basic compiler is about 40% faster (speed-ups between 10 and 60%)