PDF hosted at the Radboud Repository of the Radboud University
Nijmegen
The following full text is a preprint version which may differ from the publisher's version.
For additional information about this publication click this link.
http://hdl.handle.net/2066/72147
Please be advised that this information was generated on 2017-06-15 and may be subject to
change.
P ro v in g p rop erties
o f lazy fu n ction al program s w ith S parkle
M aarten de Mol, M arko van Eekelen and Rinus Plasm eijer
{maartenm, marko, rinus}@cs.ru.nl
Institute for Computing and Information Sciences
Radboud University Nijmegen, The Netherlands
A b s tr a c t. 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 m athematical nature, functional programming languages are
well suited for formal reasoning. Moreover, SPARKLE offers specialized
support for reasoning about CLEAN, and is integrated into its official
development environment. These factors make SPARKLE a proof assistant
th at is relatively easy to use.
This paper provides both theoretical background for formal reasoning,
and detailed information about using SPARKLE in practice. Special atten­
tion will be given to specific aspects th a t arise due to lazy evaluation and
due to the existence of strictness annotations. Several assignments are
included in the text, which provide hands-on experience with SPARKLE.
1
In tro d u c tio n
In 2001, th e d istrib u tio n of th e lazy functional program m ing language C lea n [5,
27,28] was exten d ed w ith th e dedicated proof assistan t S p a r k l e . T he purpose
of a proof assistan t is to verify th e correctness of a com puter program w ithout
executing it. T his is accom plished by m eans of th e m ath em atical process of
form al reasoning, which m akes use of th e source code of th e program and the
sem antics of th e program m ing language.
S pa r k l e is in ten d ed as an additional tool for th e CLEAN-programmer and
aim s to m ake form al reasoning accessible. It is conveniently in te g ra ted into the
official D evelopm ent E nvironm ent of C l e a n , allows reasoning on th e level of
th e program m ing language itself and offers dedicated su p p o rt for dealing w ith
CLEAN-programs. U nfortunately, form al reasoning is a com plex m ath em atical
process th a t requires specialized expertise. Therefore, it is often still difficult to
carry out, even in ded icated proof assistants such as S p a r k l e .
In practice, S p a r k l e has already been applied for various purposes. It has
been used for proving p ro p erties of I/O -p ro g ra m s by Butterfield[7] and Dowse[12].
In [29,17], Tejfel, H o rv ath and Koszik have proposed an extension for it for
dealing w ith tem p o ral properties. S u p p o rt for class-generic properties has been
added to it by van Kesteren[19]. F urtherm ore, it has also been used in education
at th e R ad b o u d U niversity of Nijmegen.
T he purpose of th is p a p er is to provide th e inform ation th a t is necessary
for functional program m ers to s ta rt m aking use of S p a r k l e . A com bination of
b o th th eo retical an d p ractical expertise will be provided. No special knowledge
is required to u n d e rsta n d th e contents of th is paper: a basic u n d erstan d in g of
lazy functional languages and elem entary logic suffices. U pon com pletion of this
paper, th e read er will be able to use S p a r k l e to prove basic properties of sm all
CLEAN-programs w ith m inim al effort. F urtherm ore, a solid foundation will be
laid for proving p ro p erties th a t are m ore complex.
T his p a p e r is stru c tu re d as follows. F irst, th e concept of form al reasoning
will be explained in d ep en d ently of S p a r k l e in Section 2. T hen, th e im p o rtan t
design principles of S p a r k l e will be sum m arized in Section 3, and th e ir effect
on th e way th a t form al reasoning is im plem ented will be explained. T hen, in
Sections 4 an d 5 a tu to ria l of th e use of S pa r k l e in practice is presented.
T he first p a rt (Section 4) presents a step-by-step intro d u ctio n of all th e basic
features of S p a r k l e ; th e second p a rt (Section 5) describes several advanced
features th a t are specific for S p a r k l e . We discuss related work in Section 6 and
draw conclusions in Section 7. Finally, th e com plete ta ctic lib ra ry of S p a r k l e
is sum m arized sep arately in A ppendix A.
T he tu to ria l is w ritte n in e x p lan ato ry style and contains various assignm ents
w ith w hich th e provided th eo ry can be p u t into practice. T he answ ers to these ex­
ercises can be found a t h ttp ://w w w .cs.ru .n l/ m arko/research/sparkle/cefp2007/.
2
F o rm a l re a s o n in g
In th e following sections, a general in tro d u ctio n to form al reasoning will be
p resented in d ep en d en tly of S p a r k l e . In Section 2.1, form al reasoning will first
be described as an a b stra c t process th a t transform s in p u t to desired o u tp u t. In
Section 2.2, th e underlying form al fram ew ork will be identified; th is fram ework is
a prerequisite for carrying o u t form al reasoning. T he m ost im p o rta n t com ponent
of th e fram ew ork is th e proof language, which will be explored in m ore detail
in Section 2.3. Finally, th e soundness of form al reasoning will be discussed in
Section 2.4.
2 .1
T h e a b s t r a c t p r o c e s s o f f o r m a l r e a s o n in g
Form al reasoning is a m ath em atical process th a t fully takes place on th e formal
level. T he goal of form al reasoning is to verify th e correctness of some kind of
form al o b ject by m eans of reasoning a b o u t it. T he process as a whole can roughly
be characterized as follows:
1. Form alize an o bject o;
2. Form alize a p ro p e rty p th a t says som ething ab o u t o;
2
3. B uild a form al pro o f th a t shows th a t p holds for o.
If form al reasoning succeeds and a form al proof is built, th e n it is shown w ith
absolute certa in ty th a t th e form alized object o behaves as specified by m eans
of p ro p e rty p. T his holds for all environm ents in which o m ay occur, because
th e form al pro o f is obliged to take all possible circum stances into account. As
such, a positive result of form al reasoning is m ore powerful th a n for instance a
positive resu lt of testing, which is restricted by th e test-set th a t was used.
If form al reasoning does n o t succeed in building a proof, however, th en not
m uch inform ation has been gained. It m ay either be th e case th a t o is incorrect,
or it m ay be th e case th a t th e desired behavior of o was incorrectly specified by
p , or it m ay sim ply be th e case th a t th e proof builder did n o t build th e proof in
th e right way. A negative result of form al reasoning is h ard to in terp re t correctly
and is therefore less useful th a n a negative result of for instance testing.
2 .2
F o rm a l fra m e w o rk
Form al reasoning m akes use of th e form al representations of th e object to reason
ab o u t (in p u t), th e p ro p e rty to prove (input) and th e proof to be b u ilt (o u tp u t).
Moreover, to ascertain th e soundness of reasoning (see Section 2.4), a formal
sem antics th a t assigns a m eaning to properties m ust be available as well. T he
com bination of these prerequisites of reasoning will be called a form al framework:
D e f in itio n 2 .2 .1 : (formal framework)
A form al fram ew ork is a tu p le (O, P, \=o, - o) such th a t:
• O is th e set th a t contains all possible objects to reason about;
— 4 (o € O denotes th a t o is a valid object to reason about)
• P is th e set th a t contains all possible p ro p erties th a t m ay be specified;
— 4 (p € P denotes th a t p is a valid p ro p erty to prove)
• \=o is th e relatio n th a t defines th e sem antics of properties;
— 4 (No p denotes th a t p € P holds in th e context of o € O)
• \-o is th e derivation system th a t defines proofs of properties.
— 4 ( - o p denotes th a t a proof of p € P exists in th e context of o € O)
(T he form al fram ew ork of S p a r k l e is described com pletely in [21]. In the
rem ainder of th is paper, it will be tre a te d im plicitly only.)
N ote th a t th e elem ents of a fram ew ork are connected: it m ust be possible to
refer to com ponents of objects w ithin properties; th e sem antics of a p ro p erty
can only be determ in ed in th e context of a given object; and th e derivation of a
proof depends on a given o bject as well.
Using th e n o tatio n s in troduced by th e form al fram ework, form al reasoning
can now be characterized as follows:
D e f in itio n 2 .2 .2 : (formal reasoning)
Form al reasoning is th e process th a t given a form al fram ework (O, P, \=o, —o),
a specific o b ject o € O and a specific p ro p e rty p € P , a tte m p ts to determ ine
w hether —o p holds or not. From th e soundness of th e form al fram ew ork it
th e n follows th a t No p holds as well.
3
In o th e r words, th e goal of form al reasoning is to determ ine \=o by m eans of h o.
T his approach only m akes sense for fram ew orks in which h o is less com plicated
th a n No, which is often th e case, because derivation system s are usually sim pler
th a n sem antic relations.
2 .3
P r o o f la n g u a g e
T he m ost im p o rta n t com ponent of th e form al fram ew ork is th e proof language,
which is usually rep resented by m eans of a derivation system . T he derivation
rules of th is system are reasoning steps th a t form th e building blocks of proofs.
B uilding proofs is basically th e rep eated application of these reasoning steps,
and can be ch aracterized as follows:
— G o a l: prove a p ro p e rty p.
— A p p ly : reasoning step R. T his transform s p to p i , . . . , p n . If n = 0, th e n the
pro o f is com plete (R proves p). O therw ise, p i , .. . , p n becom e th e new goals
w hich all have to be proved recursively by th e sam e reasoning process.
— G o a l: prove all p ro p erties p 1, . . . ,p n .
In o th er w ords, reasoning steps are functions th a t tran sfo rm propositions into
(possibly m ore) propositions, and th e proof language is th e set of functions
th a t one is allowed to apply during reasoning. F urtherm ore, reasoning itself is
‘g o al-b u stin g ’: a t each p o in t in tim e a num ber of propositions (goals) have to
be proved, an d these propositions can be simplified (busted) by m eans of the
rep eated applicatio n of predefined reasoning steps.
T he resu lt of reasoning is a derivation tree in w hich th e nodes are propositions
(an d th e ro o t node is th e initial proposition to prove) and each set of edges
leading from a single node corresponds w ith a reasoning step. Edges in th is tree
do n o t necessarily have to lead to an o th er node, because reasoning steps m ay
produce th e em p ty list of propositions. T he leaves of th e tree are th e propositions
th a t still have to be proved.
T he derivation tree is of course th e formal rep resen tatio n of a proof. It can
easily be serialized, provided th a t th e reasoning steps are nam ed. A serialized
proof can be tran sferred to anyone w ith knowledge of th e formal fram ew ork th a t
it uses. F urtherm ore, th e receiver can even auto m atically check th e validity of
th e proof by re-running it. N ote th a t validating proofs is easy, because it only
requires th e form al fram ew ork, b u t building proofs is difficult, because it requires
th e continuous selection of th e ‘rig h t’ reasoning step.
2 .4
S o u n d n e s s o f f o r m a l r e a s o n in g
B uilding form al proofs is an exercise in th e rep ea te d sim plification of propositions
according to predefined reasoning steps. This, however, is a purely syntactic
exercise th a t does n o t take th e actual m eaning of propositions into account in
any way. In o rder for th e results of reasoning to be m eaningful, th e underlying
form al fram ew ork m ust be sound as well:
4
D e f in itio n 2 .4 .1 : (soundness o f form al frameworks (1))
A form al fram ew ork (O, P, \=o, - o) is sound if for all o € O and p € P it holds
th a t —o p im plies No p.
Because -o is com posed of individual derivation rules, th e soundness of a formal
fram ew ork as a whole can be determ ined by verifying these rules as follows:
D e f in itio n 2 .4 .2 : (soundness o f a derivation rule)
A derivation rule R € - o is sound if for all p € P it holds th a t No (pi A . .. A p n )
im plies No p, assum ing th a t R (p) = p i , . . . ,p n .
D e f in itio n 2 .4 .3 : (soundness o f form al frameworks (2))
A form al fram ew ork (O ,P , \=o, - o) is sound if all its derivation rules R € - o
are sound.
Form al reasoning only m akes sense if th e underlying form al fram ew ork is sound.
Soundness should therefore preferably be proved explicitly. If th e com plexity of
th e derivation system m akes th is to o difficult, th e n some degree of confidence can
still be gained from practice (‘no u n tru e propositions have ever been proved, so it
m ust be c o rre c t’), b u t th is weakens th e results of form al reasoning considerably.
T he soundness of th e form al fram ew ork of S pa r k l e has been proved in [21].
Finally, n ote th a t for th e usefulness of form al reasoning it is im p o rta n t th a t
th e reverse p ro p e rty of com pleteness (for all properties p, No p im plies —o p) holds
too. Full com pleteness is extrem ely difficult to achieve for com plex frameworks.
Using pro o f theory, however, it can usually be approxim ated quite closely.
3
D e s ig n p r in c ip le s o f S pa r k l e
T he m ain purpose of SpARKLE is to allow functional program m ers to reason
ab o u t th e CLEAN-programs th a t th ey are developing, which im proves th e quality
of th e pro g ram as a whole. T he reasoning su p p o rt th a t S pa r k l e offers is in the
first place tailo red tow ards th is m ain purpose, although in general S p a r k l e is
also useable for anyone who would like to reason a b o u t functional program s. In
p articu lar, a frontend for H a s k e l l ’98 is curren tly being added to C l e a n , which
in th e fu tu re would allow reasoning a b o u t m ixed CLEAN/HASKELL-programs.
In th e following sections, th e effect th a t th e m ain purpose of SpARKLE has
on its design will be explored closely. In Section 3.1, first th e intended users
of S pa r k l e will be analyzed in detail. T hen, in Section 3.2 a list of resulting
consequences for th e design will be presented. Finally, th e im p o rta n t consequence
of ded icated reasoning will be explored in detail in Sections 3.3 and 3.4.
3 .1
I n t e n d e d u s e r s : f u n c tio n a l p r o g r a m m e r s
T he in ten d ed users of S p a r k l e are functional program m ers, or m ore specifically
anyone who has dow nloaded th e CLEAN-distribution and is developing program s
w ith it. O f course, th ere is m uch diversity in this group, and th ere is no such
th in g as ‘th e functional p ro g ram m er’. Still, for th e sake of design, we will make
th e following te n ta tiv e assum ptions a b o u t th e intended users of S p a r k l e :
5
— th e y do n o t necessarily have m uch experience w ith form al reasoning, and
m ay n o t even know a b o u t it a t all;
— th e y often have some theoretical background, and usually have a t least a
basic u n d erstan d in g of elem entary logic;
— th e y usually have good knowledge of functional program m ing in general and
of C lea n (and its sem antics) in specific;
— th e y are not necessarily aware of th e benefits of form al reasoning for the
purpose of im proving th e quality of software;
— th e y are m ainly in terested in th e program s th a t th e y develop.
O th er pro o f assistan ts m ay be geared tow ards different users; for instance, the
m ajo r independent pro o f assistan ts (such as for instance P v s [23] and CoQ [30])
are m ainly in ten d ed for logicians who already know ab o u t form al reasoning and
are in terested in it as well.
3 .2
D e s ig n c h o ic e s
SpARKLE im plem ents a th eo retically sound form al fram ework, and therefore fully
su p p o rts general form al reasoning on th e fundam ental level. In its design, how­
ever, S p a r k l e focuses m ainly on functional program m ers as its intended users.
T he m ost im p o rta n t choices in th e design of SpARKLE are:
— T he object language should be C l e a n , because th is allows program m ers to
reason on th e level of th e program m ing language, which is th e ir area of
expertise. A lthough th is has n o t been realized fully, a good approxim ation
by m eans of C o r e - C l e a n has been ad o pted by S p a r k l e (see Section 3.4).
— For th e property language, it suffices to use a sta n d a rd first-order logic which
has been exten d ed w ith an equality on a rb itra ry program expressions. In such
a logic m ost com m on p roperties can be expressed easily. Moreover, functional
program m ers are likely to be capable of handling sta n d a rd first-order logic.
T he p ro p e rty language will be in troduced in th e tu to ria l in Section 4.3.
— T he semantics of th e p ro p erty language should conform to th e sem antics of
C l e a n . T his ensures th a t properties th a t are proved w ith S p a r k l e hold for
th e real-w orld CLEAN-program as well. T his is achieved by giving ‘e 1 = e2’
th e m eaning ‘it is possible to interchange e 1 w ith e2 in any program w ithout
changing its observational beh av io r’. T he full sem antics will be introduced
on an inform al level in th e tu to ria l in Section 4.4.
— Form al reasoning should be integrated w ith program m ing, such th a t sw itch­
ing betw een th e tw o activities becom es easy. T his m akes form al reasoning
m ore a ttra c tiv e , because it is linked to an activ ity th a t is carried o u t contin­
uously. T he in teg ratio n of S p a r k l e is realized by allowing it to be sta rte d
d irectly from th e ID E (Integ rated D evelopm ent E nvironm ent) of C l e a n , in
w hich case th e cu rren t pro ject is loaded a u to m atically in S p a r k l e .
— T he reasoning steps of S p a r k l e should be specialized for dealing w ith lazy
functional program s in general, and for dealing w ith C l e a n in specific. In
p articu lar, lazy evaluation and explicit strictness have a profound influence
6
on sem antics, an d therefore on reasoning as well. T he specialized features of
S pa r k l e will be described in Section 5.
— T he first impression of S p a r k l e should be positive, and should entice pro­
gram m ers to continue w ith form al reasoning. T his is realized by S p a r k l e ’s
a ttra c tiv e user interface (see tu to rial), and by allowing sm all proofs to be
carried o u t a u to m atically w ith th e h in t m echanism (see Section 4.5).
— S pa r k l e should have u p -to -d ate and extensive docum entation. T his paper
is th e first a tte m p t to achieve th is goal.
T he design choices w ith th e m ost profound influence on S p a r k l e are th e level
of th e o b ject language an d th e specialization of th e reasoning steps. T he conse­
quences of th e level of th e object language will be exam ined fu rth er in Sections
3.3 an d 3.4; th e specialized features of S pa r k l e will be described in detail later
in Section 5.
3 .3
D e d i c a t e d v s g e n e r a l- p u r p o s e f o r m a l r e a s o n in g
If one w ants to ad d su p p o rt for form al reasoning to a specific program m ing
language, tw o different approaches can be taken:
1. B uild o n e’s own dedicated proof assistant th a t d irectly su p p o rts reasoning
on th e level of th e program m ing language itself; or
2. B uild a shell aro u n d an existing general-purpose proof assistant, com bined
w ith a tra n sla tio n m echanism to and from its object language.
C urrently, several good general-purpose proof assistan ts are available in prac­
tice, such as for instan ce P v s [23], CoQ [30] and I sa b e l l e [25]. These proof
assistan ts all have a large user base and m ake use of well-developed formal
fram ew orks th a t are extrem ely expressive and powerful. In th e shell approach,
such a w ell-established form al fram ew ork is re-used autom atically, w hich is a
m ajo r advantage.
U nfortunately, general-purpose proof assistants have a m ajo r disadvantage as
well: none have an o b ject language th a t fully su p p o rts th e sem antics of C l e a n ,
which is based on lazy g raph-evaluation w ith explicit strictness. Therefore, the
evaluation m echanism of th e proof assistant cannot be re-used, and an in terp reter
for C lea n has to be b u ilt com pletely w ithin th e object language of th e general­
purpose pro o f assistan t. T his has th e following im p o rta n t draw back:
actual reasoning no longer takes place on the level of the CLEAN-program,
but instead on a meta-representation of it in the object language o f the
general-purpose proof assistant
From th e p ro g ram m er’s p o int of view, however, it is crucial th a t reasoning at
least appears to be tak in g place on th e level of th e CLEAN-program. In th e case
th a t a general-purpose pro o f assistant is used, it is therefore th e ta sk of th e shell
to hide th e underlying m eta-level com pletely from th e end user. Consequently,
applying a reasoning step in a shell actually requires th ree activities: (1) tra n sla te
7
th e pro g ram an d th e reasoning step to th e m eta-level; (2) execute th e reasoning
step on th e m eta-level; (3) tra n sla te th e feedback back to th e program m ing level.
To sum m arize, th e shell approach has th e advantage th a t a w ell-established
form al fram ew ork is re-used, b u t th e disadvantage th a t an in te rp re ter and a
two-way tra n sla tio n an d com m unication m echanism have to be realized. We feel
th a t th e general-purpose approach poses m ore practical problem s th a n it offers
advantages; therefore, we have chosen to m ake use of th e dedicated approach.
In hindsight, S p a r k l e has been th e result of only a b o u t 18 ‘m an -m o n th s’ of
work, which shows th a t w riting one’s own dedicated proof assistan t is certainly
doable. We estim ate th a t w riting a shell would have tak en considerably m ore
effort. O n th e o th e r hand, th e form al fram ew ork of S p a r k l e does lack some
expressiveness, b u t th is has tu rn e d o u t to be only a slight disadvantage for
reasoning a b o u t functional program s.
3 .4
S p a r k l e ’s a p p r o x i m a t i o n o f d e d i c a t e d r e a s o n in g
S pa r k l e is a ded icated pro of assistan t and aim s to su p p o rt form al reasoning on
th e level of th e program m ing language itself. C l e a n , however, is a real-w orld
program m ing language w ith an extensive sy ntax and lots of syntactical sugar.
Reasoning on th e level of C lea n requires explicit su p p o rt for all of its constructs,
b o th on th e p ractical level (definition of reasoning steps) and on th e theoretical
level (sem antics). U nfortunately, th e com plexity of C l ea n m akes it extrem ely
difficult to use it as th e o b ject language of a form al reasoning framework.
It is im p o rta n t th a t form al reasoning itself is as easy as possible. For this
purpose, S p a r k l e sim ply can n o t o p erate on th e level of full C l e a n . Instead, a
sim plification of C l ea n will be used. T his simplified version of C lea n is called
C o r e -C lea n and is actu ally th e in term ed iate rep resentation of th e com piler.
A lthough S p a r k l e does n o t allow reasoning on th e level of C lea n itself, using
C o r e -C lea n is still a good approxim ation of dedicated reasoning, because:
— C o r e - C l e a n has th e same expressive power as C l e a n .
In o th er words: any CLEAN-program can be transform ed to an equivalent
C oR E -program , on which reasoning w ith S pa r k l e is possible. F urtherm ore,
th e tran sfo rm atio n itself has already been im plem ented in th e actual C l e a n com piler. B ecause b o th S p a r k l e and th e com piler are w ritte n in C l e a n ,
th e existing tran sfo rm atio n can be re-used. T his n o t only saves a lot of tim e,
b u t also ensures soundness of th e transform ation.
— C o r e - C l e a n is a subset of C l e a n .
P ro g ram s in C o r e - C lea n can easily be u n d ersto o d by CLEAN-programmers,
because th e y m ake use of th e sy n tax and sem antics of C l e a n . U nderstanding
th e p rogram to reason ab o u t is vital for th e success of form al reasoning.
— P ro g ram s in C o r e - C l e a n are very similar to th e ir CLEAN-originals.
T his ensures th a t m uch of th e p ro g ram m er’s expertise of th e source program
is still valid on th e C o r e -C l ea n level. A gain, th is greatly increases the
u n d erstan d in g of th e program to reason about.
8
T he language C o r e -C lea n will be defined inform ally in th e T utorial in Section
4.1. T here, th e feature of S pa r k l e to present C oR E-program s as if th ey were
CLEAN-programs will also be explained. T his feature brings C o r e -C lea n even
closer to C l e a n .
4
T u t o r i a l p a r t I: g e t t i n g s t a r t e d w i t h S p a r k l e
In th e following sections, a step-by-step in tro d u ctio n of th e basic functionality
of S pa r k l e will be presented. T he in tro d u ctio n covers th e user interface, the
specification of program s and properties, th e sem antics, and th e th ree different
su p p o rted styles of reasoning. A t various places assignm ents are included, w ith
th e purpose of giving th e reader th e o p p o rtu n ity to gain hands-on experience
w ith th e S p a r k l e pro o f assistant.
T he tu to ria l will be continued in Section 5, in which th e specialized features
of S p a r k l e will be described. A su m m ary of all available reasoning steps is given
in A ppendix A.
4 .1
L o a d in g a p r o g r a m
T he first step of form al reasoning w ith S p a r k l e is loading a CLEAN-program
into its m emory. T his pro g ram provides th e context inform ation th a t is required
for sta tin g an d proving properties. T he fastest way of sta rtin g S p a r k l e and
loading a pro g ram is by m eans of th e sta n d a rd ID E of C l e a n , in which access
to S p a r k l e has been integrated:
A s s ig n m e n t 1: (loading a program into SPARKLE automatically)
(a ) O pen th e CLEAN-project p r i m e s .p r j in th e Examples\CEFP folder.
(b ) E xam ine th e code of th e m ain m odule ( p r i m e s .i c l ) and a tte m p t to predict
th e behavior of th e program . T hen, compile and ru n th e program .
(c ) F in d th e Theorem P ro v e r P r o j e c t option and use it to launch SPARKLE.
Internally, S pa r k l e m ain tains its own rep resentation of th e program . In this
representation, a pro g ram is sim ply considered to be a list of (interdependent)
m odules, and each m odule is considered to be a list of definitions. S p a r k l e does
not distinguish betw een th e definition ( .d c l ) and im plem entation ( . i c l ) p a rts
of a m odule an d allows access to all com ponents of a program a t any tim e.
Program := = Module*
Module := = Definition*
Definition := = Algebraic Type | Record Type | Function | Class | Instance
SpARKLE has a powerful graphical user interface th a t allows th e stru c tu re of the
loaded pro g ram to be in spected in detail:
A s s ig n m e n t 2: (browsing through the program structure)
(a ) F in d th e window th a t displays th e list of m odules th a t are curren tly loaded.
In th is list, find th e p rim e s m odule and open it.
9
(b ) T he opened window actually filters all available definitions w ith th e form ula
‘functions from th e p rim e s m o d u le’. C hange th e filter to find all functions
in S t d L i s t an d S tdF unc th a t begin w ith th e le tte r ‘s ’.
T he user interface also allows each individual definition of th e loaded program
to be displayed in a sep arate window. F urtherm ore, these definition windows are
in terconnected by m eans of th e sym bols th a t are used w ithin it:
A s s ig n m e n t 3: (browsing through the program components)
(a ) O pen th e definition of th e function is P rim e in th e p rim e s m odule.
(b ) Follow th e in tern al link to th e canBeDividedByAny function.
(c ) Follow th e in tern al link to th e predefined rem function.
S p a r k l e is a dedicated pro o f assistan t th a t aim s to su p p o rt reasoning on th e level
of th e program m ing language. U nfortunately, reasoning on th e level of C l e a n
is n o t practical, because of th e m any different syntactical co nstructs th a t are
allowed. Therefore S p a r k l e uses C o r e - C l e a n , which is basically th e subset of
C l e a n in w hich all sy n tactic sugar has been rem oved, as interm ediate reasoning
language. T he only rem aining definitions in C o r e - C l e a n are algebraic types
and global functions, an d expressions m ay only be con stru cted by m eans of
applications, case d istin ctio n and lets.
Even th o u g h C o r e -C lea n is a sm all language only, all CLEAN-programs
can be represented in it. W hen a CLEAN-program is loaded into S p a r k l e , it is
always au to m atically converted to C o r e -C l e a n . As a result, th e program in the
m em ory of S p a r k l e differs from th e original C l ea n version. Some im p o rta n t
differences betw een th e CLEAN-program and its CoRE-CLEAN-equivalent are:
— all local functions have been lifted to th e global level;
— all p a tte rn m atches have been transform ed to case distinctions;
— all sharing has been expressed by m eans of recursive lets;
— all overloading has been expressed by m eans of dictionaries;
— all synonym ty p es an d m acro’s have been expanded fully;
— all list com prehensions and dot-dot-expressions have been transform ed to
function applications.
F ortunately, th e differences betw een th e in ternally loaded C o r e - C lea n program
and th e original C lea n version only have a slight effect on reasoning, and are
therefore h a rd ly noticeable m ost of th e tim e. F urtherm ore, th e user interface of
S pa r k l e is able to optionally display p a rts of C o r e -C lea n program s in the
sy n tax of th e ir original C lea n versions:
A s s ig n m e n t 4: (effect o f the optional display options)
(a ) O pen th e function definitions is P rim e and canBeDividedByAny from the
p rim e s m odule an d sp an from th e S t d L i s t m odule.
(b ) Toggle th e display options P a t t e r n M a tch in g and C a s e /L e t v s # / ! . T he
‘re a l’ C o r e -C lea n program is displayed w hen th e options are toggled off.
(c ) T here is one difference betw een th e in ternal version of is P rim e and the
C l ea n version th a t cannot be hidden. W h a t is th is difference?
10
4.2
U n d e fin e d n e ss in C lean a n d C ore -C lean
As in any o th e r program m ing language, co m putations in C o r e -C lea n and in
C lea n can te rm in a te erroneously. T his can hap p en in a num ber of situations,
for exam ple w hen dividing by zero, or w hen a p a rtia l function is applied to an
argum ent for which it was n o t intended. A dditionally, C lea n even offers two
sta n d a rd functions th a t always te rm in a te erroneously, nam ely a b o r t and u n d e f .
One of th e features of lazy languages is th a t it is possible for a co m p u tatio n
to produce a (p artial) end result, even w hen it contains sub co m p u tatio n s th a t
te rm in a te erroneously. T his is only possible, however, w hen th e sub co m p u tatio n
is n o t needed for producing th e end result at all.
A s s ig n m e n t 5: (partial undefinedness in practice)
(a ) O pen th e u n d e f in e d p ro ject w ith th e ID E. R un and com pile it.
(b ) R eplace th e b o d y of m y_undefined w ith an o th er com p u tatio n th a t also
term in ates erroneously.
(c ) Cycle th ro u g h th e available S t a r t bodies and exam ine th e ru n -tim e results.
A form al m odel of C lea n needs to be able to handle expressions th a t contain
undefined subexpressions. For th is purpose, C o r e -C l ea n defines th e additional
expression altern ativ e ‘± ’. T his co n stan t expression is tre a te d as a base value
of any type, because a co m p u tatio n of any ty p e can term in a te erroneously. All
different kinds of errors are tre a te d equally; therefore, only one ± suffices and it
does n o t need additio n al argum ents.
N ote th a t ± is a special value w ith special characteristics. It cannot be used
as a p a tte rn , or in a case d istinction. In fact, it is not possible a t all in C lea n
to produce a defined resu lt based on a successful check of undefinedness.
A s s ig n m e n t 6: (undefinedness cannot be detected)
(a ) W h a t fam ous (unsolvable) problem would be solved if it was possible to
d etect undefinedness w ithin a C lea n program ?
4 .3
S ta tin g a p ro p e rty
A p ro p e rty in S p a r k l e is a logical statem en t, eith er tru e or false, th a t deals w ith
th e executional behavior of a CLEAN-program. P ro p erties can be used to sta te
th a t th e pro g ram functions correctly w ith respect to its specification. E xpressing
th e desired behavior of a program by m eans of properties is very useful.
S p a r k l e allows p ro p erties to be expressed in an extended first-order logic.
T he usual logic o p erato rs — (not), A (and), V (or), ^ (implies) and ^ (iff) are
su p p o rted , as well as th e q u an to rs V (for all) and 3 (exists), and th e co n stants
TRUE an d FALSE. V ariables and quantors can range over propositions and over
expressions of an a rb itra ry type, b u t n o t over predicates or relations of any kind.
To s ta te p ro p erties of program s, th e logic also su p p o rts equality on expressions.
11
Prop := = VarProp
| TRUE | FALSE
| —Prop | Prop A Prop | Prop V Prop | Prop ^ Prop | Prop ^ Prop
l ^VarProp 'Prop | V yarExpr .Prop | 3 varProp .Prop | 3 y arExpr .Prop
| E xpr = Expr
M any concepts of th e p roposition level are also available on th e expression level,
which can be a little confusing. N ote for instance th e subtle differences between:
— T rue an d F a ls e , which are expressions of ty p e B ool, and TRUE and FALSE,
w hich are propositions;
— n o t, && an d ||, w hich are CLEAN-functions th a t o p erate on values of type
B ool, and —, A an d V, which are o p erators th a t connect propositions;
— ==, which is an overloaded CLEAN-function th a t produces a B ool and m ust
be defined m anually for each type, and = , which produces a proposition and
is available a u to m atically for each type.
(the CLEAN-function == is computable and cannot compare undefined values,
while the fo rm a l = is not computable and can compare undefined values; this
additional expressiveness is really important, because m any properties have
definedness preconditions that could otherwise not be expressed)
A ssum ing th e context of th e p rim e s project, exam ples of p ro p erties are:
1.
2.
3.
4.
5.
6.
V pV q .(P A Q) ^ (Q A P )
17 > 12 = T rue
V fV xsV ys.map f (xs ++ ys) = map f xs ++ map f ys
Vxs.r e v e r s e ( r e v e r s e xs) = xs
VnVxs.(n < l e n g t h xs = T rue) ^ le n g t h (ta k e n xs) = n
ViVj .(i > j = T rue A j > 0 = T rue) ^ p rim e s !! i > p rim e s !! j = T rue
O f these properties, th e first does n o t refer to any com ponent of th e program ; in
fact, it is a tautology which is independent of any program . T he second p ro p e rty
refers to th e function >, which is defined for integers in th e m odule S td I n t. T he
th ird , fo u rth an d fifth p ro p erties refer to th e functions map, ++, r e v e r s e , ta k e
and l e n g th , which are all defined in th e m odule S td L is t. T he six th property,
finally, is th e only p ro p e rty th a t is really specific for th e p rim e s project. It
not only depends on th e sta n d a rd functions > and !! , b u t also on th e p rim e s
function of th e p rim e s m odule.
A s s ig n m e n t 7: (validity of the example properties)
(a ) O f th e six exam ple properties, only five are tru e, and one is in fact false (it
needs an additional precondition). W hich one is false?
(Hint: lists m ay be infinite in C l e a n )
(b ) W h a t h ap p en s to th e six th p ro p e rty if eith er i or j is undefined?
T he only way to en ter p ro p erties in S pa r k l e is by m eans of te x tu a l in p u t. T he
p arser allows th e n a tu ra l sy n tax to be used, w ith th e following conventions:
12
— ~P denotes —P ;
— P / \ Q denotes P A Q;
— P \ / Q denotes P V Q;
— P -> Q denotes P ^ Q;
— P <-> Q denotes P ^ Q;
— _ |_ denotes ± ;
— [x] denotes Vx ; and
— {x} denotes 3 x .
Type-checking of propositions is perform ed auto m atically by S p a r k l e . D uring
th is check, th e types of th e variables are inferred as well. A lternatively, it is also
possible to explicitly specify th e ty p e of a variable in a quantor. These explicit
types m ay contain ty p e variables, which are im plicitly assum ed to be b o und by
universal q uantors. T yped qu an to rs are denoted by:
— [ x : : a ] denotes Vx::a; and
— { x : : a } denotes 3 x..a .
A s s ig n m e n t 8: (specify the example properties (1))
(a ) Use New Theorem to m anually enter all six exam ple properties.
(Hint: in case of failure, a tte m p t to add brackets)
A s s ig n m e n t 9: (specify properties with overloading)
T he m anual specification of types is essential w hen m aking use of overloading:
(a ) W ith o u t explicit types, a tte m p t to specify VxVy .x + y = y + x.
(b ) Use explicit types ( x :: I n t , y :: I n t ) to help S p a r k l e solve th e overloading
in VxVy.x + y = y + x.
For th e sake of convenience, SpARKLE offers two features to m ake th e m anual
specification of p ro p erties easier:
— E ach free sym bol in th e proposition is assum ed to be a variable, and a
universal q u a n to r is created auto m atically for it. T his feature allows universal
q u an to rs to be o m itte d w hen specifying properties. It also m eans, however,
th a t m istyping th e nam e of an identifier, or using an identifier th a t is not
defined by th e cu rren t program , does not lead to a bind error, b u t instead
resu lts in an incorrect universal quantor.
— W hen possible, boolean expressions are auto m atically lifted to propositions
by im plicitly adding ‘= T ru e ’. T his feature shortens specifications, b u t m ay
also lead to confusion betw een th e expression and th e proposition level. N ote
th a t th e ‘= T ru e ’ beh ind a lifted boolean expression is n o t even displayed
by S p a r k l e if th e B o o lean P r e d i c a t e s display option is tu rn e d on.
A s s ig n m e n t 10: (specify the example properties (2))
(a ) Specify th e exam ple p roperties again, using th e features described above.
Do not q u it S p a r k l e afterw ards.
13
S pa r k l e organizes theorem s and proofs into sections, m uch in th e sam e way as
C l ea n organizes definitions into m odules. Sections are stored in a sem i-readable
in tern al form at in S p a r k l e ’s \ S e c t i o n s subdirectory. T heorem s and (p arts of)
proofs can be assigned to individual sections, which m ust th e n be saved explicitly.
A w arning to new users: S p a r k l e does not save sections autom atically, and does
not p ro m p t you to do so either!
A s s ig n m e n t 11: (save properties into sections)
(a ) C reate a new section w ith th e nam e temp.
(b ) O pen b o th th e m ain section and th e tem p section.
(c ) Move th e exam ple p ro perties from th e m ain section into th e tem p section.
(d ) Save th e tem p section and q u it S p a r k l e .
O f course, sections can be loaded into S p a r k l e as well. Because th e contents
of a section m ay d epend on various o th er com ponents, th e following actions are
carried o u t w hen a section is loaded:
— F irst, it is verified if th e sym bols are available th a t are required for sta tin g the
p ro p erties of th e section. If th is is not th e case, th e n th e section is n o t loaded
a t all. O therw ise, theorem s are created for th e properties of th e section. T he
proofs them selves, however, are not loaded yet.
— T hen, th e sections are loaded recursively th a t contain th e theorem s th a t are
used w ithin th e proofs of th e top-level section.
— Finally, th e proofs of th e section are loaded and carried o u t again, step by
step. If a step fails, which m ay be th e case if a definition w ithin th e program
has been altered (b u t its nam e and ty p e were unchanged), th en th e proof is
loaded p a rtia lly u n til th e error point.
A fter th is process, it can be guaran teed th a t th e in tern al sta te of SpARKLE is
consistent, an d th a t all proofs th a t were loaded successfully are valid.
A s s ig n m e n t 12: (load sections into m em ory)
(a ) S ta rt S p a r k l e m anually (directly and n o t from w ithin th e ID E ).
(b ) A tte m p t to load th e predefined section l i s t s .
(c ) O pen th e p rim e s p ro ject from w ithin S p a r k l e .
(d ) Load th e predefined section l i s t s .
(e ) Load th e section tem p of th e previous assignm ent.
4 .4
T h e m e a n in g o f p r o p e r t i e s
T he m eaning of p ro p erties is described by a form al algorithm th a t determ ines
w hether a given property, in th e context of a given program , is tru e or false.
T his algorithm is expressed a t th e form al level only, and cannot be executed in
practice, n eith er by a h um an nor by a com puter. If it could be executed, formal
reasoning would n o t have been necessary in th e first place.
14
A m eaning m ust be provided for all alternatives of SpARKLE’s first-order
logic, which was in tro d u ced in Section 4.3. T his logic contains b o th sta n d a rd
elem ents (TRUE, FALSE, —, A, V, ^ , ^ , V on propositions, 3 on propositions)
and custom ized ones (= , V on expressions, 3 on expressions). T he m eaning of
th e sta n d a rd elem ents is th e sam e as in sta n d a rd logic, which we assum e to be
well-known. T he m eaning of th e custom ized elem ents is as follows:
— T he equality e i = e2 holds if for all program s P th e observational behavior
stays th e sam e if ei is interchanged w ith e2 (or vice versa, e2 w ith e i). T he
observational behavior of a program is th e visible o u tp u t th a t is produced
w hen it is executed. S p a r k l e cannot deal w ith program s th a t perform I/O ;
therefore, only o u tp u t th a t is displayed on th e console is considered.
To be able to d eterm ine th e equality betw een observational behaviors, it has
to be tak en in to account th a t program s m ay n o t term in ate, and th a t the
o u tp u t th a t th e y produce m ay be infinite. O n th e form al level, observational
behavior is therefore m odelled by tim e indexed streams, and bisimulation
is used to d eterm ine equality. O n th e intuitive level, th is is equivalent to
assum ing th a t infinite tim e is available to program s, and th a t th e resulting
infinite stream s are equal only if all th eir finite substream s are equal.
Finally, n ote th a t it is not possible to determ ine if e i and e2 are sem antically
equal based only on th e observational behaviors of th e program s S t a r t =
e 1 an d S t a r t = e2. T his is because e 1 and e2 m ay be functions th a t only
produce m eaningful o u tp u t w hen th e y are supplied w ith argum ents.
— T he universal quantification Vx .P holds if for all wellformed expressions E
th e in sta n tia te d p roposition P [x ^ E] holds. A n expression E is wellformed
if th e resulting P [x ^ E] is b o th closed and w elltyped.
N ote th a t th e undefined expression ± is always a valid value for E , because
it is closed an d of any type. F urtherm ore, if th e dom ain of x allows for it,
infinite expressions are also valid values for E .
— T he m eaning of th e ex istential quantification 3 x .P is defined in th e sam e
w ay as th e universal quantification.
A s s ig n m e n t 13: (examples o f (in)equality)
(a ) Are ‘o n e s ’ an d ‘l e t x = [1 :x ] i n x ’ equal? If so, argue; if not, give the
pro g ram th a t distinguishes betw een them .
(b ) Same question for ‘o n e s ’ and ‘on es ++ o n e s ’.
(c ) Sam e question for ‘o n e s ’ and ‘ [2] ++ o n e s ’.
(d ) Same question for ‘o n e s ’ and ‘on es ++ [ 2 ] ’.
(e ) Sam e question for ‘± ’ and ‘ [1: ± ] ’.
( f ) Sam e question for ‘± ’ and ‘A x .± ’.
(H in t: m ake use of explicit strictness)
(g ) Same question for ‘± ’ and ‘l e t x = x i n x ’.
(H in t: only basic values and constructors are m eaningful o u tp u t)
4 .5
R e a s o n in g s ty le in S pa r k l e
As m ost m o d ern d ay pro o f assistants, S p a r k l e is based on th e L C F -approach.
T his m eans th a t reasoning takes place by th e rep e ate d sim plification of a list of
15
goals by m eans of th e application of tactics. T his process of reasoning was first
intro d u ced by th e LCF[16] proof assistant, and has since been nam ed after it.
A goal is a p ro p e rty th a t still has to be proved, represented in such a way th a t
it can be m an ip u lated easily in th e reasoning process. A tactic is a function from
a single goal to a list of goals, such th a t th e sem antic validity of th e produced
goals im plies th e validity of th e original one. Therefore, applying ta ctics is sound,
because a proof of th e p roduced goals is also a proof of th e original goal.
A pro o f is represen ted by a tree in which th e nodes are goals and th e edges
are tactics. T he ro o t in such a proof tree contains th e original p ro p e rty th a t
one w ants to prove, and th e leaves hold th e goals th a t still need to be proved.
T he application of a final tactic, which is a tac tic th a t produces th e em pty list
and therefore im m ed iately proves th e source goal, closes a leaf. T he proof of a
p ro p e rty is com plete w hen all th e leaves in its proof tree have been closed.
A s s ig n m e n t 14: (backwards proving)
(a ) W hy is S p a r k l e ’s reasoning style som etim es also called backwards proving?
D uring reasoning, th e proof state consists of a list of goals th a t correspond to the
leaves of th e pro o f tree. T he active goal being m an ip u lated is called th e current
goal; th e o thers are called subgoals. A goal corresponds to a p ro p e rty th a t has
been broken dow n in to in troduced variables, in troduced hypotheses, and a ‘to
prove’. If x i , . . . , x n are th e introduced variables, H i : P i , . . . , H m : P m are the
intro d u ced hypotheses, an d Q is th e to prove, th e n th e goal corresponds to the
p ro p e rty Vx i ...xn .Pi ^ .. .Pm ^ Q. B y breaking down properties, its com ponents
can be accessed m uch m ore easily in a proof.
A Proof State
^I
Context of this Goal
__ I_________ Current Goal
n e Int
H I: n * 1
A Goal
take n 1 ++ drop n 1 = 1
Fig. 1. A proof state
A s s ig n m e n t 15: (decompose the property)
T he pro o f sta te s in Fig. 1 and Fig. 2 are taken from an actu al proof.
(a ) W hich p ro p e rty corresponds to th e cu rren t goal in Fig. 1?
(b ) W hich p ro p e rty was th e sta rtin g p o in t of th e proof?
16
1
Theorem: take ++ drop
in section: lists i
proving: sub goal 1 of 3 (see below)
Assume variables:
n : : Iu t
(d e fin e d )
Assume hypotheses:
HI: -i [n = _L)
t a k e ti X ++ drop ti _L
±
ill
• subgoat 1 : t a k
• sub goal 2: V n .- ,( n = X )
t a k e ti [] ++ d r o p n [] = []
• subgoa! 3: V xV xs. ( V ti.- ,(n - X> — t a k e n x s ++ d r o p n x s - x s ) —
-Ll
*
= X)
ta k e n
x : x s ] ++ d r o p n
d
<11
i T
induction.
Fig. 2. Screen shot of the SPARKLE proof window at the same proof state as in Fig. 1.
4 .6
P r o v i n g a s im p le p r o p e r t y
In th is section, we will use S pa r k l e to prove a sim ple p ro p e rty which concerns
th e behavior of th e map function from th e sta n d a rd environm ent of C l e a n .
A s s ig n m e n t 16: (specification o f a property of mapj
(a ) O pen S p a r k l e from scratch, th e n load th e sta n d a rd environm ent (C trl-E ).
(b ) C reate a new section w ith th e nam e m ap _ sectio n .
(c ) In m ap _ sectio n , create a new theorem nam ed m ap _ p ro p erty , stating:
V f VxSVyS.map f (xs ++ ys) = map f xs ++ map f ys
(d ) O pen th e pro o f window (C trl-P ) th a t corresponds to th e created theorem .
B uilding a pro o f is th e rep e a ted process of selecting tactics and applying th e m on
th e cu rren t goal. For th is process, S p a r k l e m akes a to ta l of 39 tactics available,
which are all described briefly in A ppendix A. T he user interface of S p a r k l e
allows ta c tic s to be applied by m eans of th ree different m ethods:
— T he hin t mechanism, which is activated by opening th e Tactic Suggestion
W indow durin g proving. T his window holds a dynam ically u p d a te d list of
suggestions for ta c tic s th a t can be applied to th e cu rren t goal. S p a r k l e
generates these suggestions auto m atically based on b u ilt-in heuristics. Each
suggestion is assigned a score betw een 1 and 100 th a t indicates th e likelihood
of th a t ta c tic being helpful in th e proof. B ased on th is score, th e suggestions
are ordered. A suggested tactic can be applied by either clicking on it, or by
m eans of its associated hot-key (F1 for th e first hint, F2 for th e second, etc.).
It is also possible to configure S p a r k l e to apply th e to p hint au tom atically
if it has a score higher th a n a m anually set threshold.
T he h in t m echanism is m ainly for beginning S p a r k l e users. It is fast and
easy to use, an d requires little expertise of th e available tactics (sim ply tru st
S p a r k le ! ) . T he h in t m echanism is a valuable tool th a t can be used as a
m eans of learning SpARKLE, and w ith which m any sm all proofs can be built
fully. However, it is n o t very powerful and by no m eans failsafe. Som etim es
th e right ta c tic is n o t suggested, or several w rong tactics get high scores.
— T he tactic dialogs. E ach tactic has its own dialog th a t can be opened by
clicking on its nam e in th e T actic L ist W indow. T his dialog has entries for
all th e argum ents th a t can be given to th e tactic. W hen possible, th e current
17
goal is used to restrict th e in p u t to valid values only. W hen all argum ents
have been entered, th e tac tic can be applied from th e dialog directly.
T he ta c tic dialogs are for intermediate users. T his m eth o d of proving is
b o th powerful, because all tac tics can be applied this way, and fairly easy,
because one does n o t need to m em orize th e nam e or sy ntax of a tactic, nor
th e argum ents th a t it requires.
— T he com mand line interface. T his is a te x tu a l interface th a t is for advanced
users only. It is powerful, b u t requires extensive expertise of S p a r k l e and
its tactics. However, once m astered, it is th e fastest way of building proofs,
because all ta c tic s can be applied th is way and it does n o t require opening
ad d itio n al dialogs a t all.
T he p ro p e rty of map th a t was given above is very easy and can therefore be
proved au to m atically w ith th e h in t m echanism :
A s s ig n m e n t 17: (proving the map property with the hint m echanism)
(a ) O pen th e T actic Suggestions W indow (C trl-H ) and set th e th reshold to 1.
(b ) Set th e th resh o ld back to 101. W hy is this necessary prior to (c)?
(c ) E n te r - ^ R e s ta r t. ► at th e com m and-line interface.
(From now onn, -^cmd. ► will be used to denote textual input to the commandline. For reasons of parsing, these commands have to end with a closing ‘. ’,
otherwise SPARKLE will not be able to recognize them.)
(d ) Redo th e pro o f by applying suggestions m anually w ith th e hot-keys.
T he com plete pro o f tree of th e exam ple p ro p e rty has now been stored in ternally
by S p a r k l e . B y m eans of th e T heorem Info W indow , th is proof tree can be
brow sed an d inspected in detail:
A s s ig n m e n t 18: (browsing through the proof)
(a ) O pen th e T heorem Info W indow of th e com pleted proof.
(b ) Click ‘brow se’ after th e first tac tic and th e n browse th ro u g h th e proof using
th e ‘p revious’ an d ‘n e x t’ b u tto n s.
(c ) U ndo th e first application of R e f le x iv e only.
(d ) Click on th e brow n s ta r to re tu rn to th e P ro o f W indow.
(e ) Use a different ta c tic to prove th e goal.
T he h in t m echanism has succeeded in com pleting th e proof autom atically, and
it did n o t require any ex pertise a t all. T he dow nside to this, unfortunately, is
th a t no u n d erstan d in g of th e ta ctics has been gained in th e process. Therefore,
below we will present th e entire proof again, and th is tim e we will explain each
ta c tic th a t was applied too.
T he in itial goal is sim ply th e p ro p erty to be proved:
Vf VxsVys.map f (xs ++ ys) = map f xs ++ map f ys (1)
Because b o th map an d ++ are tail-recursive, stru c tu ra l induction on xs is likely to
be useful here. T his is accom plished by applying th e tactic -^ In d u c tio n x s . ►.
18
T h ree new goals(1.1,1.2,1.3) are created: one for th e case th a t xs is _L; one for th e
case th a t xs is N il; an d one for th e case th a t xs is an application of Cons. N ote
th a t L is a base value of any ty p e and is therefore always tre a te d b y induction
as a co n stru cto r case.
Vf Vy5.map f
++ ys) = map f ^ ++ map f ys
(i.i)
Fig. 3. Screen shot of SPARKLE at proof state (1.1)
T h e cu rren t propo sitio n s ta rts w ith two universal quantifications, on w hich it
does not m ake sense to perform induction (on f it is n o t possible, and on ys
it does not help because ++ is not tail-recursive in its second argum ent). It is
therefore best to apply ^ I n t r o d u c e f y s . ^ , w hich removes th e q u antors and
introduces th e variables f and xs in th e context of th e goal. A fter th is action,
th e m ain propo sitio n can be accessed m ore easily.
f :: b ^ a, ys :: [b]
(i.i')
map f (^ ++ ys) = map f ^ ++ map f ys
D ue to th e strictn ess of map and ++ and th e presence of L argum ents, redexes
are present in th e cu rren t goal. T he tac tic ^R ed u ce NF A ll. ► can be used to
19
reduce all redexes in th e cu rrent goal to norm al form. W ith o th e r p aram eters, the
ta c tic Reduce can also be used for stepwise reduction, reduction to ro o t norm al
form, red u ctio n of one p a rtic u la r redex and reduction in th e goal context.
f :: b ^ a, ys :: [b]
± = ±
T his is clearly a triv ial goal, because equality is a reflexive relation. Such reflexive
equalities are proved im m ediately w ith th e final tac tic -^ R e fle x iv e . ►.
Vf Vys.map f ([] ++ ys) = map f [] ++ map f ys
(1.2)
T his is th e second goal of induction, crea ted for th e case th a t xs is th e em pty
list. A gain, in d u ctio n m akes no sense for f and ys, and th e y should therefore be
intro d u ced in th e goal context by m eans of -^ In tro d u c e f y s . ►.
f :: b ^ a, ys :: [b]
map f ([] ++ ys) = map f [] ++ map f ys (1.2')
T here are again redexes present in th e cu rren t goal, because b o th map and ++
have p a tte rn s th a t m atch on th e em pty list []. Therefore: -^Reduce NF A l l . ►.
f :: b ^ a, ys :: [b]
[] = []
(1.2'')
T his is an o th er exam ple of a reflexive equality; therefore -^ R e fle x iv e . ►.
VxVxs.
(VfVys.map f (xs ++ ys) = map f xs ++ map f ys)
^ (Vf Vys.map f ( [ x : xs] ++ ys) = map f [ x : xs] ++ map f ys)
(1.3)
T his is th e th ird goal created by induction for th e case th a t xs is a com posed
list. T he cu rren t goal looks quite com plicated, b u t in tro d u ctio n can m ake things
a lot clearer. Here, we will n o t only introduce variables from universal quantors,
b u t we will also introduce hypotheses from im plications. T his can be perform ed
in one go w ith - ^ In tro d u c e x x s IH f y s . ^ .
x :: b, xs :: [b ], f :: b ^ a, ys :: [b]
IH : Vf Vys.map f (xs ++ ys) = map f xs ++ map f ys (1.3')
map f ( [ x : xs] ++ ys) = map f [ x : xs] ++ map f ys
Again, th e cu rren t goal contains redexes, because map and ++ have p a tte rn s th a t
m atch on co n stru cted lists of th e form [ x : x s ] . Therefore, ^R ed u ce NF A l l . ^ .
20
x :: b , xs :: [b] , f :: b ^ a, ys :: [b]
IH V fVys.map f (xs ++ ys) = map f xs ++ map f ys
[ f x map f (xs ++ ys)] = [ f x : map f xs ++ map f ys]
(1.3")
T he cu rren t p roposition is now of th e form [X:Y] = [X :Z ]. Using th e a u to m atic
injectiv ity of all lazy d a ta co n structors in C l e a n , we can sim plify th is to X = X
A Y = Z. Therefore, - ^ I n j e c t i v e . ►.
A s s ig n m e n t 19: (injectivity and strictness)
(a ) W hy does injectiv ity n o t hold for stric t d a ta constructors?
x :: b, xs :: [b] , f :: b ^ a, ys :: [b]
IH : Vf Vys.map f (xs ++ ys) = map f xs ++ map f ys (1.3'")
f x = f x A map f (xs ++ ys) = map f xs ++ map f ys
T he cu rren t p roposition is now of th e form P A Q, and can obviously be split into
subgoals P an d Q. Therefore, - ^ S p lit. ►, which creates subgoals 1.3.1 and 1.3.2.
x :: b, xs :: [b] , f :: b ^ a, ys :: [b]
IH : Vf Vys.map f (xs ++ ys) = map f xs ++ map f ys (1.3.1)
f x = f x
T his is a reflexive equality th a t can be proved im m ediately w ith -^ R e fle x iv e . ►.
x :: b, xs :: [b] , f :: b ^ a, ys :: [b]
IH : Vf Vys.map f (xs ++ ys) = map f xs ++ map f ys (1.3.2)
map f (xs ++ ys) = map f xs ++ map f ys
T he cu rren t p roposition is now an in sta n tia tio n of th e induction hypothesis IH.
It can therefore be proved im m ediately by applying I H w ith ^ A p p ly IH. ►.
Q.E.D.
T here are no m ore subgoals, which m eans th a t th e proof is complete!
A s s ig n m e n t 20: (manual proof o f the map property)
(a ) Prove th e map p ro p e rty again, using th e tactic dialogs only.
(b ) Prove th e map p ro p e rty again, using th e com m and interface only.
(Hint: -^Reduce. ► abbreviates ^R ed u ce NF A l l . ^ , and - ^ I n t r o s . ► is a
v arian t of in tro d u ctio n th a t comes up w ith suitable nam es on its own)
(c ) T he a u to m atic pro o f consists of th e application of 13 tactics. It is possible
to prove th e p ro p e rty in less steps (our sh o rtest proof consists of 9 steps).
T ry to sh o rten th e proof yourself.
A s s ig n m e n t 21: (more small proofs)
Try to prove th e following properties, preferably w ithout th e hint m echanism :
(a ) Vxs'iys'izs.xs ++ (ys ++ zs) = (xs ++ ys) ++ zs.
(b ) y xs.—(xs = ± ) ^ —(xs = []) ^ [hd x s : t l xs] = xs.
(c ) VnVXs — (n —^_) —^ t a k e n xs + + d ro p n xs — xs.
(d ) VpV q .(—P ^ Q) ^ ( P ^ —Q).
21
5
T u to r ia l p a r t II: s p e c ia liz e d f e a tu r e s o f S pa r k l e
In th is section, th e tu to ria l will be continued w ith advanced inform ation about
th e ded icated use of S p a r k l e in practice, and th e features th a t are specialized
for reasoning a b o u t C lea n will be described. T he sam e ex p lan ato ry style will be
used as in p a rt I of th e tu to ria l, and various assignm ents will again be included.
F irst, in Section 5.1 th e im portance of sharing in proofs will be explained.
T hen, th e specification of definedness conditions in properties will be described
in Section 5.2. T he specialized behavior of four tactics will be in troduced next; for
‘E x ten sio n ality ’ in Section 5.3, for ‘In d u ctio n ’ in Section 5.4, for ‘D efinedness’ in
Section 5.5, an d for ‘R educe’ in Section 5.6. Finally, th e specification of properties
by m eans of CLEAN-functions will be discussed in Section 5.7.
5 .1
T h e in f lu e n c e o f s h a r in g o n r e a s o n in g
Sharing is im p o rta n t for th e efficiency of functional program s. In C lea n sharing
is explicit, because for every co n stru ct it is precisely defined w h at is shared and
w hat is n o t shared[28]. T he sem antics of C lea n are based on graph rew riting
[2, 26, 3]. T his m eans th a t d uring reduction of th e S t a r t expression to its result,
sharing is m ain tain ed as m uch as possible.
In S p a r k l e , red u ctio n m ay be used at m any points in proofs as well. This
reduction should behave in a sem antically equivalent way to reduction in C l e a n ,
b u t it does n o t have to be exactly th e sam e. N ote th a t reduction in S p a r k l e is
sym bolic, because it m ay encounter free variables th a t are in troduced by logic
q uantors. In C l e a n , red u ction only operates on closed expressions.
Sharing has no influence on sem antics, and reduction in S p a r k l e is free to
eith er preserve or b reak it. C urrently, th e following stra te g y is realized:
— W ithin th e application of reduction sharing is always preserved;
— B u t afterwards sharing is always au to m atically broken.
T he idea b ehind th is s tra te g y is twofold. Firstly, efficiency is im p o rta n t in proofs
too, therefore sharing is preserved w ithin reduction. Secondly, after full reduction
sharing is often not m eaningful anym ore and only hinders reduction, therefore
it is a u to m atically broken.
A s s ig n m e n t 22: (the effect of sharing during reduction in proofs)
(a ) C onsider in S p a r k l e th e triv ial theorem ( l e t n = 1+2+3 i n n+ n) = 12.
Prove it using -^Reduce NF A l l . ^ , followed by - ^ R e fle x iv e . ►.
(b ) U ndo th e proof w ith C tr l- Z and prove th e theorem again, th is tim e using
red u ctio n w ith a fixed num ber of steps (^R ed u ce 4 . ►).
(c ) U ndo th e proof w ith C tr l- Z and prove th e theorem again, th is tim e using
rep e a te d single-step reduction (^R ed u ce !..►•).
(d ) E xplain w hy m ore red uction steps are needed in (c) th a n in (b).
U nfortunately, S p a r k l e ’s cu rren t stra te g y for handling sharing is n o t optim al.
T he m ain problem is th a t all m eaningful sharing, such as for instance recursion
22
th a t has been expressed by m eans of cyclic lets, can n o t be d ealt w ith a t all.
Moreover, th e cu rren t behavior is n o t very intuitive, as was already dem o n strated
in th e assignm ent above.
T he way sharing is han dled in S p a r k l e is curren tly being fixed according
to th e red u ctio n m echanism described in [11]. In th e nex t release, S p a r k l e will
always preserve all sharing, and m anual reasoning steps will be added th a t allow
users to m an ip u late, an d possibly break, shared expressions a t will.
5 .2
D e f in e d n e s s c o n d itio n s in p r o p e r t i e s
S p a r k l e m akes use of a total sem antics in which undefinedness is taken into
consideration explicitly. T his has two consequences for th e p ro p erty language.
Firstly, expressions are only equal if th e y either produce th e sam e defined value,
or b o th produce undefinedness. Secondly, th e undefined value L is a m em ber of
any type, an d therefore a valid in sta n tia tio n of any quantor.
In order to specify p ro p erties of CLEAN-programs correctly, one therefore has
to know precisely how th e y behave in case some of th e ir in p u t becom es undefined.
T his behavior is determ in ed by th e lazy rew riting sem antics of C l e a n , of which
a th o ro u g h u n d erstan d in g is required for form al reasoning. Below we present a
sm all exam ple to illu stra te th e pro p ag atio n of L-values th ro u g h expressions. For
a full ex p lan atio n of co m p u tatio n in C l ea n we refer to [28] and [32].
E x a m p le . C onsider th e following definition of th e well-known function ta k e :
| t a k e n []
= []
| t a k e n [ x :x s ] = i f (n>0) [x: ta k e (n -1 ) x s] []
In C l e a n , p a tte rn s are evaluated from to p to bo tto m , and right-hand-sides
are only ev aluated w hen th e ir p a tte rn m atches. Consequently:
• t a k e n L = L for all n, because th e first p a tte rn always causes L to be
m atch ed against [] , which fails;
• t a k e L [] = [], because th e successful m atch of th e first p a tte rn does
not require L to be evaluated;
• t a k e L [ x : xs] = L for all x and xs, because th e second p a tte rn m atches,
and its right-hand-side requires th e co m p u tatio n of L > 0 , which fails.
It is very im p o rta n t th a t th e sta rtin g p o int of form al reasoning is a logically
correct property. Therefore, th e specification of properties m ust always involve
an analysis of behavior in th e undefined case. In some cases, th e p ro p erty tu rn s
out to hold au to m atically for th e undefined value, and n o thing has to be changed.
In o th e r cases, however, th e p ro p erty actually tu rn s o u t to be false:
E x a m p le . C onsider th e following intuitively tru e p ro p erty of d ro p and ta k e :
I VnVxs.ta k e n xs ++ d ro p n xs = xs.
T his p ro p e rty is falsified by th e case n = L , because th e n th e left-hand-side
m ay becom e undefined, while th e right-hand-side rem ains xs:
• Assum e xs = [1 ]. T hen th e left-hand-side reduces to L , as follows:
ta k e L [1] ++ d ro p L [1] = L ++ d ro p L [1] = L .
B u t th e right-hand-side is [1] , which is defined.
23
A s s ig n m e n t 23: (more definedness analysis)
(a ) T he exam ple p ro p e rty VnVxs.t a k e n xs ++ d ro p
th e case th a t xs = L A n = L . Argue w hy th is is
(Hint: distinguish betw een n = 0 and n = 0.)
(b ) Is th e p ro p e rty V f VxsVys.map f (xs ++ ys) = (map
in th e undefined case? If so, give exam ple values
th e property. If not, argue why.
(Hint: see also Section 4.6.)
n xs = xs is not falsified in
th e case.
f xs) ++ (map f ys) falsified
for f , xs and ys th a t break
If definedness analysis shows th a t a p ro p erty is falsified by a set of variable values
V , th e n it can be rectified sim ply by adding conditions th a t exclude V . These
definedness conditions are often sim ple and of th e form ‘n = L ’, b u t th e y can
also be m ore in tric a te (see Section 5.7).
R e c tif ie d e x a m p le : T he ta k e -d ro p p ro p erty can be corrected by m eans of:
I VnVxs.n = L — ta k e n xs ++ d ro p n xs = xs.
A s s ig n m e n t 24: (proving the rectified ta k e - d r o p example)
(a ) In S p a r k l e , prove VnVxs.n = L — ta k e n xs ++ d ro p n xs = xs.
Finally, note th a t C l e a n su p p o rts strictness annotations, w ith which th e strict
evaluation of certain expressions can be enforced explicitly. These an n o tatio n s
are often placed w ith o u t m uch th o u g h t w ith th e purpose of im proving efficiency.
However, strictn ess a n n o tatio n s change th e definedness behavior of th e program ,
and have an effect on p ro p erties and reasoning as well. In th e context of formal
reasoning, th e y should therefore only be used w ith care.
T he precise effect of strictness a n n o tatio n s on p ro p erties is difficult to predict.
A dding a strictn ess a n n o ta tio n can either: (1 ) n o t change a p ro p erty at all; or (2 )
falsify a property, requiring additional definedness conditions to be form ulated;
or (3 ) allow existing definedness conditions to be rem oved. T he th ird effect in
p a rtic u la r is ra th e r surprising.
E x a m p le o f (1 ). C onsider th e following property:
I VxsVySVzs.(xs ++ ys) ++ zs = xs ++ (ys ++ zs)
T his p ro p e rty holds for th e sta n d a rd definition of ++, which is stric t in its
first argum ent only. A dding strictness to th e second argum ent does n o t effect
th e property, however; it rem ains valid in th e stric t case as well.
E x a m p le o f (2 ). C onsider th e following property:
I Vf,gVxs .map ( f o g) xs = map f (map g x s )
T his p ro p e rty is valid for lazy lists, b u t invalid for elem ent-strict lists.
Suppose xs = [12], g 12 = L and f (g 12) = 7.
T h en map ( f o g) xs = [7 ], b o th in th e lazy and in th e stric t case.
However, map f (map g x s ) = [7] in th e lazy case, b u t L in th e stric t case.
T he p ro p e rty can be a d ap ted to elem ent-strict lists by explicitly enforcing
th a t g produces a defined result for all elem ents x of xs:
I Vf,g,xs .(Vx£xs .g x = L ) — map ( f o g) xs = map f (map g x s ).
24
E x a m p le o f (3 ). C onsider th e following property:
I Vxs .finite xs — r e v e r s e ( r e v e r s e x s ) = xs
T his p ro p e rty is valid b o th for lazy lists and for spine-strict lists.
T he condition finite x s , however, is satisfied au to m atically for spine-strict
lists, because spine-strict lists can never be infinite. In th e spine-strict case,
th e p ro p e rty can therefore safely be reform ulated (or, rath er, optim ized) by
rem oving th e finite xs condition:
I Vxs .r e v e r s e ( r e v e r s e x s ) = xs
N ote th a t w ith o u t th e condition, th e p ro p e rty is invalid in th e lazy case: ju st
choose any infinite list for xs.
5 .3
S p e c ia liz e d b e h a v io r o f e x te n s io n a lity
T he p ro p e rty of extensionality, which sta te s th a t two functions are equal iff th e y
produce th e sam e resu lt for all possible argum ents, is often considered to be
universal. U nfortunately, th ere is a (ra th e r obscure) exam ple of two functions
for which th e p ro p e rty of extensionality does not hold unconditionally in the
context of lazy evaluation:
H :: a -> b
H x = H x
F :: (a -> b)
F = F
In th e definitions above, H is a function of a rity 1 th a t only reduces (to itself)
w hen it is given an argum ent. F on th e o th er h an d is a function of a rity 0 th a t
always reduces to itself, regardless of w hether it is applied or not. Obviously,
F x = H x now holds for all x , because th e y b o th reduce to them selves and are
therefore b o th undefined.
Surprisingly, th e p ro p e rty F = H does n o t hold, because H is defined (it is a
p a rtia l function application, and is th u s in head norm al form), while th e m eaning
of F is undefined. It is therefore n o t safe to replace H by F (nor F by H); such a
replacem ent could nam ely change th e term in atio n behavior of th e program .
F ortunately, th e problem can be corrected by w eakening th e p ro p e rty of
ex tensionality as follows:
D e f in itio n 5 .3 .1 : (revised version of extensionality)
V fV g . ( f = L ^ g = L ) — (V x .f x = g x) — f = g
T his revised version of ex tensionality is correct in th e context of C l e a n . It can
not be applied to prove F = H , because th e condition F = L ^ H = L does
not hold. S p a r k l e defines a reasoning step for extensionality th a t m akes use of
th e correct behavior.
A s s ig n m e n t 25: (extensionality)
(a ) Prove using ex tensionality th a t sum o (map (c o n s t 1)) = l e n g t h holds.
25
5.4
S p e c ia liz e d b e h a v io r o f in d u c tio n
An im p o rta n t reasoning step for dealing w ith recursive functions over algebraic
d a ta ty p e s is structural induction. A lthough induction is n o t always applicable, it
is extrem ely useful in th e context of functional program m ing, because it can be
used successfully on m any com m on d a ta stru ctu re s (such as for instance lists)
and on m an y com m on kinds of recursive functions (such as for instance those
defined by recursion on th e results of p a tte rn m atching).
In order to deal w ith lazy evaluation, induction has to be custom ized in two
different ways. Firstly, an e x tra base step is required for th e undefined value L .
Because L is a m em ber of each type, it m ust nam ely be tre a te d as a co n structor
w ith no argum ents. T his behavior of induction is actu ally quite intuitive; for
instance, if we w ant to prove V x E[a ] .P (x) w ith induction on th e list stru ctu re,
we would get th e following proof obligations:
- P (L );
- p ([]);
- VxeAVxsE [A] P ( x s ) ——P ( [x : xs] )
N ote th a t w ith o u t th e case for undefinedness it is possible to prove properties
th a t are not tru e. For instance, we could easily prove th a t every lazy list is finite:
th e em p ty list is finite, an d th e extension of a finite list w ith a single elem ent is
always finite as well. T he undefined list, on th e o th er hand, is n o t finite!
T he second custom ization of induction extends it to infinite stru c tu re s as
well. B ecause an infinite stru c tu re does n o t end w ith a base case, th e induction
principle is in general n o t applicable to it. In [24], however, Paulson has shown
th a t th e resu lts of induction m ay be applied to infinite stru ctu re s as long as
th e induction p red icate satisfies th e criterion of admissibility. We claim th a t
P au lso n ’s results m ay be applied to th e context of C l e a n as well.
T he adm issibility criterion can be lifted to lazy functional languages easily.
T he basic idea is th a t equalities on negative positions (behind a negation) w ithin
a p roposition m ust be decidable. An equality on ty p e a is decidable if all possible
expressions of ty p e a are finite. T his can be approxim ated statically: if a does
not contain any recursion, th e n all its m em bers are certainly finite. An equality
on B ool is for instan ce decidable, b u t an equality on lists is not.
D e f in itio n 5 .4 .1 : (finite types)
A ty p e a is finite if th e set E of all possible expressions of ty p e a is finite.
D e f in itio n 5 .4 .2 : (decidable equalities)
A n equality betw een values of ty p e a is decidable if a is finite.
We will denote th is (inform ally) w ith Decidable(= ).
26
D e f in itio n 5 .4 .3 : (admissibility)
A p roposition P is adm issible if A d m ( + 1 , P ) holds, by m eans of:
A d m (sign, True )
= True
A d m (sign, False)
= True
A d m (sign, —P )
= Adm (-s ig n , P )
A d m (sign, P A Q)
= A d m (sign, P ) A A d m (sign, Q)
A d m (sign, P V Q)
= A d m (sign, P ) A A d m (sign, Q)
A d m (sign, P ^ Q) = A d m ( - s i g n , P ) A A d m (sign, Q)
A d m (sign, P ^ Q) = A d m (sign, P ^ Q) A A d m (sign, Q ^ P )
A d m ( sign, V . P )
= A dm (s ig n ,P )
A d m (sign, 3 .P )
= A d m (sign , P )
A d m (sign, E i = E 2 ) = Decidable (= ) V sign = + 1
A s s ig n m e n t 26: (induction on lazy lists)
For each of th e theorem s below: prove it or show th a t it is not adm issible.
(a ) y xs.f i n i t e xs ^ t a k e ( le n g th xs) xs = xs
(b ) y xs.xs = o n es ^ f i n i t e xs
(c ) Vxs^fVp.a l l p (map f xs) = a l l (p o f ) xs
(d ) Vxs e [a]Vyse[0].xs = ys ^ xs == ys
In order to reason a b o u t non-adm issible predicates a n d /o r non-inductive types
several techniques have been developed. T he m ost renow ned of th e m are th e take
lem m a an d its im proved version th e approxim ation lem m a [4] on one hand, and
th e class of techniques concerning co-induction based on bisimilarity[15] on the
o th er hand. To tre a t th e m in fu rther detail is outside th e scope of th is paper.
5 .5
D e f in e d n e s s a n a ly s is a n d t h e s p e c ia l ‘d e f in e d n e s s ’ t a c t i c
A consequence of th e specialized behavior described in Sections 5.2-5.4 is th a t
reasoning in S p a r k l e often involves properties of th e form E = ± or E = ± .
D ealing w ith definedness is cum bersom e, and should therefore be su p p o rted as
m uch as possible. For th is purpose, S p a r k l e derives definedness inform ation
autom atically, an d offers specialized tactics th a t m ake use of this inform ation.
Definedness analysis is th e process of deriving definedness inform ation. It is
carried o u t au to m atically by S p a r k l e each tim e a new goal is constructed. T he
results of definedness analysis are sets D and U , which contain expressions th a t
have been determ in ed to be defined and undefined respectively. T he sets D and
U are sto red w ith each goal and can be used by various tactics.
T he process of definedness analysis s ta rts by assigning all occurring basic
values to D an d ± to U . It th e n rep eated ly extends D and U by exam ining
th e hypotheses th a t have been introduced, and by m aking use of strictness and
totality properties. T he following derivation rules are used for th is purpose:
— Definedness by
If a hypothesis
If a hypothesis
If a hypothesis
hypothesis equality.
E 0 = E i is available, and E ¿ G D , th e n add E i - i to D .
E 0 = E i is available, and E i G U , th e n add E i - i to U .
E 0 = E 1 is available, and E i G U , th e n add E l - i to D .
27
— Constructor definedness.
A ssum e th a t C is a co n stru cto r of a rity n w ith stric t argum ents S C { 1 .. .n } .
If th e application A = (C E j . . . E n ) occurs as a subexpression in th e goal,
an d {E i | i G S} C D , th e n add A to D .
If th e application A = (C E j . . . E n ) occurs as a subexpression in th e goal,
an d { E i | i G S} n U = 0 , th e n add A to U .
— Total fu n c tio n definedness.
A ssum e th a t F is a function of a rity n which is known to be to tal.
If th e application A = (C E j . . . E n ) occurs as a subexpression in th e goal,
an d { E i | 1 < i < n } C D , th e n add A to D.
If th e application A = (C E j . . . E n ) occurs as a subexpression in th e goal,
an d { E i | 1 < i < n } n U = 0 , th en add A to U .
— N o rm a l fu n c tio n definedness.
A ssum e th a t F is a function of arity n w ith stric t argum ents S C {1 . . . n }.
If th e application A = ( F E i . . . E n ) occurs as a subexpression in th e goal,
an d { E i | i G S} n U = 0 , th e n add A to U .
N ote th a t th e strictn ess inform ation for th e definedness analysis is available
explicitly in th e source program , w hereas th e to ta lity inform ation is assum ed to
be m ade available ex tern ally (in S p a r k l e , m any functions from StdEnv are h a rd ­
coded to be to ta l). F urtherm ore, to m axim ize th e effectiveness of th e definedness
analysis, th e negation of th e cu rren t goal is tre a te d as a hypothesis as well.
An im p o rta n t ta c tic th a t m akes use of definedness analysis is ‘D efinedness’.
It im m ediately proves any goal th a t contains co n tradictory definedness, which
is th e case if D an d U overlap. N ote th a t because th e negation of th e current
goal is tre a te d as a hypothesis, it also proves any goal in which th e definedness
inform ation im plies th e validity of th e to prove. A lthough th e rules of definedness
analysis are relatively sim ple, it is surprisingly powerful. T he SPARKLE-tactic
‘D efinedness’ is therefore extrem ely useful, and can be applied often in proofs.
A s s ig n m e n t 27: (using the Definedness-tactic)
Prove each of th e following properties in S p a r k l e w ith th e D efinedness-tactic.
(a ) V f V ^ .—(map f xs = ± ) ^ —(xs = ± )
(b ) Vn .e v a l (n + 12) ^ - ( n = ± )
(c ) VnVm .(n / m = 42) ^ —(n + m = ± )
(d ) Vn .(7 + (12 * (13 - n )) = ± ) ^ n = ±
M ore exam ples of th e use of definedness can be found in [32].
5 .6
S p e c ia liz e d b e h a v io r o f r e d u c t i o n
Because of th e presence of logic variables th a t are in troduced by qu an to rs on
th e p ro p e rty level, red u ctio n in S p a r k l e is symbolic. A logic variable m ay be
in sta n tia te d w ith an a rb itra ry w ell-typed expression, and its evaluation does not
yield anything. A ssum ing term in atio n , it is therefore no longer possible to reduce
every expression to eith er a weak head norm al form or to ± .
28
It is im p o rta n t th a t red uction in S pa r k l e carries on as far as possible. For
th is purpose, S pa r k l e realizes two extensions in its reduction m echanism th a t
allow red u ctio n to continue, even w hen a logic variable is encountered on a strict
p osition.T he first extension involves ignoring unnecessary strictness annotations;
th e second extension involves using th e results of definedness analysis.
T he idea of th e first extension is th a t some strictness a n n o tatio n s can safely
be rem oved w ith o u t changing th e sem antics of th e program . To illu strate this,
take a look a t th e following th ree CLEAN-functions:
i d :: !a -> a
i d x = x
K :: !a !b -> a
K x y = x
le n g t h :: ![a ] -> I n t
le n g t h [ x :x s ] = 1 + le n g th xs
le n g t h []
=0
An exclam ation m ark before th e ty p e of an argum ent indicates strictness. D uring
evaluation, th e stric t argum ents of a function will always be reduced to weak head
norm al form before th e function is expanded, w hereas th e non-strict argum ents
will not. A strictn ess a n n o tatio n always changes th e reduction behavior of the
program ; however, it does n o t always change th e sem antics.
T he strictn ess a n n o ta tio n in th e function i d does n o t change th e sem antics,
because th e evaluation of its b o d y im m ediately requires th e evaluation of its
argum ent anyway. T he sam e goes for th e le n g t h function, because th e p a tte rn
m atch enforces evaluation. In th e function K, th e first strictness a n n o tatio n does
not change th e sem antics, b u t th e second one does. In fact, rem oving th e second
a n n o ta tio n would cause K x L = x , where in th e cu rren t situ a tio n K x L = L .
T he reduction system of S p a r k l e is able to recognize th e different kinds
of strictn ess an n o tatio n s. In case a stric t function argum ent is encountered like
in i d or in K (first a n n o tatio n ), it will be reduced first, b u t th e function will
always be expanded afterw ards. T his is different from reduction in C l e a n , b u t
sem antically sound, an d m uch m ore user friendly for reasoning (not expanding
‘i d x ’ would be really inconvenient). T he behavior of S p a r k l e on an n o tatio n s
as in K (second an n o tatio n ) is of course n o t changed, because th a t would be
sem antically unsound. T he behavior on an n o tatio n s as in l e n g t h is n o t changed
either, because th e pending p a tte rn m atch requires its argum ent to be reduced.
E xpan d in g th e function therefore does n o t m ake m uch sense, because reduction
would be sto p p ed by th e p a tte rn m atch anyway.
A s s ig n m e n t 28: (reduction in S p a r k l e (1))
(a ) B uild a CLEAN-module w ith th e functions above and load it into S p a r k l e .
(b ) Prove Vx . i d x = x
(c ) Prove Vx .K x 12 = x
(d ) A tte m p t to prove Vx .K 12 x = 12. W hy does th is p ro p erty n o t hold?
T he second extension of reduction is very straightforw ard: sim ply m ake use of
th e results of th e definedness analysis. In case S p a r k l e encounters a function
argum ent whose strictn ess cannot be rem oved safely, and on which no p a tte rn
m atch is perform ed, th e n th e function is allowed to be expanded anyway, as
long as th e argum ent expression is an elem ent of D . Again, th e argum ent will be
29
reduced as m uch as possible first. T he second extension allows users to influence
th e red u ctio n m echanism by m eans of specifying (and later proving) additional
definedness properties.
A s s ig n m e n t 29: (reduction in S p a r k l e (2))
(a ) Prove VxVy .—(y = L ) — K x y = x
5 .7
P r o p e r t y s p e c if ic a tio n in C l ea n
T he p ro p e rty language of S p a r k l e is a sim ple first-order proposition logic only,
in which pred icates an d relations cannot be expressed. However, th e possibility
to define higher-order functions in th e program m ing language and use th em as
boolean p redicates gives unexpected expressive power. T he higher-order of the
program m ing language can be com bined w ith S p a r k l e ’s first order logic.
A good exam ple of a boolean predicate in C l e a n is th e function e v a l. T he
purpose of e v a l is to fully reduce its argum ent and re tu rn T rue afterw ards. Such
an ‘eval’ function is usually used to express evaluation strategies in th e context
of parallelism [6, 31]. We use e v a l for expressing definedness conditions.
In th e m odule S td S p a r k le of S p a r k l e ’s sta n d a rd environm ent, th e function
e v a l is defined by m eans of overloading. T he instance on C har is defined by:
c l a s s e v a l a ::
!a -> Bool
i n s t a n c e e v a l Char
w here
e v a l :: !C har -> Bool
e v a l x = T rue
In a logical property, ( e v a l x = T rue) can now be used as a m anual definedness
condition. T he m eaning of th is condition is identical to —(x = L ) , because:
- If x = L , th e n ( e v a l x) = ( e v a l L ) = L on th e sem antic level, because e v a l
is stric t in its argum ent. Therefore, e v a l x = T rue is n o t satisfied.
- If x = L , th e n x m ust be equal to some defined basic ch aracter b. Therefore,
( e v a l x) = ( e v a l b) = T rue on th e sem antic level.
- N ote th a t e v a l is defined in such a way th a t it is never equal to F a ls e .
O n ch aracters, e v a l is n o t so interesting. However, by m eans of overloading, it
can easily be defined for lists, and all o ther kinds of d a ta stru ctu re s as well. T he
overloading is used to assum e th e presence of an e v a l on th e elem ent type:
in s ta n c e e v a l
w here
eval
eval
eval
[a] I e v a l a
:: ![ a ] -> B ool I e v a l a
[ x :x s ] = e v a l x && e v a l xs
[]
= T rue
T his instance of e v a l fully evaluates b o th th e spine of th e list and all its elem ents,
and only re tu rn s T rue if th is succeeds. It can therefore be used to express the
30
in tricate definedness condition th a t a list is finite and contains defined elem ents
only. T his condition can n o t be expressed on th e p ro p erty level a t all.
A s s ig n m e n t 30: (proofs of properties that use e v a l)
Using th e function e v a l from S td S p a r k le , prove th e following properties:
(a ) VxVxs.e v a l xs — isM ember x xs — e v a l x
(b ) Vxs.e v a l xs — sum (map (K 1) xs) = le n g t h xs
(using th e stric t version of function K, see assignm ent 28)
(c ) VxVpVxs.e v a l x — e v a l xs — e v a l (map p xs) —
isM ember x ( f i l t e r p xs) = isM ember x xs && p x
All instances of e v a l have to share certain properties. To prove properties of
all m em bers of a certain ty p e class, th e recently added tool su p p o rt for general
ty p e classes can be used [19]. W ith th is tool, th e properties Vx .e v a l x — x = L
and Vx .e v a l x = F a ls e can be sta te d and proven in S p a r k l e .
A useful variation of e v a l on lists is th e function th a t evaluates th e spine of
th e list only, b u t leaves th e elem ents alone. T his function expresses th e condition
th a t a list is finite. It is defined in S td S p a rk le as follows:
fin ite
fin ite
fin ite
:: ![ a ] -> Bool
[ x :x s ]
= f i n i t e xs
[]
= T rue
T he boolean p red icate f i n i t e allows several useful properties to be sta te d and
proven in S p a r k l e :
A s s ig n m e n t 31: (proofs of properties that use f i n i t e )
Using th e function f i n i t e from S td S p a rk le , prove th e following properties:
(a ) Vxs.f i n i t e xs — l e n g t h xs > 0
(b ) Vxs.f i n i t e xs — f i n i t e ( r e v e r s e xs)
(c ) Vxs.f i n i t e xs — r e v e r s e ( r e v e r s e xs) = xs
6
R e la te d W o rk
C urrently, well-known an d w idely used proof assistants are P v s [23], C oq [30]
and I sa b e l l e [25]. T h ey are all generic provers th a t are n o t tailored tow ards
a specific program m ing language. It is very h a rd for program m ers to reason in
them , because th e y require using a different sy n tax and a different sem antics. For
instance, strictn ess a n n o tatio n s as in C lea n are n o t su p p o rted by any existing
proof assistan t. O n th e o th er hand, these well established proof assistan ts offer
features th a t are n o t available in S p a r k l e . M ost notably, th e tac tic language
and th e logic are m uch richer th a n in S p a r k l e .
A t C halm ers U niversity of Technology, th e proof assistan t A gda [1] has been
developed in th e context of th e C o v e r [9] project. A g d a is dedicated to th e lazy
functional language H a sk e l l [18]. As in S p a r k l e , th e program is tra n sla te d to a
core-version on which th e proofs are perform ed. Being geared tow ards facilitating
31
th e ‘average’ functional program m er, S pa r k l e offers dedicated ta ctics and a
d edicated sem antics based on graph rew riting. A g d a uses sta n d a rd constructive
ty p e th e o ry on A-terms, enabling independent proof checking.
Also as p a rt of th e C o v e r project, it is argued in [10] th a t “loose reasoning”
is “m orally co rrect” , i.e. th a t th e correctness of a theorem u n der th e assum ption
th a t every subexpression is stric t and term in atin g im plies th e correctness of the
theo rem in th e lazy case u n d er certain additional conditions. T he conditions th a t
are found in th is way, however, m ay be to o restrictive for th e lazy case. S p a r k l e
offers good su p p o rt for reasoning w ith definedness conditions directly.
A nother pro o f assistan t dedicated to H a sk e l l is E ra [33], which stan d s
for E q u atio n al R easoning A ssistant. T his proof assistant builds on earlier work
in itia te d by A ndy Gill[13]. It is intended to be used for equational reasoning,
and n o t for theo rem proving in general. A dditional proving m ethods, such as
induction or logical steps, are not supported. E r a is a stand-alone application.
U nfortunately, it seem s th a t work on this pro ject has been discontinued for
a while. Recently, A ndy Gill took up th e project again, producing a version
w ith an A jax based interface, un d er th e nam e of H e r a [14], short for H a sk e l l
E q u atio n al R easoning A ssistant.
In [20], a description is given of an au to m ate d proof tool which is dedicated to
H a s k e l l . It su p p o rts a subset of H a s k e l l , and needs no guidance of users in the
proving process. In d u ctio n is only applied w hen th e corresponding q u an to r has
been m arked explicitly in advance. T he user, however, cannot fu rth er influence
th e proving process a t all, and cannot suggest tactics to help th e prover in
co n stru ctin g th e proof.
A nother pro o f assistan t th a t is dedicated to a functional language is E v t [22],
th e E rlan g V erification Tool. However, E r l a n g differs from C l e a n , because it
is a stric t, u n ty p ed language which is m ainly used for developing d istrib u te d
applications. E v t has been applied in practice to larger exam ples.
T he P r o g r a m a t ic a p ro ject of th e Pacific Software R esearch C enter in
O regon (w w w .cse.ogi.edu/PacSoft/projects/program atica) is an o th er p ro ject th a t
aim s to in teg rate program m ing and reasoning. T h ey in ten d to su p p o rt a wide
range of validation techniques for program s w ritte n in different languages. For
functional languages th e y use P-logic, which is based on a m odal ^-calculus
in w hich undefinedness can also be expressed. In th e P r o g r a m a t ic a project,
p ro p erties are m ixed w ith th e H a s k e l l source.
P ro p erties a b o u t functional program s are proved by h an d in m any textbooks,
for instance in [4]. Also, several articles (for instance [8]) m ake use of reasoning
ab o u t functional program s. It seems w orthw hile to a tte m p t to formalize these
proofs in S p a r k l e . In program m ing practice, however, reasoning a b o u t func­
tio n al program s is scarcely used.
7
C o n c lu s io n s
In th is pap er, we have p resented a th o rough description of th e dedicated proof
assistan t S p a r k l e , w hich is in teg rate d in th e d istrib u tio n of th e lazy functional
32
program m ing language C l e a n . We have in troduced S p a r k l e in detail, b o th
on th e th eo retical an d on th e p ractical level. O n th e theoretical level, we have
explained th e process of form al reasoning in general, and S p a r k l e ’s dedicated
su p p o rt for it in specific. O n th e practical level, we have provided an extensive
tu to ria l of th e actu al use of S p a r k l e .
T he tu to ria l n o t only covers th e fundam ental functionality of S p a r k l e , b u t
also explains several of its advanced features th a t are specific for reasoning about
lazy functional program s. A ssignm ents are included a t various points in the
tu to rial; th e y allow useful hands-on experience w ith S p a r k l e to be ob tain ed in a
guided way. A fter com pletion of th e tu to ria l, anyone w ith a basic un d erstan d in g
of functional program m ing will be able to m ake effective use of S p a r k l e in
practice, an d will be able to prove sm all to m edium properties w ith little effort.
F urtherm ore, we also hope to have sparked an in terest in m aking use of formal
reasoning to show im p o rta n t properties of functional program s. W ith th e right
tool su p p o rt, th is is alread y feasible for m any sm aller exam ples, and provides an
enjoyable challenge for bigger program s too!
R e fe re n c e s
1. A. Abel, M. Benke, A. Bove, J. Hughes, and U. Norell. Verifying Haskell programs
using constructive type theory. In D. Leijen, editor, Proceedings of the A C M SIGP L A N 2005 Haskell Workshop, pages 62 - 74. Tallinn, Estonia, ACM Press, 2005.
2. H. P. Barendregt, M. C. J. D. van Eekelen, J. R. W. Glauert, R. Kennaway, M. J.
Plasmeijer, and M. R. Sleep. Term graph rewriting. In J. W. de Bakker, A. J.
Nijman, and P. C. Treleaven, editors, PARLE (2), volume 259 of Lecture Notes in
Computer Science, pages 141-158. Springer, 1987.
3. E. Barendsen and S. Smetsers. Graph rewriting aspects of functional programming.
In Handbook of Graph Grammars and Computing by Graph Transformation, pages
63-102. World Scientific, 1999.
4. R. S. Bird. Introduction to Functional Programming using Haskell, second edition.
Prentice Hall, 1998. ISBN 0-13-484346-0.
5. T. H. Brus, M. C. J. D. van Eekelen, M. O. van Leer, and M. J. Plasmeijer.
Clean: A language for functional graph writing. In Proceedings of the Functional
Programming Languages and Computer Architecture, pages 364-384, London, UK,
1987. Springer-Verlag.
6. G. L. Burn. Evaluation transformers a model for the parallel evolution of functional
languages. In Proc. of a conference on Functional programming languages and
computer architecture, pages 446-470, London, UK, 1987. Springer-Verlag.
7. A. Butterfield and G. Strong. Proving Correctness of Programs with I/O - a
paradigm comparison. In T. Arts and M. Mohnen, editors, Selected Papers from
the 13th International Workshop on Implementation of Functional Languages, IFL
2001, volume 2312 of LNCS, pages 72-88, Stockholm, Sweden, 2001. Springer.
8. A. Butterfield and G. Strong. Proving correctness of programs with io - a paradigm
comparison. In T. Arts and M. Mohnen, editors, IFL, volume 2312 of Lecture Notes
in Computer Science, pages 72-87. Springer, 2001.
9. T. Coquand, P. Dybjer, J. Hughes, and M. Sheeran. Combining verification meth­
ods in software development. Project proposal, Chalmers Institute of Techology,
Sweden, December 2001.
33
10. N. A. Danielsson, J. Hughes, P. Jansson, and J. Gibbons. Fast and loose reasoning
is morally correct. SIG P LA N Not., 41(1):206-217, January 2006.
11. M. de Mol, M. van Eekelen, and R. Plasmeijer. A single-step term-graph reduction
system for proof assistants. In Andy Schurr and Manfred Nagl and Albert Zündorf,
editor, Proceedings of Selected and Invited Papers of Applications of Graph Trans­
formations with Industrial Relevance, Third International Symposium, A G T IV E
2007, pages 181-197, Kassel, Germany, 2007.
12. M. Dowse, A. Butterfield, and M. C. J. D. van Eekelen. Reasoning About Deter­
ministic Concurrent Functional I/O . In C. Grelck, F. Huch, G. Michaelson, and
P. W. Trinder, editors, IFL, volume 3474 of Lecture Notes in Computer Science,
pages 177-194. Springer, 2004.
13. A. Gill. The technology behind a graphical user interface for an equational rea­
soning assistant. In D. N. Turner, editor, Functional Programming, Workshops in
Computing, page 4. Springer, 1995.
14. A. Gill. Introducing the haskell equational reasoning assistant. In Haskell ’06:
Proceedings of the 2006 A C M SIG PLA N workshop on Haskell, pages 108-109, New
York, NY, USA, 2006. ACM Press.
15. A. Gordon. Bisimilarity as a theory of functional programming. In Proceedings
of the Eleventh Conference on the Mathematical Foundations of Programming Se­
mantics, volume 1 of Electronic Notes in Theoretical Computer Science. Elsevier
Science B.V., 1995.
16. M. Gordon, R. Milner, and C. Wadsworth. Edinburgh LCF: a mechanised logic
of computation. volume 78 of Lecture Notes in Computer Science. Springer-Verlag
Berlin, 1979.
17. Z. Horvath, T. Kozsik, and M. Tejfel. Proving invariants of functional programs.
In P. Kilpelüinen and N. Paivinen, editors, SPLST, pages 115-126. University of
Kuopio, D epartm ent of Computer Science, 2003.
18. P. Hudak, S. L. P. Jones, P. Wadler, B. Boutel, J. Fairbairn, J. H. Fasel, M. M.
Guzman, K. Hammond, J. Hughes, T. Johnsson, R. B. Kieburtz, R. S. Nikhil,
W. Partain, and J. Peterson. Report on the Programming Language Haskell, A
Non-strict, Purely Functional Language. SIG P LAN Notices, 27(5):R1-R164, 1992.
19. Kesteren, R. van and Eekelen, M. van and Mol, M. de. Proof support for gen­
eral type classes. In H.-W. Loidl, editor, Trends in Functional Programming 5:
Selected papers from the Fifth International Symposium on Trends in Functional
Programming, TFP04, pages 1-16. Munchen, Germany, Intellect, 2004.
20. S. Mintchev. Mechanized reasoning about functional programs. In K. Hammond,
D. Turner, and P. Sansom, editors, Proceedings of the Glasgow Functional Progamming Workshop, pages 151-167, Glasgow, United Kingdom, 1994. Springer.
21. M. d. Mol, M. v. Eekelen, and R. Plasmeijer. The Mathematical Foundation of
the Proof Assistant Sparkle. Technical Report ICIS-R07025, Radboud University
Nijmegen, November 2007.
22. T. Noll, L. Fredlund, and D. Gurov. The evt erlang verification tool. In Proceed­
ings of the 7th International Conference on Tools and Algorithms for the Construc­
tion and Analysis of Systems (T A C A S ’01), volume 2031 of LNCS, pages 582-585,
Stockholm, Sweden, 2001. Springer Verlag. ISBN 3-540-41865-2.
23. S. Owre, N. Shankar, J. Rushby, and D. Stringer-Calvert. P V S Language Reference
(version 2.3), 1999. http://pvs.csl.sri.com /m anuals.htm l.
24. L. C. Paulson. Logic and Computation. Cambridge University Press, 1987. ISBN
0-52-134632-0.
25. L. C. Paulson. The Isabelle Reference Manual. University of Cambridge, 2001.
http://w w w .cl.cam .ac.uk/Research/H V G /Isabelle/docs.htm l.
34
26. R. Plasmeijer and M. van Eekelen. Functional Programming and Parallel Graph
Rewriting. Addison-Wesley Publishing Company, 1993. ISBN 0-201-41663-8.
27. R. Plasmeijer and M. van Eekelen. Keep it clean: a unique approach to functional
programming. SIG PLA N Not., 34(6):23-31, 1999.
28. R. Plasmeijer and M. van Eekelen. Concurrent CLEAN Language Report (version
2.0), December 2001. http://w w w .cs.ru.nl/~ clean/.
29. M. Tejfel, Z. Horvath, and T. Kozsik. Extending the sparkle core language with
object abstraction. Acta Cybern., 17(2), 2006.
30. The Coq Development Team. The Coq Proof Assistant Reference Manual (version
7.0). Inria, 1998. http://pauillac.inria.fr/coq/doc/m ain.htm l.
31. P. W. Trinder, K. Hammond, H.-W. Loidl, and S. L. P. Jones. Algorithm + strategy
= parallelism. J. Funct. Program., 8(1):23-60, 1998.
32. M. van Eekelen and M. de Mol. Proof tool support for explicit strictness. In
A. Butterfield, C. Grelck, and F. Huch, editors, Selected Papers of the 17th Inter­
national Workshop on Implementation of Functional Languages, IFL 2005, volume
4015 of Lecture Notes in Computer Science, pages 37-54, Dublin, Ireland, 2006.
Springer Verlag.
33. N. Winstanley. Era User Manual, version 2.0. University of Glasgow, March, 1998.
http://w w w .dcs.gla.ac.uk/~nw w /Era/Era.htm l.
35
A
A p p e n d ix : s h o r t d e s c r ip tio n o f a ll S p a r k l e t a c tic s
T his ap pendix provides a sh o rt description of th e ta ctic s th a t can be used in
S pa r k l e proofs. In to ta l, S pa r k l e m akes a lib rary of 39 tac tic s available. In
th e d escription below, each tac tic is briefly categorized as follows:
Equivalence/Strengthening - an equivalence tac tic creates new goals th a t are
logically equivalent to th e original goal; a stren gthening tactic creates goals
th a t are logically stronger.
Forwards/Backwards - a forw ards ta ctic brings hypotheses closer to th e current
goal; a backw ards ta c tic brings th e cu rrent goal closer to th e hypotheses.
Instantaneous - an in stan tan eo u s ta ctic proves a goal in one single step (and will
n o t be categorized as eq u ivalence/strengthening or forw ards/backw ards).
Programming/Logic - a program m ing tac tic is based on th e sem antics of C le a n ;
a logic ta c tic is based on th e sem antics of th e logical connectives.
Besides th e type, for each tac tic some inform ation ab o u t its inner w orking is
sta te d , an d a sm all example is given of its use.
A bsurd <Hyp1> <Hyp2>.___________________________________________________
T y p e : In stan tan eo u s; logic.
In fo : Proves a goal th a t contains co n trad icto ry (absurd) hypotheses.
D e ta ils : H ypotheses are c o n trad icto ry if th ey are each o th e r’s exact negation.
E x a m p le : p, (H1:-i(p = 12)}, (H2:p = 12} h FALSE
A bsurd H1 H 2 .^
Q .E.D .
A b s u rd E q u a lity <Hyp>.
T y p e : In stan tan eo u s; program m ing.
In fo : Proves a goal th a t contains a hypothesis sta tin g an absurd equality.
D e ta ils : A n equality betw een tw o different basic values is absurd, as well as an
equality betw een applications of different lazy constructors.
E x a m p le : (H1:True = F a lse } h FALSE
^ A b s u rd E q u a lity H 1 .►
Q .E.D .
N o te s : T ru e an d F a ls e are constructors; FALSE is a co n stan t proposition.
36
A pply < F a ct> .
T y p e : U sually strengthening, depends on fact; backw ards; logic.
In fo : Applies a fact to th e cu rren t goal.
D e ta ils : A fact is either an earlier proved theorem or an in troduced hypothesis,
and m ust be of th e form Vx i ...xn .P i— . .. P m — Q. It is only valid if r i .. . r n can
be found such th a t Q[_xi — T'i ] equals th e cu rrent goal. If th is is th e case, th en
th e cu rren t goal is replaced w ith th e conjunction P 1 [xi — ri ] A .. .A P m [xi — r i ].
E x a m p le : p, (H1:VxVyVz .x > 0 — y < z — x + y < x + z} h 7 + p < 7 + 1 2
^ A p p ly H 1 .►
p, (H1 :VxVyVz .x > 0 — y < z — x + y < x + z} h 7 > 0 A p < 12
N o te s : T his ta c tic can also be applied in a forw ards m anner. In th a t case, P 1
m ust m atch on a hypothesis R, which is th en replaced by P 2 — . . . Pn — Q.
Assume <Prop>.
T y p e : Equivalence; forwards; logic.
In fo : Assum es th e validity of a m anually sta te d proposition.
D e ta ils : Tw o goals are created: one w ith th e assum ption as new hypothesis,
and one w ith th e hypothesis as goal itself.
E x a m p le : P, Q, R, (H 1:P ^ R ), ( H 2 :-P ^ R) h R
^Assum e P V —P .►
(1) P , Q , R , (H 1:P ^ R ), (H2:—P ^ R), (H 3:P V —P ) h R
(2) P , Q , R , (H 1:P ^ R ), (H2:—P ^ R) h P V —P
N o te s : A nam e for th e new hypothesis is generated autom atically.
Case <Hyp>.
T y p e : Equivalence; backw ards; logic.
In fo : B reaks dow n an in tro duced disjunction.
D e ta ils : T he hypothesis m ust be of th e form P V Q. Tw o goals are created: one
in which th e hypothesis is replaced by P , and one in which it is replaced by Q .
E x a m p le : P, Q, (H 1:P V - P } , (H 2:P — Q}, (H 3 :-P — Q} h Q
^ C a s e H 1 .►
(1) P, Q, (H 1 :P }, (H 2:P — Q}, (H 3 :- P — Q} h Q
(2) P, Q, ( H 1 :- P }, (H 2:P — Q}, ( H 3 :-P — Q} h Q
37
C ases <Expr>.
T y p e : Equivalence; program m ing.
In fo : Perform s a case d istin ction on a given expression.
D e ta ils : T he expression m ust be of an algebraic type. New goals are created
for each of its constructors, and one for ± as well. Each new goal is obtained
by replacing all occurrences (also in th e hypotheses) of th e indicated expression
w ith a generic applicatio n of th e constructor.
E x a m p le : xs, ys, (H 1 :le n g th (xs ++ ys) > 0} I---- -(xs ++ ys = [])
-^C ases (x s ++ y s ) . ^
(1) (H 1 :le n g th ± > 0} I— —
( ^ = [])
(2) (H 1 :le n g th [] > 0} h - ( [ ] = [])
(3) x i , x 2 , (H 1 :le n g th [ x i :x 2 ] > 0} I— 1( [ x i :x 2 ] = [])
N o te s : N am es for th e new ly in troduced variables are generated autom atically.
C hooseC ase.
T y p e : Equivalence; program m ing.
In fo : Simplifies a case d istin ctio n in which only one p a tte rn is valid.
D e ta ils : T he goal m ust be of th e form E i = E 2, w here E i is a case distinction
and E 2 is a basic value. A p a tte rn is valid if its result is n o t statically unequal
to E 2 . T he ta c tic succeeds only if th ere is exactly one valid p a tte rn . T he case
is th e n simplified to th e result of th e single valid p a tte rn , and its condition is
intro d u ced as a conjunction in th e goal.
E x a m p le : n h c a s e n o f (7 — 13; 13 — 7; n — 11) = 13
^ C h o o seC ase . ►
n b n = ^ A 13 = 13
Compare <Expr1> w ith <Expr2>.
T y p e : Equivalence; backw ards; logic.
In fo : D istinguishes betw een th e possible com pare results of two expressions.
D e ta ils : T he expressions m ust b o th be of ty p e I n t . Five new goals are created;
one for E i = ± , one for E 2 = ± , one for E i < E 2, one for E i = E 2 (provided
th a t E i and E 2 are not ± ) , and one for E 2 < E i .
E x a m p le : m , n h m in m n < max m n
-^Compare m w ith n . ^
(1) m , n h m = ± — min m n < max m n
(2) m , n h n = ± — min m n < max m n
(3) m , n h m < n — min m n < max m n
(4) m , n \---- i(m = + ) — —(n = ± ) — m = n — min m n < max m n
(5) m , n h n < m — min m n < max m n
38
C o n tra d ic tio n .
T y p e : Equivalence; backw ards; logic.
In fo : B uilds a pro o f by contradiction.
D e ta ils : Replaces th e c u rren t goal by th e ab su rd proposition FALSE and adds
its negation as a hypothesis in th e context. If a double negation is produced, it
will be rem oved autom atically.
E x a m p le : P, (H 1:P ^ FALSE) h —P
- ^ C o n tr a d ic tio n . ►
P, (H 1:P ^ FALSE), (H 2:P) h FALSE
N o te s : A nam e for th e new hypothesis is generated autom atically. T his tactic
can also be applied in a forw ards m anner on a hypothesis. In th a t case, the
negation of th e hypothesis sim ply becom es th e new goal to prove.
Cut < F a ct> .
T y p e : Equivalence; backw ards; logic.
In fo : D uplicates a fact.
D e ta ils : A fact is either an earlier proved theorem or an in troduced hypothesis.
It is add ed to th e to prove by m eans of a new im plication.
E x a m p le : (H1:VP .P V —P ) h FALSE
^ C u t H1. ►
(H1:VP .P V —P ) h (VP .P V —P ) ^ FALSE
D e f in e d n e s s .
T y p e : In stan tan eo u s; logic.
In fo : Uses c o n trad icto ry definedness inform ation to prove a goal.
D e ta ils : Two sets of expressions are determ ined: (1) those th a t are statically
know n to be equal to ± ; (2) those th a t are statica lly known to be unequal to
± . T hese sets are determ in ed by exam ining equalities in hypotheses and using
strictn ess inform ation. In addition, th e to ta lity of certain predefined functions is
used. If an overlap betw een th e tw o sets is found, th e goal is proved im m ediately.
E x a m p le : xs, ys, zs, (H1 :xs = 1 ) , (H2:xs ++ ys = [1 : zs] ) h FALSE
-^ D e fin e d n e s s . ►
Q .E.D .
N o te s : In th e exam ple, xs = ± due to H1, and —(xs = ± ) due to th e strictness of
++ an d th e definedness of th e result of xs ++ ys by m eans of H2.
D is c a r d <Hyp>.
T y p e : Strengthening; logic.
In fo : D eletes an intro d u ced hypothesis.
E x a m p le : x, xs, (H 1 :re v e rs e [] = []} h r e v e r s e [ x : xs] = r e v e r s e xs + +[x]
-^ D isc a rd H1. ►
x, xs h r e v e r s e [ x : xs] = r e v e r s e xs + + [x]
39
E x a c t <Hyp>.
T y p e : In stan tan eo u s; logic.
In fo : Proves a goal th a t is identical to an in troduced hypothesis.
E x a m p le : (H1:VP VQ.(P A Q) — P} h V PVQ .(P A Q) — P
-^E xact H 1 .►
Q .E.D .
E x F also <Hyp>.
T y p e : In stan tan eo u s; logic.
In fo : Proves a goal th a t contains a hypothesis sta tin g FALSE.
E x a m p le : (H1:FALSE} h 5 = 6
^ E x F a ls o H1. ►
Q .E.D .
E x t e n s i o n a l i t y <Name>.
T y p e : Equivalence; backw ards; logic.
In fo : Proves eq u ality of functions by m eans of extensionality.
D e ta ils : T he cu rren t goal m ust of th e form E 1 = E 2, and b o th E 1 and E 2 m ust
be functions. T he goal is th e n replaced w ith VName-(E1 Name) = ( E 2 Name).
E x a m p le : h (++ [] ) = id
- ^ E x t e n s i o n a l i ty x s . ^
h Vxs. [] ++ xs = i d xs
N o te s : To prevent proving ± = X x .±, which is n o t valid, additional definedness
conditions are created u nder certain conditions.
G e n e r a liz e <Expr> t o <Name>.
T y p e : Strengthening; backw ards; logic.
In fo : G eneralizes an a rb itra ry subexpression.
D e ta ils : In th e to prove, replaces all occurrences of th e indicated expression
w ith th e variable Name. T hen, adds th e q u an to r VName in front of it.
E x a m p le : xs h ( r e v e r s e xs) ++ [] = r e v e r s e xs
^ G e n e r a li z e ( r e v e r s e x s ) t o y s . ^
h VyS.ys ++ [] = ys
40
I n d u c tio n <Var>.
T y p e : Strengthening; backw ards; program m ing.
In fo : Perform s s tru c tu ra l induction on a variable
D e ta ils : T he ty p e of th e indicated variable m ust be I n t , Bool or algebraic. A
goal is created for each ro o t norm al form (R N F) th e variable m ay have, which
includes + . T he R N F s of an algebraic ty p e are determ ined by its constructors. In
each created goal, th e variable is replaced by its corresponding R N F. U niversal
q u an to rs are created for new variables. A dditionally, induction hypotheses are
added (as im plications) for all recursive variables.
E x a m p le : h Vxs.xs ++ [] = xs
-^ In d u c tio n x s . ^
(1) h ± ++ [] = ±
(2) h []++ [] = []
(3) h VxVxs.(xs ++ [] = xs) — [ x : xs] ++ [] = [ x : xs]
I n je c tiv e .
T y p e : Strengthening; backw ards; logic.
In fo : Proves equality of applications by m aking use of injectivity.
D e ta ils : Replaces a goal of th e form ( S E i . . . E n ) = ( S E 'i . . . E 'n ), where S is
eith er a function or a co n structor, w ith th e conjunction E i = E [ A . . . A E n = E 'n .
E x a m p le : xs, ys h xs ++ [] = xs ++ ys
-^ In je c tiv e . ►
xs, ys h xs = xs A [] = ys
N o te s : T his ta c tic can also be applied in a forwards m anner on a hypothesis.
In tA rith .
T y p e : Equivalence; backw ards; logic.
In fo : B uilt-in sim plification of a rith m etic expressions.
D e ta ils : T his ta c tic o p erates on expressions containing applications of + , — and
* on integers. It perform s three sim plifications: (1) a * (b + c) is replaced w ith
a * b + a * c; (2) co n stan ts are m oved to th e right as m uch as possible; and (3)
co m p u tatio n s on co n stan ts are carried o u t statically.
E x a m p le : x , y h 3 + 7 * (12 + x) — 100 = y
^ In tA rith . ►
x, y h 7 * x — 13 = y
N o te s : T his ta c tic can also be applied in a forwards m anner on a hypothesis.
41
In tC o m p are.
T y p e : In stan tan eo u s; logic.
In fo : Proves goals w ith c o n trad icto ry integer com parisons.
D e ta ils : O nly hypotheses of th e exact form x < y are used as in p u t. If a chain
x < y < . . . < x can be found, th e n th e goal is proved im m ediately.
E x a m p le : x, y, z, (H1:y < x}, (H2:z < y}, (H3:x < z} h FALSE
^ In tC o m p a re . ►
Q .E.D .
I n tr o d u c e <Name1> <Name2> . . . <Namen>.
T y p e : Equivalence; backw ards; logic.
In fo : Introduces universally quantified variables and hypotheses in th e goal.
D e ta ils : T he cu rren t goal m ust be of th e form VXl...Xa .P i — .. . P b— Q, where
a + b = n. T he q u an to rs and im plications m ay be m ixed. T he variables x i .. . x a
and th e hypotheses P i .. . P b are deleted from th e cu rren t goal and are added to
th e goal context using th e nam es given.
E x a m p le : h V X.(x = 7 — Vy .(y = 7 — x = y))
- ^ In tro d u c e p H1 q H 2 .^
P, q, (H1:p = 7), (H2:q = 7) h p = q
M oveQ uantors < D ir> .
T y p e : Equivalence; backw ards; logic.
In fo : Swaps im plications and universal quantifications.
D e ta ils : T he direction argum ent is either ‘I n ’ or ‘O u t’. W hen m oving inwards,
goals of th e form VXl...Xn .P1 — . . . P m — Q are transform ed to P 1 — . . . P m —
VXl...Xn.Q, provided th a t none of th e x j occur in any of th e P j . T he outw ards
move is th e opposite of th e inw ards move.
E x a m p le : R h VPV q .R — —R — P A Q
^M oveQ uantors I n . ^
R h R ———R ——Vp V q .P A Q
N o te s : T his ta c tic can also be applied in a forwards m anner on a hypothesis.
Opaque <Fun>.
T y p e : Special.
In fo : M arks a function as non-expandable.
D e ta ils : W hen a function is m arked opaque, it will n o t be expanded by the
reduction m echanism . Instead, reduction will stop.
E x a m p le : h z i p ( [ ] , []) = []
-^Opaque z ip 2 ; Reduce NF A l l . ►
h z ip 2 [] [] = []
42
Reduce NF A ll.
T y p e : Equivalence; backw ards; program m ing.
In fo : R educes all expressions in th e cu rren t goal to norm al form.
D e ta ils : All redexes in th e cu rren t goal are replaced by th eir reducts. T his full
reduction is accom plished by first using sta n d a rd reduction to ro o t norm al form,
and th e n continuing recursively on th e top-level argum ents.
E x a m p le : h r e v e r s e [7 * 12,100 — 12] = [89 — 1, 83 + 1]
-^Reduce NF A l l . ►
h [88, 84] = [88, 84]
N o te s ( 1 ) : An artificial lim it is im posed on th e m axim um num ber of reduction
steps in order to safely h andle no n -term in atin g reductions.
N o te s ( 2 ) : T his ta c tic can also be configured to reduce n steps; or to reduce to
root norm al form; or to reduce a specific redex; or to reduce w ithin a hypothesis.
R e fin e U n d e fin e d n e s s .
T y p e : Equivalence; backw ards; logic.
In fo : Refines undefinedness equalities.
D e ta ils : A tte m p ts to refine all undefinedness equalities in th e cu rren t goal of
th e form ( S E i . . . E n ) = ± , w here S is eith er a con stru cto r or a haltin g function.
Replaces th e eq u ality w ith th e disjunction of all E i = ± where E i is on a strict
position an d n o t statically know n to be defined.
E x a m p le : x , y h (x + y) — 13 = ±
^ R e f in e U n d e f in e d n e s s . ►
x , y h (x + y) = ±
N o te s : T his ta c tic can also be applied in a forwards m anner on a hypothesis.
R e f le x iv e .
T y p e : In stan tan eo u s; logic.
In fo : U tilizes th e reflexivity of th e b u ilt-in o p erators = and ^ .
D e ta ils : Im m ediately proves any goal of th e form y x i ...xn - P \ ^ - ■■Pm ^ Q, where
Q is eith er E = E or P ^ P .
E x a m p le : h y x 3 y ■x < y ^ x + y = x + y
^ R e f le x iv e .►
Q .E.D .
Rename <Name1> t o <Name2>.
T y p e : Special.
In fo : R enam es an intro d u ced variable or an introduced hypothesis.
E x a m p le : x , y h x < y — —(x = y)
^Rename x t o z . ^
z , y h z < y — - ( z = y)
43
R e w rite < f a c t> .
T y p e : U sually strengthening, depends on fact; backw ards; logic.
In fo : R ew rites th e cu rren t goal using an equality in a fact.
D e ta ils : A fact is either an earlier proved theorem or an in troduced hypothesis,
and m ust be of th e form Vx i ...x n.Pi — .. .P m — Q, where Q is eith er L = R or
L ^ R. It is only valid if r i .. . r n can be found such th a t L[x* — ri ] occurs
w ithin th e to prove. If th is is th e case, th e n all occurrences of L [xi — r^i ] are
replaced w ith R[x.i — r i ]. F urtherm ore, goals are created for each condition of
th e fact; th e i-th sta te s P i [— — — ].
E x a m p le : p, (H1:Vx .—(x = ± ) — x * 0 = 0} h (p — 7) * 0 = 0
-^R ew rite H 1 .►
(1) p, (H1:Vx .—(x = ± ) — x * 0 = 0} h 0 = 0
(2) p, (H1:Vx .—(x = + ) ——x * 0 = 0} h— -(p — 7) = +
N o te s : T his ta c tic can also be configured to rew rite from right to left; or to
rew rite a t one specific location only; or to rew rite w ithin a hypothesis.
S p e c i a l i z e <Hyp> w ith < E xpr> /< P rop> .
T y p e : Strengthening; forwards; logic.
In fo : Specializes a universally quantified hypothesis.
D e ta ils : T he hypothesis m ust be Vx . P , and th e given ex p ression/proposition r
m ust have th e sam e ty p e as x. T hen, th e hypothesis is replaced w ith P [x — r].
E x a m p le : x , y , z , (H 1 :x < y }, (H2:y < z }, (H3:Va . x < a — a < z — x < z } h x < z
^ S p e c i a l i z e H3 w ith y . ^
x, y, z, (H1 : x < y } , (H 2:y< z}, ( H 3 :x < y — y < z — x < z } h x < z
S p lit.
T y p e : Equivalence; backw ards; logic.
In fo : Splits a conjunction into sep arate goals.
E x a m p le : P, Q, (H 1:P ), (H2:Q) h P A Q
^ S p lit. ►
(1) P ,Q , (H 1 :P ), (H2:Q) h P
(2) P ,Q , (H 1 :P ), (H2:Q) h Q
N o te s : T his ta c tic can also be applied in a forwards m anner on a hypothesis.
44
S p litC a s e <Num>.
T y p e : Strengthening; backw ards; program m ing.
In fo : Splits a case expression into its alternatives.
D e ta ils : T he case expression th a t will be split is indicated by m eans of an index
(cases are num bered from left to right sta rtin g w ith 1). A new goal is created for
each of th e altern ativ es of th e case, including one for ± and one for th e default.
In each goal, th e case expression is replaced by th e result of th e alternative.
H ypotheses are intro d u ced to indicate which altern ativ e was chosen.
E x a m p le : xs, (H i :-i(xs = ^ ) } h c a s e xs o f ( [y : ys] ^ y; _ ^ 12) > 0
^ S p l i t C a s e !..►
(1) xs, (H i:- ( x s = ^ ) } , (H2:xs = + }
> 0
(2) xs, y, ys, ( H i:-(x s = ^ ) } , (H2:xs = [y : ys] } h y > 0
( 3 ) xs, (H i:- ( x s = ± )} , (H2:xs = []} h 12 > 0
S p l i t I f f . _________________________________________________________________
T y p e : Equivalence; backw ards; logic.
In fo : Splits a ^ in to a — and a ^ .
D e ta ils : T he cu rren t goal m ust be of th e form P ^ Q. Two goals are created,
one for w ith P — Q an d one for Q — P .
E x a m p le : P, Q, (H 1:P — Q), (H2:Q — P ) h P ^ Q
^ S p litI ff .►
(1) P, Q, (H 1:P — Q), (H2:Q — P ) h P — Q
(2) P, Q, (H 1:P — Q), (H2:Q — P ) h Q — P
N o te s : T his ta c tic can also be applied in a forwards m anner on a hypothesis.
S ym m etric.
T y p e : Equivalence; backw ards; logic.
In fo : U tilizes th e sy m m etry of th e b u ilt-in o p erators = and ^ .
D e ta ils : T he cu rren t goal m ust be of th e form VXl...Xn .P1— . . . Pm — Q, where
Q is either E 1 = E 2 or Q \ ^ Q 2. If th is is th e case, th en Q is replaced w ith
E 2 = E 1 if it was a = , an d w ith Q 2 ^ Q 1 if it was a ^ .
E x a m p le : x, (H1: x = y) h y = x
-^ S y m m etric .►
x, (H1: x = y) h x = y
N o te s : T his ta c tic can also be applied in a forwards m anner on a hypothesis.
45
T r a n s i t i v e < E xpr> /< P rop> .
T y p e : Equivalence; backw ards; logic.
In fo : U tilizes th e tra n sitiv ity of th e b u ilt-in o p erators = and ^ .
D e ta ils : If th e argum ent T is an expression, th en th e cu rren t goal m ust be of
th e form E i = E 2; if T is a proposition, th e n it m ust be of th e form P i ^ P 2.
Two goals are th e n created, one sta tin g E i = T (or P i ^ T ), and th e other
sta tin g T = E 2 (or T ^ P 2).
E x a m p le : p h p < p + 2
- ^ T r a n s itiv e (p + 1 ). ►
(1) p h p < p + 1
(2 ) p h p + 1 < p + 2
T r a n s p a r e n t.
T y p e : Special.
In fo : M arks a function as expandable.
D e ta ils : U ndos th e effect of O paque.
E x a m p le : h z i p ( [ ] , []) = []
-^Opaque z ip 2 ; T r a n s p a r e n t z ip 2 ; Reduce NF A ll. ►
h [] = []
T r i v i a l . _________________________________________________________________
T y p e : In stan tan eo u s; logic.
In fo : Proves th e triv ial p roposition TRUE.
D e ta ils : Im m ed iately proves any goal of th e form VXl...Xn.P 1— . .. Pm— TRUE.
E x a m p le : h VP .P — —P — TRUE
^ T riv ia l. ►
Q .E.D .
U n c u rry .
T y p e : Equivalence; backw ards; program m ing.
In fo : U ncurries all applications in th e cu rren t goal.
D e ta ils : Forces all curried applications ( f x i .. . x i ) x i + i .. . x n in th e current
goal to be u n cu rried to f x i .. . x n .
E x a m p le : h [((+) 1) 1 : map ((+ ) 1) [ ]] = [2]
-^ U n c u rry .►
h [1 + 1 : map ((+ ) 1) [ ]] = [2]
N o te s : T his ta c tic can also be applied in a forwards m anner on a hypothesis.
46
Undo <num>.
T y p e : Special.
In fo : U ndos th e last n steps of th e proof.
D e ta ils : S p a r k l e does not m em orize th e last actions of th e user. Instead, n
upw ards steps in th e proof tree are m ade.
E x a m p le : h Vxs.xs ++ [] = []
-^ In d u c tio n x s ; R educe. Undo 2 . ^
h Vxs.xs ++ [] = []
W itn e ss < E xpr> /< P rop> .
T y p e : Strengthening; backw ards; logic.
In fo : Chooses a w itness for an existentially quantified goal.
D e ta ils : T he cu rren t goal m ust be of th e form 3 x . P , and P [x — T ] (where T
is th e te rm argum ent) m ust be w elltyped. If th is is th e case, th e n th e goal is
replaced w ith P [x — T ].
E x a m p le : h 3 x .x * x = x
-^W itness 1 . ^
h 1*1=1
N o te s : T his ta c tic can also be applied in a forwards m anner on a hypothesis.
47