A Metalanguage for Interactive Proof In
Total Page：16
File Type：pdf, Size：1020Kb
Conference Record of the Fifth Annual ACM Sym~sium on Principles of Programming Languages A Metalanguage for Interactive Prcof in ICE’* M. Gordon, R. Milner University of Fdinburgh L. Morris Syracuse University M. Newey Australian National University C. Wadsworth University of Edinburgh Introduction cqmting system) of ML and PPI began over three years ago at Edinburgh; for abut two years the LCF (Icqic for Caqmtable Functions) is a system has keen usable, and its development is now prcof generating system mnsisting of an inter- virtually ccmplete. Recently it has been used in active programing language MG (MetaLmguage) for various studies concerning formal semantics: mnducting prcofs in PPA (Polynmrphic Predicate theorems about data structures, recursion remval, A-calculus) , a deductive calculus suitable for the direct versus continuation semantics, and Other formalisation of reasoning almut recursively topics. defined functions, in particular about the syntax, semantics and iq?lementations of many prqrcmming The need for and design of ML is based on languages. PPI is an enrichment (in respect of experience with an earlier system at Stanford type structure and expressive pcwer) of an extended [17, 181 . In that system, beyond the ability to a-calculus due to Dana Scott and is fully discussed direct it to execute a basic inference (e.g. beta elsewhere [ 22 I . The puxposes of this paper are conversion, or transitivity of equivalence) , the (a) to illustrate the features of ML which me user could it of general interest in language design (a) invoke .s@lif ication with respect to a set quite independently of its use for machine of equivalences specified by him, assistd formal pxcof, (b) adopt a goal-directed pr~f style, gener- (b) to illustrate ML applied to PPA, in ating subgoals by built-in tactics based encoding interesting prcof -finding-and- qn the inference rules and simplification, perfonning procedures, and and (c) to convey a methodology for controlled semi- (c) use theorems previously proved. automatic proof. These facilities were enough to enable several We avoid formal descrj ption; we hope that our non-trivial case studies to be tackled [1,23,24,34] qles and discussion will achieve these purposes but further use of the systein hecam increasingly mme clearly. A qlete description of ML, and limited by the fixed, and rather primitive, nature its use with PPA, exists as a techriical reprt [91. of its repertoire of ccmnands (rather like using an interactive assenbly language - and one without The in@enemtation (using LISP on a DEC 10 —.- a prow stirou~e feature at mat: - in whim W’his work was supprted by the Science I@search one is working all the t- at top-level) . Prcnfs Council of Great Britain under grant n- oft.em contained many instances of a few patterns of B/RG/48175. inference which one would like to express as 119 derived inference rules or - in the goal-directed prcofs, the following ingredients in ML were soon style - as derived tactics or strategies. found to be expedkmt (almost necessary) : the ability to handle higher order functions, a rigorous Our present point of view is that neither a but flexible type structure, a mechanism for gen- straightforward prcof -checker ( lalmrious and re@t- erating and trapping failures, and an abstract itive to use) nor an autcmatic theorem-prover synta~ic rePres-tation of the object language (inefficient because of general search) is satis- PPa . factory. What is required is a framswork in which a user can both design his own partial prmf Acknowledgments strategies (where he can find them) and execute single steps of proof (where he needs to) . We We are indebted to Dana Scmtt for providing believe also that, although formal proofs are @?- a large part of the theoretical basis for oux vmrk: ortant and should be retrievable, it is pragmatic- to John McCarthy for encmrcaging the forerunner of ally more convincing to achieve clear expression of this project at Stanford: to Richard Weyhrauch who p~f strategy; the latter entails that the way in contributed greatly to that project: to Tony Hoare which the strategy is built from sub-stratqies and Jexry Schwarz for help with the notion of should be evident in its expressicm. abstract -s in ML : to Avra Cohn for help in the final design stages through her experiments: In other words, we’ re not so concerned with to Rod Burstall and many colleagues in ~inburgh checking or generating prcofs as with per forming for ilhnnina ting discussions. procf s . ‘RnJs, we don’ t normally store or display proofs but only the results of them - i.e. theorems. These form an abstract type on which the only allowed operations are the inference rules of PPI ; this ensures that a well-typed pnqcam carmot Outline of ML. perform faulty proofs (it may not prove the theorem ML is a higher-crder functional programing expected but the result ~ be a theorem!) . If language in the tradition of ISWIM [15], PAL [8], extra security or formal prcof -checking is desired, POP2 [6] and @DANKEN [26 1, but differs princip- full proofs are easily generated - only minor ally in its handling of failure and, more so, of changes in the implementation of the abstract t~ typ2s . It is an expression-based language, for theorems wmld be required. though expressions may have side-effects because The principal aims then in designing ML were of the presence of assignment (the expression to make it impossible to prove non-theorems yet “X: =e” has as value the value of e , and also easy to prcgram strategies for performing pnmfs. gives x this value) . An @mrtant expression A strategy - or recipe for proof - cm.dd be scane- construct is “let x = e —in e’”, which binds x thing like “induction on f and g , f ollad by to the value of e throughout e‘ ; alternative assuning antecedents and doing case analysis, all forms of declaration are “let f (x,y,. ..) = e“ interleaved with sinplif ication”. This is for def irdng functions, “letrec f (x,y,.. ) = e“ inprecise - analysis of what cases? - what kind of for defining functions recursively, “letref x = e” induction, etc, etc. - but these in turn may well for declaring and initializing assignable variables, be given by further recipes, still in the sam and generalizations of these forms for s~taneous style. The point is that such strategies appear declarations. to be built frcm sinpler ones (which we call Another imprtant expression construct is tactics rather than strategies) by a number of ‘Ie ? evtp (read “e or else e’”), whose value is the general operations in fairly regular ways; we value of e unless e generates a failure, in which call these operations tacticals by analcgy w’ith case it is the value of e’. The systen generates functional. certain failures autcnnatically, and the user may For progr arming tactics and tacticals, and generate his own with the expression “fail”, or mre generally for manipulation of PP1 in f ind.ing the expression “failwith e“ where the value of e 120 is a token which identifies the kind of failure; Notes: (1) “letrec f(x,y, z)(urv) = - - -“ a generalization of the form “e ? e’” can be used is equivalent to to trap only certain failure tokens (kinds of “letrec f = l(x,y, z).l(u,v). - - -“. failure) . The type token is one of ML’s basic (Similarly, let . ..). That is, scala.r- types; tokens are just synbol strings. In our prod and”itscalarprod are defined here current application of ML, the use of failure as a as (partially) curried functions, as dynamic escqe and escape-trapping mechanism facil- is the style in functional progrann.ing. itates a natural programing style for caqosing The separation of argments into two tactics and strategies which are usually inapplic- groups allows scalarprcxi to be able to certain goals. “partially applied” to three argummts to obtain particular scalar prcduct AS hinted above, if d is a declamation and: functions; it also suggests a more e an expression, then “d —in e“ is an expression. efficient recursive definition in which In interactive prcgramning (which is how prcofs we replace are conducted) , one evaluates a mixed sequence of declarations and expressions, separated by “;;” . letrec scalarprcx3($*, $+, zero) (kl,12) = ML is a “static binding” language, like ISWIM, PAL - - -scalaqrod ($*, $+, zero) (11’, ~2’)- - and GEDWWEN (but unlike LISP and FOP2) ; a free by a form which recurses on only & variable z in the declaration “let f(x) = . ..” arguments, nawly refers to the textually enclosing declaration of let scalarprcd($*., $+, zero) = scalp z , not to any subsequat declaration. whererec scalp (!l, t2) = An example which illustrates most of the --- scalp (n’ ,12’) - - - features of MT is a generalised scalar product (2) Prefixing $ to a token enables its use (sum the prcducts of two vectors) which is param- as a binaq infix without the $. eterised on its prcduct and sunnnation functions and on a zero (for null vectors) . Two ways - the (3) Infixed “.” is the cons function. Use first recursive and the second iterative - of on the left of a declaration, as here, writing this in ML, with vectors represented as binds xl and kl’ to the head and tail, lists and failure for vectors of unequal length, respectively, of !1, with failure when are as follows: U is null. letrec scalarprod ($*, $+, zero) (.U,~2) = (1,2) (4) The failure trappd by “?” here is that ( —let xl. il’ = L1 —and x2. L2’ = ~2 (.3) of the declaration when one of R1, L2 in (x1*x2) +5Cakqwcd($*, $+rzero) (!1’ ,X2’ ) is null. ); (4) (5) “q e“ repeats e until failure.