Microsemantics as a Bootstrap in Teaching Formal Methods

Transcription

1 Microemantic a a Boottrap in Teaching Formal Method Raymond Boute INTEC Univeriteit Gent, Belgium Raymond.Boute@intec.UGent.be Abtract Introducing an elementary form of program emantic early in the curriculum provide a good preamble to formal method. Microemantic ue only the mot baic concept in formal mathematic, namely ubtitution, and therefore can be preented a early a the econd lecture of a frehman-level coure. It can ubequently erve a a boottrap for gradually introducing mot of the other fundamental concept of formal method, leading up to formal ytem pecification and deign. Keyword: calculational reaoning, domain-independent problem, formal method, lambda calculu, microemantic, tate equation, ubtitution, program emantic, teaching 1. INTRODUCTION In a recent paper [7], we argued that the bet way for making formal method widely accepted a a elf-evident part of profeional practice in computer-related area of engineering i by enuring that our educational intitution provide a maive injection of qualified people into indutry. Doing o require a curriculum where formal method are not taught in a few iolated coure, but rather where all coure et the example by ytematically uing mathematical modeling which, a Parna [15] aptly oberve, i the major ability ditinguihing profeional engineer from other deigner. Thi view underlie the common educational model in claical engineering, but many computer-related curricula and coure have coniderable catching up to do. Solid foundation upon which all other coure can rely clearly mut be laid at the tart of the curriculum. In order to make the inherently high abtraction level acceible to mot tudent, it i neceary to provide a variety of conceptual and application illutration and exercie. Yet, in the firt year mot tudent till have very limited domain-pecific (technical) knowledge. For thi and other reaon, it i advantageou to ue domain-independent example and problem [7]. The upply of uch problem i very rich and varied. However, the olution typically given are meant to how cleverne rather than ytematic formulation and reaoning. Often not only the reaoning tep but even the initial cating into mathematical formula i coare and ha eriou gap. Filling thoe gap, in both expreion and reaoning, contitute an added dimenion. In the ame paper [7], we alo conidered a cla of domain-independent problem or puzzle where the gap are due to the fact that the problem i tated procedurally or operationally, wherea the olution mut be uccinct and declarative. Here i an example of uch a problem, found on a lit of problem poted by Dahlke [8], but reformulated here for the ake of brevity. A chool ha 1000 tudent and an array of 1000 locker, all initially cloed. All tudent walk along the row one after the other, and the k th tudent invert the tate of every k th locker, that i: open the locker if it wa cloed and vice vera. How many locker are open in the end? Since claical mathematic ha no framework for decribing procedure, traditional olution make a fairly large jump from the informal procedural tatement to the mathematical equation from which the final olution i derived. Programming language on the other hand are uitable for expreing procedure, and hence can help in accurately formalizing the procedure expreed in word in the problem tatement. Here i uch a formalization for the preceding example: Teaching Formal Method: Practice and Experience, 15 December

2 for k in 1..K do (for n in 1..N do if (k divide n) then inv (L n) fi od) od, auming K tudent and an array L of N locker (defining inv for inverion i not relevant here). Yet, uing a programming language reduce only the gap between informal and formal problem tatement at the procedural level, but the gap between the procedure and the mathematical equation leading to the final olution remain and ha become even more viible. Clearly, the bridge from program to equation i provided by mathematical emantic. More pecifically, we need a formalim to derive, from a program text, mathematical equation that expre the program behavior. Thi amount to mathematically modeling a procedure in the ame pirit a an electronic engineer model a circuit by deriving, from the circuit diagram, mathematical equation that expre the circuit behaviour. To be uitable already within the firt week of a frehman-level coure, the formalim hould be very lightweight, and in proportion to the perceived implicity of the puzzle of interet. Our approach, firt outlined in [7], meet thi requirement, and i therefore named microemantic. The principle of microemantic, guideline for it ue and a few example are preented in ection 2, wherea ection 3 outline how it can be ued for boottrapping fundamental concept uch a equational reaoning, lambda calculu, propoitional and predicate logic, finally leading to formal ytem pecification and deign at the end of uch a coure. 2. MICROSEMANTICS For achieving the extremely lightweight formalim needed for the tated purpoe, we ue only the mot baic concept in formal mathematic, namely ubtitution, a decribed, for intance, by Grie and Schneider in [10, Chapter 1]. Thi i the limited toolkit aumed at thi tage. Subtitution Subtituting expreion d for variable v in expreion e i written e[ v d. An example: (x + 3 y)[ y z+1 = x + 3 (z + 1). We ue = for yntactic equality. A warning: if parenthee in d are omitted according to the uual convention, it may be neceary to reintate them for ubtitution, e.g., around z + 1 in the preceding example. By an obviou generalization, v and d may be tuple, a illutrated by (x + 3 y)[ x, y a y, z+1 = a y + 3 (z + 1). Multiple ( imultaneou ) ubtitution do not necearily have the ame a ucceive ubtitution. With the general convention that one may write e[ v c[ w d for (e[v c)[ w d, thi i hown by (x + 3 y)[ x a y[ y z+1 = (a y + 3 y)[ y z+1 = a (z + 1) + 3 (z + 1). One can ee [ v d a a (metalevel) yntactic operator on mathematical expreion. Program equation The tate i a tuple whoe element correpond to the program variable, in the order and with type a declared. Let be the tuple made from the variable themelve. Such a variable lit turn out to be ueful in unifying theorie [6] and in microemantic. The term command deignate intruction a well a entire program. A command c i modeled a a function from tate to tate, defined by an axiom of the form c = e. Thi i a familiar tyle for defining function in mathematic, a hown in defining quare by quare x = x x. Such axiom are ued or applied by intantiation [10, Chapter 1]; more pecifically, (c = e)[ d = c d = e[ d. For ubtitution, command are treated a function contant [10, Chapter 1], i.e., are not affected. Firt we conider the primitive command aignment (v := e), compoition (c ; c ), election (if b then c ele c fi), where c and c are command and b a boolean expreion: (v := e) = [ v e (1) (c ; c ) = c (c ) (2) (if b then c ele c fi) = b? c c. (3) Teaching Formal Method: Practice and Experience, 15 December

3 The lat right hand ide i a conditional expreion. It general form i b? e 1 e 0, read in word a if b then e 1 ele e 0 and formalized by the axiom (b? e 1 e 0 ) = e b where b i 0 or 1. Uing a the formal argument in (1) and (3) enure their imple and intuitive form; for (2) it i unimportant. The following are derived command, ince they can be defined in term of the primitive one. kip = (v := v) (or, a a primitive command, kip = ) (4) (if b then c fi) = (if b then c ele kip fi) (5) (while b do c od) = (if b then (c ; while b do c od) fi). (6) Oberve that microemantic i fully minimalit in the ene that it involve no other notation than the baic expreion and command that may occur in the imple program themelve and ubtitution. The machinery of denotational and axiomatic emantic, which may be intimidating if preented in the firt few week, i bypaed. Of coure, it can be introduced at a later tage. Guideline for ue and example A a matter of convention, we write program variable in typewriter font (e.g., x) and the matching tate variable in italic (e.g., x). Thi ditinction ha no calculational conequence and i for expoition only: if it help, fine, otherwie it can be afely ignored (which i convenient in handwriting, where the ditinction i eaily lot anyway). About aignment We tart with an example. Aume a program with variable x and y, declared a integer, o the tate i the pair (x, y). For the aignment x := x + y, (x := x + y) (x, y) = Axiom (1) (x, y)[ x x+y = Subtitut. (x + y, y). (7) Axiom (1) alo cover multiple aignment, i.e., of the form (v := e) where v i a tuple of variable and e i a tuple of expreion. An example i wapping two variable: (x, y := x, y) (x, y) = Axiom (1) (x, y)[ x,y y,x = Subtitut. (y, x). Intantiating correctly Clearly (x := x + y) (2, 3) = (5, 3) by intantiating the reult from (7). More generally, recall that intantiating c = e by [ d yield c d = e[ d and hence, for Axiom (1), (v := e) d = ([ v e)[ d. (8) Warning: it i tempting but wrong to write ([ v e)[ d a d[v e. Interetingly, thi warning i more relevant for advanced uer prone to kip tep than for beginner who tend to apply the rule meticulouly. About program tructure Oberve the tyle of (1.. 6), where c and c in turn tand for arbitrary command. By aying that the left hand ide (omitting ) are the only form for command, the yntax i pecified a well. More pecifically, the tructure of a program i decribed recurively in the ene that it i either the mot elementary command (i.e., an aignment), or a compoition of two command, or a election between two command. The latter command are again arbitrary: each of them can again be an aignment, a compoition or a election etc.. Axiom (1.. 6) illutrate how a (emantic) function can be defined by recurion on (program) tructure. About compoition At thi tage, we can prove an intereting algebraic program property: (c ; (c ; c )) = ((c ; c ) ; c ) (exercie). (9) Thi mean that (c ; (c ; c )) = ((c ; c ) ; c ), at leat for the particular tate emantic conidered in thi note. A i cutomary with aociative operator in mathematic, we make the parenthee in compoition optional. We alo make other parenthee optional inofar a replacing them i obviou (in a formalizable way). Thi give rie to an intereting illutration about handling yntactic and emantic ambiguity, dicued elewhere in the coure. The typical error to which we alluded in the warning about intantiating correctly i hown in the loppy calculation (c ; v := e) = (v := e) (c ) = (c )[ v e, wherea (8) yield the correct ([ v e)[ c. Teaching Formal Method: Practice and Experience, 15 December

4 It i intructive to exercie with ucceive aignment. An example i wapping x and y uing an auxiliary variable z, a done by the program z := x ; x := y ; y := z. Here i a fully detailed calculation for the final tate if the initial tate i x, y, z (exercie: uing a, b, c intead). (z := x ; x := y ; y := z) (x, y, z) = Ax. (2) (y := z) ((x := y) ((z := x) (x, y, z))) = Ax. (1) (y := z) ((x := y) (x, y, z)[ z x) = Subt. (y := z) ((x := y) (x, y, x)) = Ax. (1) (y := z) (x, y, z)[ x y[ x,y,z x,y,x = Subt. (y := z) (y, y, z)[ x,y,z x,y,x = Subt. (y := z) (y, y, x) = Ax. (1) (x, y, z)[ y z[ x,y,z y,y,x = Subt. (x, z, z)[ x,y,z y,y,x = Subt. (y, x, x). Thi how both the power of ubtitution (it can do the job all by itelf) and it limitation (tediou). Selection and iteration Familiarizing the tudent with election i fairly traightforward. The equation for loop are recurive, and therefore olving them i a good introduction to recurion and iteration. Thi i a topic for later in the coure, a outlined next. 3. MICROSEMANTICS FOR BOOTSTRAPPING FUNDAMENTAL CONCEPTS Microemantic provide a running example for gradually introducing the fundamental concept underlying formal method in an introductory coure. The following i jut an outline. Syntax, axiomatic, emantic, pragmatic Generally it i not a good idea to burden beginning tudent with technicalitie. However, microemantic offer opportunitie for giving a imple and concrete firt explanation about the ditinction and relation between yntax (here: expreion and command), axiomatic (formal calculation rule), emantic (variou view on meaning) and pragmatic (to what purpoe notation and rule are deigned in a particular way). Equational reaoning The earlier calculation already provide an example of equational reaoning, although it involve a purely yntactic (meta-)operator, namely, [ for ubtitution. The obviou next tep i equational reaoning involving only function and expreion in the language (baic mathematic), for which it uffice here to mention the the firt chapter in [10]. Lambda calculu Lambda notation i intuitive enough to be undertood a a finihed product. However, after microemantic one can provide an extra dimenion, howing how to re-invent lambda calculu from the pragmatic (uage) viewpoint by making optimal deign deciion. We tart by analogy with the convention of partial application [5] of mathematical operator. Thi mean that the application of an operator to part of it argument form an operator that can be applied to the ret 1. Uing thi convention for the meta-operator for ubtitution make the earlier [ v d one of the poible partial application. However, [v d ha v a a dangling reference, which permit only inelegant calculation rule. A different partial application that ha no dangling reference 2 and hence permit elegant calculation rule i e[ v. For thi, we adopt the alternative notation λv.e, which i the baic form for (impure) lambda term. Clearly, (λv.e)d = e[ v d. Now we can alo rewrite axiom of the form c = e a c = λ.e. For intance, axiom (1) can be written (v := e) = λ.(λv.)e. Similarly, lambda combinator can be deigned for compoition and election, which reader familiar with lambda calculu will ee a traightforward. Thi et the tage for preenting formal calculation rule for lambda term [2] followed by a firt introduction to variable-free expreion with combinatory logic [2] a an archetype, and generic functional [4] for practical ue. 1 Thi mut not be confued with currying: it pertain to an operator taking a tuple a it only argument, and a partial argument then conit of ome element of the tuple. 2 For the inider : not to be confued with free variable; thee may till be preent. Teaching Formal Method: Practice and Experience, 15 December

5 Propoitional and predicate logic A oon a program involve a few conditional and domain of dicoure other than baic arithmetic, the need for propoitional and predicate logic arie, and can be atified by the proper chapter in [10] or by our own functional variant [3, 5]. Induction A oon a program with loop are conidered, the equation decribing their behavior are recurive, and calculational reaoning about thi i bet upported by induction. We have found that notion about induction that tudent may have retained from previou coure, e.g., in high chool, may lead them into all kind of pitfall. Mot typical error amount to intantiating the induction hypothei. So here i the opportunity for etting thing traight by explaining the tructure of inductive proof, the relation with well-foundedne, variou proof tyle, other form of induction than over number only (tructural, e.g., over lit) and o on. Relation In the form preented, microemantic ue ante/pot function, which cover only determinitic program. By analogy with certain tate equation in elementary mechanic [6], we introduce ante-expreion e derived from expreion e by replacing all tate variable v by v (uing ante-quote), correponding to the tate before a command i executed. Note that, by thi convention, e = e[. Similarly, e = e[ for pot-expreion correponding to the tate after a command i executed. The functional model of the form c = e (for a command c) can thereby be generalized to a relational model of the form 3 c p a Hehner book [11] if only one kind of emantic i wanted, or R c p a in [6] if everal emantic are wanted. Hence relation pave the way to nondeterminitic program and formal pecification. Furthermore, at thi tage of the coure, a ufficient bai i available for dicuing extremal element (maximum and minimum, greatet and leat, upper and lower bound), the variou kind of ordering (preorder, partial order etc.) mot encountered in the theory and practice of programming, and the variou tyle of calculating with relation (point-wie, point-free). 4. RELATION TO OTHER COURSES AND TOPICS Formal pecification and deign of ytem For a firt-year coure, the preceding material will uually need preading over a complete emeter (ay, 2 lecture and 2 exercie eion 4 per week during 12 week) for allowing the tudent to develop adequate undertanding and kill. Yet, it would benefit from further conolidation and practicing by a econd emeter on formal ytem pecification and deign. The emphai can be on ytem theory and hybrid ytem (in the pirit outlined by Lee and Varaiya [14]) or on oftware ytem (program emantic, model checking etc. [13]) depending on whether the coure i meant to be EE or CS oriented. Coure on programming Optimally, a coure a outlined in Section 3 hould tart no later than introductory programming, allowing the latter to be taught with proper foundation and attitude. Moreover, for introductory programming, functional language would be mot uitable, although few univeritie eem to have the courage to make uch a deciion. It functional tyle make microemantic a convenient early link between imperative and functional language. However, it i meant only a a boottrap auming minimal prerequiite, wherea, for realitic program derivation, practical method in the line of axiomatic emantic mut be covered [6, 11]. Coure on formal emantic Formal emantic i to the oftware engineer what device and circuit theory i to the electronic engineer. It elimination from certain curricula (in favor of baic coure on programming language that any engineering or CS tudent hould be able to learn independently a part of the preparation for the exercie eion of other coure) i unjutified. However, a coure a outlined in Section 3 would lower the threhold for (re-)introducing formal emantic in the pirit of unifying theorie of programming [6, 12] Taking microemantic a an introductory example, it unification with axiomatic emantic wa outlined earlier in the context of relation. Here we outline it unification with the claical denotational tyle. Let the denotational-tyle meaning function be C for command and E for expreion. For intance, for ingle-variable aignment, C (v := e) σ = (v E e σ) > σ where, 3 Aide: Hehner doe not ue antequote, and jut write. In [6] we how when and how antequote are convenient. 4 Auming 75 minute each, the tandard at Ghent Univerity. Arguably, for lecture 3 x 50 min. i better than 2 x 75 min. Teaching Formal Method: Practice and Experience, 15 December

6 a uual (up to notational difference), the tate σ i a function from variable to denotation, make maplet, and > i function overriding. Since the interpretation of mathematical equation i common to both emantic and hence trivial for the unification, we factorize it out and take the common denotation domain to be the et of expreion, keeping everything purely yntactic. Writing µ for the mapping from denotational-tyle tate to microemantic-tyle tate, unification i etablihed by proving µ (C c σ) = M c (µ σ) for any command c and denotational-tyle tate σ, where we made the microemantic denotation function M explicit jut to eliminate it hitherto privileged tatu. For intance, for aignment we mut prove µ ((v E e σ) > σ) = ([ v e)[ µ σ. Uing the propertie of generic functional [4], thi take only a few line. 5. CONCLUSIONS We have outlined how a firt-year preamble to formal method can be contructed around microemantic. Of coure, for the ake of diverity, other kind of application example and problem mut be included a well, preferably domain-independent [7] for the majority, but alo ome domain-pecific cae requiring only prior knowledge from high chool or parallel coure. Our own coure of thi kind [3] emphaize clean formalization and calculational reaoning [10] right from the beginning, placing the inight gained from Computing Science [9] at the dipoal of our tudent. Avoiding poor practice i alway eaier than correcting them afterward. A final practical remark: microemantic i too recent for having been incorporated in [3], but will appear in a future verion. We hope that, meanwhile, other teacher may benefit from the idea. REFERENCES [1] Roland Backhoue (2005), Algorithmic Problem Solving. Lecture Note, Univerity of Nottingham. On the web: [2] Henk P. Barendregt (1984), The Lambda Calculu, It Syntax and Semantic, North-Holland. [3] Raymond Boute (2002), Functional Mathematic: a Unifying Declarative and Calculational Approach to Sytem, Circuit and Program Part I. Coure note, Ghent Univerity. On the web via [4] Raymond Boute (2003), Concrete Generic Functional: Principle, Deign and Application, in: Jeremy Gibbon and Johan Jeuring, ed., Generic Programming, , Kluwer. [5] Raymond Boute (2005), Functional declarative language deign and predicate calculu: a practical approach, ACM Tran. Prog. Lang. Syt., 27, [6] Raymond Boute (2006), Calculational emantic: deriving programming theorie from equation by functional predicate calculu, ACM Tran. Prog. Lang. Syt., 28, [7] Raymond Boute (2006), Uing Domain-Independent Problem for Introducing Formal Method, in: Jayadev Mira, Tobia Nipkow, Emil Sekerinki, ed., FM 2006: Formal Method, Springer LNCS [8] Karl Dahlke, Fun and Challenging Math Problem for the Young, and Young At Heart, on the web: [9] Edger W. Dijktra (1990), How Computing Science created a new mathematical tyle, EWD Univerity of Texa at Autin. On the web: [10] David Grie and Fred Schneider (1993), A Logical Approach to Dicrete Math. Springer. [11] Eric C. R. Hehner (2004), A Practical Theory of Programming (2nd edition). Springer. Regularly updated verion on the web: [12] C. Antony R. Hoare, He Jifeng (1998), Unifying Theorie of Programming. Prentice-Hall. [13] Lelie Lamport (2002), Specifying Sytem: The TLA+ Language and Tool for Hardware and Software Engineer. Addion-Weley. [14] Edward A. Lee and Pravin Varaiya (2000), Introducing Signal and Sytem The Berkeley Approach. Firt Signal Proceing Education Workhop, Hunt, Texa, Oct On the web: [15] David L. Parna (1993), Predicate Logic for Software Engineering, IEEE Tran. SWE, 19, Teaching Formal Method: Practice and Experience, 15 December