A Formal Methodology for Deriving Purely Functional Programs from Z Specifications Via the Intermediate Specification Language Funz

Total Page:16

File Type:pdf, Size:1020Kb

A Formal Methodology for Deriving Purely Functional Programs from Z Specifications Via the Intermediate Specification Language Funz Louisiana State University LSU Digital Commons LSU Historical Dissertations and Theses Graduate School 1995 A Formal Methodology for Deriving Purely Functional Programs From Z Specifications via the Intermediate Specification Language FunZ. Linda Bostwick Sherrell Louisiana State University and Agricultural & Mechanical College Follow this and additional works at: https://digitalcommons.lsu.edu/gradschool_disstheses Recommended Citation Sherrell, Linda Bostwick, "A Formal Methodology for Deriving Purely Functional Programs From Z Specifications via the Intermediate Specification Language FunZ." (1995). LSU Historical Dissertations and Theses. 5981. https://digitalcommons.lsu.edu/gradschool_disstheses/5981 This Dissertation is brought to you for free and open access by the Graduate School at LSU Digital Commons. It has been accepted for inclusion in LSU Historical Dissertations and Theses by an authorized administrator of LSU Digital Commons. For more information, please contact [email protected]. INFORMATION TO USERS This manuscript has been reproduced from the microfilm master. UMI films the text directly from the original or copy submitted. Thus, some thesis and dissertation copies are in typewriter face, while others may be from any type of computer printer. H ie quality of this reproduction is dependent upon the quality of the copy submitted. Broken or indistinct print, colored or poor quality illustrations and photographs, print bleedthrough, substandardm argins, and improper alignment can adversely affect reproduction. In the unlikely, event that the author did not send UMI a complete manuscript and there are missing pages, these will be noted. Also, if unauthorized copyright material had to be removed, a note will indicate the deletion. Oversize materials (e.g., maps, drawings, charts) are reproduced by sectioning the original, beginning at the upper left-hand comer and continuing from left to right in equal sections with small overlaps. Each original is also photographed in one exposure and is included in reduced form at the back of the book. Photographs included in the original manuscript have been reproduced xerographically in this copy. Higher quality 6" x 9" black and white photographic prints are available for any photographs or illustrations appearing in this copy for an additional charge. Contact UMI directly to order. A Bell & Howell Information Company 300 North Zeeb Road. Ann Arbor. Ml 48106-1346 USA 313/761-4700 800/521-0600 A FORMAL METHODOLOGY FOR DERIVING PURELY FUNCTIONAL PROGRAMS FROM Z SPECIFICATIONS VIA THE INTERMEDIATE SPECIFICATION LANGUAGE FUNZ A Dissertation Submitted to the Graduate Faculty of the Louisiana State University and Agricultural and Mechanical College in partial fulfillment of the requirements for the degree of Doctor of Philosophy in The Department of Computer Science by Linda Bostwick Sherrell B.S., Auburn University, 1972 M.S., Auburn University, 1974 May 1995 DMI Number: 9538761 Copyright 1995 by Sherrell, Linda Bostwick All eights reserved. DMI Microform 9538761 Copyright 1995, by UMI Company. All rights reserved. This microform edition is protected against unauthorized copying under Title 17, United States Code. UMI 300 North Zeeb Road Ann Arbor, MI 48103 © Copyright 1995 Linda Bostwick Sherrell All rights reserved ii Acknowledgements This dissertation would not have been possible without the support of numerous individu­ als. First, I would like to thank Dr. Doris L. Carver, my major professor, for encouraging me to submit my results to international conferences and journals early in the process. The com­ ments from reviewers have helped to improve this work and to inspire me to continue on my path. Furthermore, Dr. Carver has presented an excellent role model. I only hope that I will be able to show the same concern and understanding towards my own students, while balanc­ ing the demands of teaching, research, and family. Second, I would like to thank each of the members of my committee for their contribu­ tions to my success. Dr. Harriet Taylor was my first computer science teacher at Louisiana State University. Needless to say if her programming course had not been enjoyable, I would not be here today. Dr. J. Bush Jones has provided me with an excellent background in compil­ ers and has always been accessible for questions. Dr. Robert F. Lax, my minor professor, has continually shown an interest in my career, beginning with my days as an Instructor in the De­ partment of Mathematics at LSU and later as my modern algebra professor. I would also like to thank Dr. Lai-Him Chan, from Physics & Astronomy, for agreeing to serve as the Dean’s Representative. Two other professors from the Department of Computer Science deserve a special thanks. Dr. Andrzej Hoppe, who was one of my early advisors, first introduced me to the functional programming paradigm by emphasizing the pure aspects of Lisp. Dr. Donald H. Kraft has consistently demonstrated his support throughout the years even though he was not a member of my committee. iii I would like to thank all the members of the Software Engineering Group for their friend­ ship and encouragement. In addition, I would like to thank David Hoelzeman with whom I shared an office for several years. His continued support after accepting an academic job have helped to provide me with a different perspective, and I appreciate his willingness to listen to my problems. I would also like to thank a special friend and colleague, Gerry Vidrine. Gerry and I be­ came good friends when we were both instructors in the Mathematics Department at LSU. Even though our lives have taken unexpected turns over the years, she has always found occa­ sions to check on my progress. I am grateful that she has been so understanding about the limitations on my time. Finally, I would like to thank various members of my family. First, I would like to thank my father, Leonard C. Bostwick, for giving me the confidence in myself to pursue a degree in the sciences when it was unfashionable for women. I would like to thank my mother, Nellie Rose Ann, for allowing me to participate in numerous activities throughout my school years. Second, I would like to thank my two sons, Robert Lawson and David Jeffrey, for under­ standing that I needed to pursue an advanced degree at this time in my life. Even when I missed one of their baseball games or special school functions, they never made me feel guilty. In fact, their support and encouragement sometimes made me wonder who was the parent and who was the child. Last, but most of all, I would like to thank my husband Dan. Without his untiring pa­ tience, love, and reassurance, none of this would have been possible. 1 know that at times it must have seemed like I would never finish my degree, and his life would become an endless discussion about my dissertation. I want to take this opportunity to tell him how much I ap­ preciate all the sacrifices that he has made for me. Table of Contents Acknowledgements .............................................................................................................. iii List of Tables ....................................................................................................................... vii List of Figures ...................................................................................................................... viii Abstract................................................................................................................................ ix Chapter 1. Introduction ............................................................................................................ 1 1.1 Overview....................................................... 1 1.2 Functional Programming ................................................................................ 2 1.2.1 Historical Influences ............................................................................ 3 1.2.2 Language Features ................................................. 4 1.2.3 The Programming Language Haskell .................................................. 9 1.3 Formal Methods .............................................................................................. 13 1.3.1 A Taxonomy for Formal Specification Languages .............................. 14 1.3.2 The Z Specification Language ............................................................. 16 1.4 Outline of the Dissertation .............................................................................. 18 2. Related Research ................................................................ 21 2.1 Prototyping ..... 21 2.2 Formal Program Development ....................................................................... 24 2.2.1 Extended M L ....................................................................................... 25 2.2.2 Larch/ML.............................................................................................. 26 2.2.3 From Z to Lazy M L ............................................................................. 28 2.3 A Frame of Reference for F unZ ....................................... 30 3. FunZ: The Language and Associated Methodology ............................................... 36 3.1 Motivation ....................................................................................................... 36 3.1.1 Why Z and Haskell? ............................................................................ 38 3.1.2 Why an Intermediate Language? ...........................................
Recommended publications
  • GHC Reading Guide
    GHC Reading Guide - Exploring entrances and mental models to the source code - Takenobu T. Rev. 0.01.1 WIP NOTE: - This is not an official document by the ghc development team. - Please refer to the official documents in detail. - Don't forget “semantics”. It's very important. - This is written for ghc 9.0. Contents Introduction 1. Compiler - Compilation pipeline - Each pipeline stages - Intermediate language syntax - Call graph 2. Runtime system 3. Core libraries Appendix References Introduction Introduction Official resources are here GHC source repository : The GHC Commentary (for developers) : https://gitlab.haskell.org/ghc/ghc https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary GHC Documentation (for users) : * master HEAD https://ghc.gitlab.haskell.org/ghc/doc/ * latest major release https://downloads.haskell.org/~ghc/latest/docs/html/ * version specified https://downloads.haskell.org/~ghc/9.0.1/docs/html/ The User's Guide Core Libraries GHC API Introduction The GHC = Compiler + Runtime System (RTS) + Core Libraries Haskell source (.hs) GHC compiler RuntimeSystem Core Libraries object (.o) (libHsRts.o) (GHC.Base, ...) Linker Executable binary including the RTS (* static link case) Introduction Each division is located in the GHC source tree GHC source repository : https://gitlab.haskell.org/ghc/ghc compiler/ ... compiler sources rts/ ... runtime system sources libraries/ ... core library sources ghc/ ... compiler main includes/ ... include files testsuite/ ... test suites nofib/ ... performance tests mk/ ... build system hadrian/ ... hadrian build system docs/ ... documents : : 1. Compiler 1. Compiler Compilation pipeline 1. compiler The GHC compiler Haskell language GHC compiler Assembly language (native or llvm) 1. compiler GHC compiler comprises pipeline stages GHC compiler Haskell language Parser Renamer Type checker Desugarer Core to Core Core to STG STG to Cmm Assembly language Cmm to Asm (native or llvm) 1.
    [Show full text]
  • Probabilistic Models for the Guarded Command Language
    Science of Computer Programming ELSEVIER Science of Computer Programming 28 (1997) 171-192 Probabilistic models for the guarded command language He Jifeng *, K. Seidel, A. McIver Oxford University Computing Laboratory, Programming Research Group, 11 Keble. Road, Oxford OXI 3QD, UK Abstract The two models presented in this paper provide two different semantics for an extension of Dijkstra’s language of guarded commands. The extended language has an additional operator, namely probabilistic choice, which makes it possible to express randomized algorithms. An earlier model by Claire Jones included probabilistic choice but not non-determinism, which meant that it could not be used for the development of algorithms from specifications. Our second model is built on top of Claire Jones’ model, using a general method of extending a probabilistic cpo to one which abo contains non-determinism. The first model was constructed from scratch, as it were, guided only by the desire for certain algebraic properties of the language constructs, which we found lacking in the second model. We compare and contrast the properties of the two models both by giving examples and by constructing mappings between them and the non-probabilistic model. On the basis of this comparison we argue that, in general, the first model is preferable to the second. @ 1997 Elsevier Science B.V. Keywords: Probabilistic programming language; Semantics; Algebraic laws 1. Introduction Dijkstra’s language of guarded commands with its weakest precondition semantics [l] put reasoning about sequential imperative programs on a secure footing. The aim of this paper is to extend this language, its semantics, and formal reasoning to sequential randomized algorithms.
    [Show full text]
  • Department of Computer Science & Engineering
    COURSE STURCTURE Of 4 YEARS DEGREE B.TECH. (Information Technology) Department of Computer Science & Engineering SCHOOL OF INFORMATION AND COMMUNICATION TECHNOLOGY GAUTAM BUDDHA UNIVERSITY GAUTAM BUDH NAGAR, GREATER NOIDA 2018-2019 4-Years Degree B. TECH. (Information Technology) I-YEAR (I-SEMESTER) (Effective from session: 2018-19) SEMESTER-I S r . Subject Code Courses L-T-P Credits CBCS/AICTE No. THEORY 1 PH102 Engineering Physics 3-1-0 4 CC/BS 2 MA101 Engineering Mathematics – I 3-1-0 4 CC/BS 3 ME101 Engineering Mechanics 3-1-0 4 CC/ESC 4 EE102 Basics Electrical Engineering 3-1-0 4 CC/ESC 5 ES101 Environmental Science 2-0-0 2 AECC/BS 6 EN101 English Proficiency 2-0-0 2 AECC/HSMC PRACTICALS 7 PH 104 Engineering Physics Lab 0-0-2 1 CC/BS 8 EE 104 Basic Electrical Engineering Lab 0-0-2 1 CC/ESC 9 ME102* Workshop Practices 1-0-2 2 CC/ESC 10 EN151 Language Lab 0-0-2 1 AECC/HSMC 11 GP General Proficiency - Non Credit Total 17-4-8 25 Total Contact Hours 29 I-YEAR (II-SEMESTER) (Effective from session: 2018-19) SEMESTER – II S r. Subject Code Courses L-T-P Credits CBCS/AICTE No. THEORY 1 CY101 Engineering Chemistry 3-1-0 4 CC/BS 2 MA102 Engineering Mathematics – II 3-1-0 4 CC/BS 3 EC101 Basic Electronics Engineering 3-1-0 4 CC/ESC 4 CS101 Fundamentals of Computer 3-1-0 4 SEC/ESC Programming 5 BS101 Human Values & Buddhist Ethics 2-0-0 2 AECC/HSMC PRACTICALS 6 CY 103 Engineering Chemistry Lab 0-0-2 1 CC/BS 7 EC 181 Basic Electronics Engineering Lab 0-0-2 1 CC/ESC 8 CS 181 Computer Programming Lab 0-0-2 1 SEC/ESC 9 CE103* Engineering Graphics 1-0-2 2 CC/ESC 10 GP General Proficiency - Non Credit Total 15-4-8 23 Total Contact Hours 27 II-YEAR (III-SEMESTER) (Effective from session: 2018-19) EVALUATION SCHEME PERIO SESSIO MID CBC CREDI COUR DS S.
    [Show full text]
  • Formal Specification— Z Notation— Syntax, Type and Semantics
    Formal Specification— Z Notation| Syntax, Type and Semantics Consensus Working Draft 2.6 August 24, 2000 Developed by members of the Z Standards Panel BSI Panel IST/5/-/19/2 (Z Notation) ISO Panel JTC1/SC22/WG19 (Rapporteur Group for Z) Project number JTC1.22.45 Project editor: Ian Toyn [email protected] http://www.cs.york.ac.uk/~ian/zstan/ This is a Working Draft by the Z Standards Panel. It has evolved from Consensus Working Draft 2.5 of June 20, 2000 according to remarks received and discussed at Meeting 56 of the Z Panel. ISO/IEC 13568:2000(E) Contents Page Foreword . iv Introduction . v 1 Scope ....................................................... 1 2 Normative references . 1 3 Terms and definitions . 1 4 Symbols and definitions . 3 5 Conformance . 14 6 Z characters . 18 7 Lexis........................................................ 24 8 Concrete syntax . 30 9 Characterisation rules . 38 10 Annotated syntax . 40 11 Prelude . 43 12 Syntactic transformation rules . 44 13 Type inference rules . 54 14 Semantic transformation rules . 66 15 Semantic relations . 71 Annex A (normative) Mark-ups . 79 Annex B (normative) Mathematical toolkit . 90 Annex C (normative) Organisation by concrete syntax production . 107 Annex D (informative) Tutorial . 153 Annex E (informative) Conventions for state-based descriptions . 166 Bibliography . 168 Index . 169 ii c ISO/IEC 2000|All rights reserved ISO/IEC 13568:2000(E) Figures 1 Phases of the definition . 15 B.1 Parent relation between sections of the mathematical toolkit . 90 D.1 Parse tree of birthday book example . 155 D.2 Annotated parse tree of part of axiomatic example .
    [Show full text]
  • An Efficient Implementation of Guard-Based Synchronization for an Object-Oriented Programming Language an Efficient Implementation of Guard-Based
    AN EFFICIENT IMPLEMENTATION OF GUARD-BASED SYNCHRONIZATION FOR AN OBJECT-ORIENTED PROGRAMMING LANGUAGE AN EFFICIENT IMPLEMENTATION OF GUARD-BASED SYNCHRONIZATION FOR AN OBJECT-ORIENTED PROGRAMMING LANGUAGE By SHUCAI YAO, M.Sc., B.Sc. A Thesis Submitted to the Department of Computing and Software and the School of Graduate Studies of McMaster University in Partial Fulfilment of the Requirements for the Degree of Doctor of Philosophy McMaster University c Copyright by Shucai Yao, July 2020 Doctor of Philosophy (2020) McMaster University (Computing and Software) Hamilton, Ontario, Canada TITLE: An Efficient Implementation of Guard-Based Synchro- nization for an Object-Oriented Programming Language AUTHOR: Shucai Yao M.Sc., (Computer Science) University of Science and Technology Beijing B.Sc., (Computer Science) University of Science and Technology Beijing SUPERVISOR: Dr. Emil Sekerinski, Dr. William M. Farmer NUMBER OF PAGES: xvii,167 ii To my beloved family Abstract Object-oriented programming has had a significant impact on software development because it provides programmers with a clear structure of a large system. It encap- sulates data and operations into objects, groups objects into classes and dynamically binds operations to program code. With the emergence of multi-core processors, application developers have to explore concurrent programming to take full advan- tage of multi-core technology. However, when it comes to concurrent programming, object-oriented programming remains elusive as a useful programming tool. Most object-oriented programming languages do have some extensions for con- currency, but concurrency is implemented independently of objects: for example, concurrency in Java is managed separately with the Thread object. We employ a programming model called Lime that combines action systems tightly with object- oriented programming and implements concurrency by extending classes with actions and guarded methods.
    [Show full text]
  • Computing the Stabilization Times of Self-Stabilizing Systems
    IEICE TRANS. FUNDAMENTALS, VOL.E83–A, NO.11 NOVEMBER 2000 2245 PAPER Special Section on Concurrent Systems Technology Computing the Stabilization Times of Self-Stabilizing Systems Tatsuhiro TSUCHIYA†, Regular Member, Yusuke TOKUDA†, Nonmember, and Tohru KIKUNO†, Regular Member SUMMARY A distributed system is said to be self- state very fast. Research in this direction includes [1], stabilizing if it converges to some legitimate state from an ar- [8], [16]. bitrary state in a finite number of steps. The number of steps In this paper, we propose an automated method required for convergence is usually referred to as the ×ØabiÐiÞaØiÓÒ for computing the worst stabilization time, aiming at ØiÑe, and its reduction is one of the main performance issues in the design of self-stabilizing systems. In this paper, we propose supporting algorithm designers. In [6], Dolev et al. pro- an automated method for computing the stabilization time. The posed a theoretical method, called the scheduler luck method uses Boolean functions to represent the state space in game, for stabilization time analysis. This method can order to assuage the state explosion problem, and computes the stabilization time by manipulating the Boolean functions. To deal with randomized algorithms only, and it is not au- demonstrate the usefulness of the method, we apply it to the tomated. Some work addresses the issues of automatic analysis of existing self-stabilizing algorithms. The results show verification of self-stabilizing systems (e.g., [11], [12], that the method can perform stabilization time analysis very fast, [14]). To the best of our knowledge, however, there has even when an underlying state space is very huge.
    [Show full text]
  • A Classification and Comparison Framework for Software Architecture Description Languages
    A Classification and Comparison Framework for Software Architecture Description Languages Neno Medvidovic Technical Report UCI-ICS-97-02 Department of Information and Computer Science University of California, Irvine Irvine, California 92697-3425 [email protected] February 1996 Abstract Software architectures shift the focus of developers from lines-of-code to coarser- grained architectural elements and their overall interconnection structure. Architecture description languages (ADLs) have been proposed as modeling notations to support architecture-based development. There is, however, little consensus in the research community on what is an ADL, what aspects of an architecture should be modeled in an ADL, and which of several possible ADLs is best suited for a particular problem. Furthermore, the distinction is rarely made between ADLs on one hand and formal specification, module interconnection, simulation, and programming languages on the other. This paper attempts to provide an answer to these questions. It motivates and presents a definition and a classification framework for ADLs. The utility of the definition is demonstrated by using it to differentiate ADLs from other modeling notations. The framework is also used to classify and compare several existing ADLs. One conclusion is that, although much research has been done in this area, no single ADL fulfills all of the identified needs. I. Introduction Software architecture research is directed at reducing costs of developing applications and increasing the potential for commonality between different members of a closely related product family [GS93, PW92]. Software development based on common architectural idioms has its focus shifted from lines-of-code to coarser-grained architectural elements (software components and connectors) and their overall interconnection structure.
    [Show full text]
  • Beyond Structured Programming
    Beyond Structured Programming M.H. van Emden Technical Report DCS-359-IR Department of Computer Science University of Victoria Abstract The correctness of a structured program is, at best, plausible. Though this is a step forward compared to what came before, it falls short of verified correctness. To verify a structured program according to Hoare’s method one is faced with the problem of finding assertions to fit existing code. In 1971 this mode of verification was declared by Dijkstra as too hard to be of practical use—he advised that proof and code were to grow together. A method for doing this was independently published by Reynolds in 1978 and by van Emden in 1979. The latter was further developed to attain the form of matrix code. This form of code not only obviates the need of fitting assertions to existing code, but helps in discovering an algorithm that reaches a given postcondition from a fixed precondition. In this paper a keyboard-editable version of matrix code is presented that uses E.W. Dijkstra’s guarded commands as starting point. The result is reached by using Floyd’s method rather than Hoare’s as starting point. 1 Introduction Structured Programming is the name of a method introduced by E.W. Dijkstra in 1969 [6]. At the time the method was revolutionary: it advocated the elimination of the goto statement and the ex- clusive use of conditional, alternative, and repetitive clauses. In a few years structured programming evolved from controversy to orthodoxy. C.A.R. Hoare invented a logic-based verification method for structured programs [13].
    [Show full text]
  • Modelling and Analysis of Communicating Systems (Chapter 4)
    Chapter 4 Sequential processes In chapter 2 we described behaviour by labelled transition systems. If behaviour be- comes more complex this technique falls short and we need a higher level syntax to concisely describe larger labelled transition systems. In this chapter we describe pro- cesses using an extended process algebra. The building blocks of our process algebra are (multi-)actions with data. We provide operators to combine behaviour in both a sequential and nondeterministic way and allow it to be controlled by data parameters. Axioms are used to characterise the meaning of the various constructs. The language that we get allows to describe all reactive behaviour. In the next chapter we define operators to combine behaviour in a more complex way, especially using the parallel operator. But these operators do not add to the expressivity of the language. The sort of all processes defined in this and the next chapter is P. 4.1 Actions As in chapter 2, actions are the basic ingredients of processes. More precisely, every action is an elementary process. Actions can carry data. E.g., a receive action can carry a message, and an error action can carry a natural number, for instance indicating its severity. Actions can have any number of parameters. They are declared as follows: act timeout ; error : N; receive : B × N+; This declares parameterless action name timeout , action name error with a data pa- rameter of sort N (natural numbers), and action name receive with two parameters of sort B (booleans) and N+ (positive numbers) respectively. For the above action name declaration, timeout , error (0) and receive (false , 6) are valid actions.
    [Show full text]
  • An Architectural Description Language for Secure Multi-Agent Systems
    An Architectural Description Language for Secure Multi-Agent Systems Haralambos Mouratidis1,a, Manuel Kolpb, Paolo Giorginic, Stephane Faulknerd aInnovative Informatics Group, School of Computing, IT and Engineering, University of East London, England b Information Systems Research Unit, Catholic University of Louvain (UCL), Belgium c Department. of Information and Communication Technology, University of Trento, Italy d Information Management Research Unit, University of Namur, Belgium Abstract. Multi-Agent Systems (MAS) architectures are gaining popularity for building open, distributed, and evolving information systems. Unfortunately, despite considerable work in the fields of software architecture and MAS during the last decade, few research efforts have aimed at defining languages for designing and formalising secure agent architectures. This paper proposes a novel Architectural Description Language (ADL) for describing Belief-Desire-Intention (BDI) secure MAS. We specify each element of our ADL using the Z specification language and we employ two example case studies: one to assist us in the description of the proposed language and help readers of the article to better understand the fundamentals of the language; and one to demonstrate its applicability. Keyword: Architectural Description Language, Multi-Agent Systems, Security, BDI Agent Model, Software Architecture 1 Corresponding Author: [email protected] 1 1. Introduction However, as the expectations of business stakeholders are changing day after day; and The characteristics and expectations of as the complexity of systems, information new application areas for the enterprise, and communication technologies and such as e-business, knowledge management, organisations is continually increasing in peer-to-peer computing, and web services, today’s dynamic environments; developers are deeply modifying information systems are expected to produce architectures that engineering.
    [Show full text]
  • Insight, Inspiration and Collaboration
    Chapter 1 Insight, inspiration and collaboration C. B. Jones, A. W. Roscoe Abstract Tony Hoare's many contributions to computing science are marked by insight that was grounded in practical programming. Many of his papers have had a profound impact on the evolution of our field; they have moreover provided a source of inspiration to several generations of researchers. We examine the development of his work through a review of the development of some of his most influential pieces of work such as Hoare logic, CSP and Unifying Theories. 1.1 Introduction To many who know Tony Hoare only through his publications, they must often look like polished gems that come from a mind that rarely makes false steps, nor even perhaps has to work at their creation. As so often, this impres- sion is a further compliment to someone who actually adds to very hard work and many discarded attempts the final polish that makes complex ideas rel- atively easy for the reader to comprehend. As indicated on page xi of [HJ89], his ideas typically go through many revisions. The two authors of the current paper each had the honour of Tony Hoare supervising their doctoral studies in Oxford. They know at first hand his kind and generous style and will count it as an achievement if this paper can convey something of the working style of someone big enough to eschew competition and point scoring. Indeed it will be apparent from the following sections how often, having started some new way of thinking or exciting ideas, he happily leaves their exploration and development to others.
    [Show full text]
  • Should Your Specification Language Be Typed?
    Should Your Specification Language Be Typed? LESLIE LAMPORT Compaq and LAWRENCE C. PAULSON University of Cambridge Most specification languages have a type system. Type systems are hard to get right, and getting them wrong can lead to inconsistencies. Set theory can serve as the basis for a specification lan- guage without types. This possibility, which has been widely overlooked, offers many advantages. Untyped set theory is simple and is more flexible than any simple typed formalism. Polymorphism, overloading, and subtyping can make a type system more powerful, but at the cost of increased complexity, and such refinements can never attain the flexibility of having no types at all. Typed formalisms have advantages too, stemming from the power of mechanical type checking. While types serve little purpose in hand proofs, they do help with mechanized proofs. In the absence of verification, type checking can catch errors in specifications. It may be possible to have the best of both worlds by adding typing annotations to an untyped specification language. We consider only specification languages, not programming languages. Categories and Subject Descriptors: D.2.1 [Software Engineering]: Requirements/Specifica- tions; D.2.4 [Software Engineering]: Software/Program Verification—formal methods; F.3.1 [Logics and Meanings of Programs]: Specifying and Verifying and Reasoning about Pro- grams—specification techniques General Terms: Verification Additional Key Words and Phrases: Set theory, specification, types Editors’ introduction. We have invited the following
    [Show full text]