DOCSLIB.ORG

Axiomatic Semantics Review

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Axiomatic Semantics Review • Still need volunteers to teach – BDDs – SAT-solvers Axiomatic Semantics – SAT-based decision procedures – Temporal logic (and maybe other modal logics) – ESC/Java • Please let me know soon Automated Deduction - George Necula - Lecture 2 1 Automated Deduction - George Necula - Lecture 2 2 Review - Operational Semantics More Semantics • We have an imperative language with pointers and • There is also denotational semantics function calls – Each program has a meaning in the form of a mathematical object – Compositional • We have defined the semantics of the language – More complex formalism • e.g. what are appropriate meanings ? • Operational semantics – Relatively simple • Neither is good for arguing program correctness – Not compositional (due to loops and recursive calls) – Operational semantics requires running the code – Adequate guide for an implementation – Denotational semantics requires complex calculations • We do instead: Programs → Theorems → Proofs Automated Deduction - George Necula - Lecture 2 3 Automated Deduction - George Necula - Lecture 2 4 Programs →→→ Theorems. Axiomatic Semantics Partial Correctness Assertions • Consists of: • The assertions we make about programs are of the – A language for making assertions about programs form: – Rules for establishing when assertions hold {A} c {B } with the meaning that: • Typical assertions: – Whenever we start the execution of c in a state that – During the execution, only non-null pointers are dereferenced satisfies A, the program either does not terminate or it – This program terminates with x = 0 terminates in a state that satisfies B • A is called precondition and B is called postcondition • Partial vs. total correctness assertions • For example: – Safety vs. liveness properties { y x } z := x; z := z +1 { y < z } – Usually focus on safety (partial correctness) is a valid assertion • These are called Hoare triple or Hoare assertions Automated Deduction - George Necula - Lecture 2 5 Automated Deduction - George Necula - Lecture 2 6 1 Total Correctness Assertions Languages for Assertions • {A} c {B } is a partial correctness assertion. It does • A specification language not imply termination – Must be easy to use and expressive (conflicting needs) • [A] c [B ] is a total correctness assertion meaning that • Most often only expression – Syntax: how to construct assertions Whenever we start the execution of c in a state that satisfies A the program does terminate in a state that – Semantics: what assertions mean satisfies B • Typical examples • Now let’s be more formal – First-order logic – Formalize the language of assertions, A and B – Temporal logic (used in protocol specification, hardware – Say when an assertion holds in a state specification) – Give rules for deriving Hoare triples – Special-purpose languages: Z, Larch, Java ML Automated Deduction - George Necula - Lecture 2 7 Automated Deduction - George Necula - Lecture 2 8 State-Based Assertions An Assertion Language • Assertions that characterize the state of the • We’ll use a fragment of first-order logic first ⊥⊥⊥ ∧ ∀ execution Formulas P ::= A | T | | P 1 P2 | x.P | P 1 ⇒ P2 | ≤ – Recall: state = state of locals + state of memory Atoms A ::= f(A 1,…,A n) | E 1 E2 | E 1 = E 2 | … • Our assertions will need to be able to refer to • We can also have an arbitrary assortment of function – Variables symbols – Contents of memory – ptr(E,T) - expression E denotes a pointer to T – E : ptr(T) - same in a different notation • What are not state-based assertions – reachable(E 1,E 2) - list cell E 2 is reachable from E 1 – Variable x is live, lock L will be released – these can be built-in or defined – There is no correlation between the values of x and y Automated Deduction - George Necula - Lecture 2 9 Automated Deduction - George Necula - Lecture 2 10 Semantics of Assertions Semantics of Assertions • We introduced a language of assertions, we need to • Formal definition (we drop σ for simplicity): assign meanings to assertions. – We ignore for now references to memory ρ true always ρ ρ ρ e1 = e 2 iff ⊢ e1 ⇓ n1 and ⊢ e2 ⇓ n2 and n 1 = n 2 • Notation ρ, σ A to say that an assertion holds in a ρ e ≥ e iff ρ ⊢ e ⇓ n and ρ ⊢ e ⇓ n and n ≥ n given state. 1 2 1 1 2 2 1 2 ρ ∧ ρ ρ – This is well-defined when ρ is defined on all variables A1 A2 iff A1 and A2 σ ρ ρ ρ occurring in A and is defined on all memory addresses A1 ∨ A2 iff A1 or A2 referenced in A ρ ρ ρ A1 ⇒ A2 iff A1 implies A2 ρ ∀x.A iff ∀n∈Z.ρ[x:=n] A • The judgment is defined inductively on the ρ ∃ ∃ ∈Z ρ structure of assertions. x.A iff n . [x:=n] A Automated Deduction - George Necula - Lecture 2 11 Automated Deduction - George Necula - Lecture 2 12 2 Semantics of Assertions Why Isn’t This Enough? • Now we can define formally the meaning of a partial • Now we have the formal mechanism to decide when correctness assertion {A} c {B } { A} c { B }: – Start the program in all states that satisfies A ∀ρσ .∀ρ’σ’.( ρ,σ A ∧ ρ, σ ⊢ c ⇓ ρ’, σ’) ⇒ ρ’,σ’ B – Run the program – Check that each final state satisfies B • … and the meaning of a total correctness assertion • This is exhaustive testing [A] c [B] iff • Not enough ∀ ρσ.∀ρ’σ’.( ρ,σ A ∧ ρ, σ ⊢ c ⇓ ρ’, σ’) ⇒ ρ’,σ’ B – Can’t try the program in all states satisfying the precondition ∧ – Can’t find all final states for non-deterministic programs ∀ρσ. ρ,σ A ⇒ ∃ρ’σ’. ρ, σ ⊢ c ⇓ ρ’, σ’ – And also it is impossible to effectively verify the truth of a ∀x.A postcondition (by using the definition of validity) Automated Deduction - George Necula - Lecture 2 13 Automated Deduction - George Necula - Lecture 2 14 Derivations as Proxies for Validity Derivation Rules for Assertions • We define a symbolic technique for deriving valid • The derivation rules for ⊢ A are the usual ones from assertions from others that are known to be valid first-order logic with – We start with validity of first-order formulas • Natural deduction style axioms: ⊢ • We write A when we can derive (prove) the ⊢ A ⊢ B ⊢ [a/x]A (a is fresh) ⊢ ∀x.A assertion A ⊢ A ∧ B ⊢ ∀x.A ⊢ [E/x]A – We wish that (∀ρσ . ρ,σ A) iff ⊢ A ⊢ [a/x]A ⊢ ⊢ A • We write {A} c {B} when we can derive (prove) the … … partial correctness assertion ⊢ ∃ ⊢ ⊢ B ⊢ A ⇒ B ⊢ A ⊢ [E/x]A x.A B – We wish that {A} c {B} iff ⊢ {A} c {B} ⊢ A ⇒ B ⊢ B ⊢ ∃x.A ⊢ B Automated Deduction - George Necula - Lecture 2 15 Automated Deduction - George Necula - Lecture 2 16 Derivation Rules for Hoare Triples Derivation Rules for Hoare Logic • Similarly we write ⊢ {A} c { B} when we can derive the • One rule for each syntactic construct: triple using derivation rules ⊢ {A} skip {A} • There is one derivation rule for each command in the language ⊢ {A} c 1 {B} ⊢ {B} c 2 {C} • Plus, the rule of consequence ⊢ {A} c 1; c 2 {C} ⊢ A’ ⇒ A ⊢ {A} c {B} ⊢ B ⇒ B’ ⊢ {A ∧ b} c {B} ⊢ {A ∧ ¬ b} c {B} ⊢ {A’} c {B’} 1 2 ⊢ {A} if b then c 1 else c 2 {B} Automated Deduction - George Necula - Lecture 2 17 Automated Deduction - George Necula - Lecture 2 18 3 Derivation Rules for Hoare Logic (II) Hoare Rules: Assignment • The rule for while is not syntax directed • Example: { A } x := x + 2 {x >= 5 }. What is A? – It needs a loop invariant – A has to imply x ≥ 3 • General rule: ⊢ {A ∧ b} c {A} ⊢ {A} while b do c {A ∧ ¬ b} ⊢ {[e/x]A} x := e {A} • Surprising how simple the rule is ! – Exercise: try to see what is wrong if you make changes to the • But try { A } *x = 5 { *x + *y = 10 } rule (e.g., drop “∧ b” in the premise, …) • A is “*y = 5 or x = y” • How come the rule does not work? Automated Deduction - George Necula - Lecture 2 19 Automated Deduction - George Necula - Lecture 2 20 Example: Assignment The Assignment Axiom (Cont.) • Assume that x does not appear in e • Hoare said: “Assignment is undoubtedly the most Prove that {true} x := e { x = e } characteristic feature of programming a digital • We have computer, and one that most clearly distinguishes it from other branches of mathematics. It is surprising ⊢ {e = e} x := e {x = e} therefore that the axiom governing our reasoning about assignment is quite as simple as any to be found because [e/x](x = e) ≡ e = [e/x]e ≡ e = e in elementary logic .” • Assignment + consequence: • Caveats are sometimes needed for languages with aliasing: ⊢ true ⇒ e = e ⊢ {e = e} x := e {x = e} – If x and y are aliased then ⊢ {true} x := e {x = e} { true } x := 5 { x + y = 10} is true Automated Deduction - George Necula - Lecture 2 21 Automated Deduction - George Necula - Lecture 2 22 Multiple Hoare Rules Example: Conditional • For some constructs multiple rules are possible: D1 :: ⊢ {true ∧ y 0} x := 1 {x > 0} D2 :: ⊢ {true ∧ y > 0} x := y {x > 0} ⊢ ∃ ∧ {A} x := e { x0.[x 0/x]A x = [x 0/x]e} ⊢ {true} if y 0 then x := 1 else x := y {x > 0} (This was the “forward” axiom for assignment •D1 is obtained by consequence and assignment before Hoare) ⊢ {1 > 0} x := 1 {x > 0} ⊢ A ∧ b ⇒ C ⊢ {C} c {A} ⊢ A ∧ ¬ b ⇒ B ⊢ true ∧ y 0 ⇒ 1 > 0 ⊢ ∧ ≥ ⊢ {A} while b do c {B} {true y 0} x := 1 {x 0} ⊢ {C} c {b ⇒ C ∧ ¬ b ⇒ B} •D2 is also obtained by consequence and assignment ⊢ {b ⇒ C ∧ ¬ b ⇒ B} while b do c {B} ⊢ {y > 0} x := y {x > 0} • Exercise: these rules can be derived from the ⊢ true ∧ y > 0 ⇒ y > 0 previous ones using the consequence rules ⊢ {true ∧ y > 0} x := y {x > 0} Automated Deduction - George Necula - Lecture 2 23 Automated Deduction - George Necula - Lecture 2 24 4 Example: Loop Another Example • We want to derive that • Verify that ⊢ {x 0} while x 5 do x := x + 1 { x = 6} ⊢ {A } while true do c { B} • Use the rule for while with invariant x 6 holds for any A, B and c ⊢ x 6 ∧ x 5 ⇒ x + 1 6 ⊢ {x + 1 6} x := x + 1 { x 6 } • We must construct a derivation tree ⊢ {x 6 ∧ x 5 } x := x + 1 {x 6} ⊢ {true ∧ true} c { true } ⊢ ⇒ ⊢ {x 6} while x 5 do x := x + 1 { x 6 ∧ x > 5} A true ⊢ true ∧ false ⇒ B {true} while true do c {true ∧ false} ⊢ • Then finish-off with consequence {A} while true do c { B} ⊢ x 0 ⇒ x 6 • We need an additional lemma: ⊢ x 6 ∧ x > 5 ⇒ x =6 ⊢ {x 6} while … { x 6 ∧ x > 5} ∀ ⊢ ⊢ {x 0} while … {x = 6} c.
Load more

Recommended publications
  • Constructive Design of a Hierarchy of Semantics of a Transition System by Abstract Interpretation
    1 Constructive Design of a Hierarchy of Semantics of a Transition System by Abstract Interpretation Patrick Cousota aD´epartement d’Informatique, Ecole´ Normale Sup´erieure, 45 rue d’Ulm, 75230 Paris cedex 05, France, [email protected], http://www.di.ens.fr/~cousot We construct a hierarchy of semantics by successive abstract interpretations. Starting from the maximal trace semantics of a transition system, we derive the big-step seman- tics, termination and nontermination semantics, Plotkin’s natural, Smyth’s demoniac and Hoare’s angelic relational semantics and equivalent nondeterministic denotational se- mantics (with alternative powerdomains to the Egli-Milner and Smyth constructions), D. Scott’s deterministic denotational semantics, the generalized and Dijkstra’s conser- vative/liberal predicate transformer semantics, the generalized/total and Hoare’s partial correctness axiomatic semantics and the corresponding proof methods. All the semantics are presented in a uniform fixpoint form and the correspondences between these seman- tics are established through composable Galois connections, each semantics being formally calculated by abstract interpretation of a more concrete one using Kleene and/or Tarski fixpoint approximation transfer theorems. Contents 1 Introduction 2 2 Abstraction of Fixpoint Semantics 3 2.1 Fixpoint Semantics ............................... 3 2.2 Fixpoint Semantics Approximation ...................... 4 2.3 Fixpoint Semantics Transfer .......................... 5 2.4 Semantics Abstraction ............................. 7 2.5 Fixpoint Semantics Fusion ........................... 8 2.6 Fixpoint Iterates Reordering .......................... 8 3 Transition/Small-Step Operational Semantics 9 4 Finite and Infinite Sequences 9 4.1 Sequences .................................... 9 4.2 Concatenation of Sequences .......................... 10 4.3 Junction of Sequences ............................. 10 5 Maximal Trace Semantics 10 2 5.1 Fixpoint Finite Trace Semantics .......................
    [Show full text]
  • Towards a Unified Theory of Operational and Axiomatic Semantics — Extended Abstract —
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Illinois Digital Environment for Access to Learning and Scholarship Repository Towards a Unified Theory of Operational and Axiomatic Semantics — Extended Abstract — Grigore Ros¸u and Andrei S¸tefanescu˘ Department of Computer Science, University of Illinois at Urbana-Champaign fgrosu, [email protected] Abstract. This paper presents a nine-rule language-independent proof system that takes an operational semantics as axioms and derives program properties, including ones corresponding to Hoare triples. This eliminates the need for language-specific Hoare-style proof rules in order to verify programs, and, implicitly, the tedious step of proving such proof rules sound for each language separately. The key proof rule is Circularity, which is coinductive in nature and allows for reasoning about constructs with repetitive behaviors (e.g., loops). The generic proof system is shown sound and has been implemented in the MatchC program verifier. 1 Introduction An operational semantics defines a formal executable model of a language typically in terms of a transition relation cfg ) cfg0 between program configurations, and can serve as a formal basis for language understanding, design, and implementation. On the other hand, an axiomatic semantics defines a proof system typically in terms of Hoare triples f g code f 0g, and can serve as a basis for program reasoning and verification. Operational semantics are well-understood and comparatively easier to define than axiomatic semantics for complex languages. More importantly, operational semantics are typically executable, and thus testable. For example, we can test them by executing the program benchmarks that compiler testers use, as has been done with the operational semantics of C [5].
    [Show full text]
  • Axiomatic Semantics
    Advanced Topics in Programming Languages Spring Semester, 2012 Lecture 6: April 24, 2012 Lecturer: Mooly Sagiv Scribe: Michal Balas and Yair Asa Axiomatic Semantics 6.1 The basic idea The problem we would like to solve is how to prove that a program does what we require of it. Given a program, we specify its required behavior based on our intuitive understanding of it. We can run it according to the operational semantics or denotational semantics and compare to its behavior there. For some programs we need to be more abstract (for example programs that receive input), and then it is necessary to use some logic to reason about the program (and how it behaves on a set of inputs and not in one specific execution path). In this case we may eventually develop a formal proof system for properties of the program or showing that it satisfies a requirement. We can then use the proof system to show correctness. These rules of the proof system are called Hoare or Floyd-Hoare rules. Floyd-rules are for flow-charts and Hoare-rules are for structured languages. Originally their approach was advocated not just for proving properties of programs but also giving a method for explaining the meaning of program. The meaning of a program was specified in terms of \axioms" saying how to prove properties of it, in other words it is given by a set of verification rules. Therefore, this approach was named axiomatic semantics. Axiomatic semantics has many applications, such as: Program verifiers • Symbolic execution tools for bug hunting • Software validation tools • Malware detection • Automatic test generation • It is also used for proving the correctness of algorithms or hardware descriptions, \extended static checking (e.g., checking array bounds), and documenting programs and interfaces.
    [Show full text]
  • Making Classes Provable Through Contracts, Models and Frames
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by CiteSeerX DISS. ETH NO. 17610 Making classes provable through contracts, models and frames A dissertation submitted to the SWISS FEDERAL INSTITUTE OF TECHNOLOGY ZURICH (ETH Zurich)¨ for the degree of Doctor of Sciences presented by Bernd Schoeller Diplom-Informatiker, TU Berlin born April 5th, 1974 citizen of Federal Republic of Germany accepted on the recommendation of Prof. Dr. Bertrand Meyer, examiner Prof. Dr. Martin Odersky, co-examiner Prof. Dr. Jonathan S. Ostroff, co-examiner 2007 ABSTRACT Software correctness is a relation between code and a specification of the expected behavior of the software component. Without proper specifica- tions, correct software cannot be defined. The Design by Contract methodology is a way to tightly integrate spec- ifications into software development. It has proved to be a light-weight and at the same time powerful description technique that is accepted by software developers. In its more than 20 years of existence, it has demon- strated many uses: documentation, understanding object-oriented inheri- tance, runtime assertion checking, or fully automated testing. This thesis approaches the formal verification of contracted code. It conducts an analysis of Eiffel and how contracts are expressed in the lan- guage as it is now. It formalizes the programming language providing an operational semantics and a formal list of correctness conditions in terms of this operational semantics. It introduces the concept of axiomatic classes and provides a full library of axiomatic classes, called the mathematical model library to overcome prob- lems of contracts on unbounded data structures.
    [Show full text]
  • The Monastic Rules of Visigothic Iberia: a Study of Their Text and Language
    THE MONASTIC RULES OF VISIGOTHIC IBERIA: A STUDY OF THEIR TEXT AND LANGUAGE By NEIL ALLIES A thesis submitted to The University of Birmingham for the degree of DOCTOR OF PHILOSOPHY Department of Theology and Religion College of Arts and Law The University of Birmingham July 2009 University of Birmingham Research Archive e-theses repository This unpublished thesis/dissertation is copyright of the author and/or third parties. The intellectual property rights of the author or third parties in respect of this work are as defined by The Copyright Designs and Patents Act 1988 or as modified by any successor legislation. Any use made of information contained in this thesis/dissertation must be in accordance with that legislation and must be properly acknowledged. Further distribution or reproduction in any format is prohibited without the permission of the copyright holder. Abstract This thesis is concerned with the monastic rules that were written in seventh century Iberia and the relationship that existed between them and their intended, contemporary, audience. It aims to investigate this relationship from three distinct, yet related, perspectives: physical, literary and philological. After establishing the historical and historiographical background of the texts, the thesis investigates firstly the presence of a monastic rule as a physical text and its role in a monastery and its relationship with issues of early medieval literacy. It then turns to look at the use of literary techniques and structures in the texts and their relationship with literary culture more generally at the time. Finally, the thesis turns to issues of the language that the monastic rules were written in and the relationship between the spoken and written registers not only of their authors, but also of their audiences.
    [Show full text]
  • Chapter 1 Introduction
    Chapter Intro duction A language is a systematic means of communicating ideas or feelings among people by the use of conventionalized signs In contrast a programming lan guage can be thought of as a syntactic formalism which provides ameans for the communication of computations among p eople and abstract machines Elements of a programming language are often called programs They are formed according to formal rules which dene the relations between the var ious comp onents of the language Examples of programming languages are conventional languages likePascal or C and also the more the oretical languages such as the calculus or CCS A programming language can b e interpreted on the basis of our intuitive con cept of computation However an informal and vague interpretation of a pro gramming language may cause inconsistency and ambiguity As a consequence dierent implementations maybegiven for the same language p ossibly leading to dierent sets of computations for the same program Had the language in terpretation b een dened in a formal way the implementation could b e proved or disproved correct There are dierent reasons why a formal interpretation of a programming language is desirable to give programmers unambiguous and p erhaps informative answers ab out the language in order to write correct programs to give implementers a precise denition of the language and to develop an abstract but intuitive mo del of the language in order to reason ab out programs and to aid program development from sp ecications Mathematics often emphasizes
    [Show full text]
  • Aspects of Language
    Aspects of Language CONTENTS CHAPTER 1 : Definitions CHAPTER 2 : Origin CHAPTER 3 : Grammar CHAPTER 4 : Usage and meaning CHAPTER 5 : Philosophy of language CHAPTER 6 : Mind and language CHAPTER 7 : Programming language CHAPTER 8 : Derivation and definitions CHAPTER 9 : Ambiguity CHAPTER 10 : Linguistics CHAPTER 11 : Modern theories CHAPTER 12 : Sign language CHAPTER 1 Language Language is the human capacity for acquiring and using complex systems of communication, and a language is any specific example of such a system. The scientific study of language is called linguistics. Estimates of the number of languages in the world vary between 6,000 and 7,000. However, any precise estimate depends on a partly arbitrary distinction between languages and dialects. Natural languages are spoken or signed, but any language can be encoded into secondary media using auditory, visual, or tactile stimuli, for example, in graphic writing, braille, or whistling. This is because human language is modality-independent. When used as a general concept, "language" may refer to the cognitive ability to learn and use systems of complex communication, or to describe the set of rules that makes up these systems, or the set of utterances that can be produced from those rules. All languages rely on the process of semiosis to relate signs with particular meanings. Oral and sign languages contain a phonological system that governs how symbols are used to form sequences known as words or morphemes, and a syntactic system that governs how words and morphemes are combined to form phrases and utterances. Human language has the properties of productivity, recursivity, and displacement, and it relies entirely on social convention and learning.
    [Show full text]
  • Concepts of Programming Languages, Eleventh Edition, Global Edition
    GLOBAL EDITION Concepts of Programming Languages ELEVENTH EDITION Robert W. Sebesta digital resources for students Your new textbook provides 12-month access to digital resources that may include VideoNotes (step-by-step video tutorials on programming concepts), source code, web chapters, quizzes, and more. Refer to the preface in the textbook for a detailed list of resources. Follow the instructions below to register for the Companion Website for Robert Sebesta’s Concepts of Programming Languages, Eleventh Edition, Global Edition. 1. Go to www.pearsonglobaleditions.com/Sebesta 2. Click Companion Website 3. Click Register and follow the on-screen instructions to create a login name and password Use a coin to scratch off the coating and reveal your access code. Do not use a sharp knife or other sharp object as it may damage the code. Use the login name and password you created during registration to start using the digital resources that accompany your textbook. IMPORTANT: This access code can only be used once. This subscription is valid for 12 months upon activation and is not transferable. If the access code has already been revealed it may no longer be valid. For technical support go to http://247pearsoned.custhelp.com This page intentionally left blank CONCEPTS OF PROGRAMMING LANGUAGES ELEVENTH EDITION GLOBAL EDITION This page intentionally left blank CONCEPTS OF PROGRAMMING LANGUAGES ELEVENTH EDITION GLOBAL EDITION ROBERT W. SEBESTA University of Colorado at Colorado Springs Global Edition contributions by Soumen Mukherjee RCC Institute
    [Show full text]
  • Concurrent Structures in Game Semantics Simon Castellan
    Concurrent structures in game semantics Simon Castellan To cite this version: Simon Castellan. Concurrent structures in game semantics. Logic in Computer Science [cs.LO]. Université de Lyon, 2017. English. NNT : 2017LYSEN034. tel-01587718 HAL Id: tel-01587718 https://tel.archives-ouvertes.fr/tel-01587718 Submitted on 14 Sep 2017 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Numéro National de Thèse: 2017LYSENO34. THÈSE DE DOCTORAT DE L’UNIVERSTÉ DE LYON opérée par l’École Normale Supérieure de Lyon École doctorale: 512 École doctorale en Informatique et Mathématiques de Lyon Spécialité de doctorat : Informatique Discipline : Informatique fondamentale Soutenue publiquement le 13/07/2017, par: Simon Castellan Structures concurrentes en sémantique des jeux Devant le jury composé de: Hyland, Martin Professor at the University of Cambridge Rapporteur Dal Lago, Ugo Professore Associoto all’Università di Bologna Rapporteur Alglave, Jade Senior Lecturer at University College London Examinatrice Curien, Pierre-Louis Directeur de Rercherche à l’Université Paris VII Examinateur Winskel, Glynn Professor at the University of Cambridge Examinateur Yoshida, Nobuko Professor at Imperial College London Examinatrice Laurent, Olivier Directeur de Recherche à l’ENS de Lyon Directeur de thèse Clairambault, Pierre Chargé de Recherche à l’ENS de Lyon Co-Encadrant 1 2 Remerciements et autres acknowledgements Mais, vous savez, moi je ne crois pas qu’il y ait de bonne ou de mauvaise situation.
    [Show full text]
  • Unifying Semantics for Programming and Verification
    Unifying Semantics for Programming and Verification Sergey Goncharov April 28, 2018 Contents 1 Unifying Semantics: Methodology2 1.1 General View of Semantics...........................2 1.1.1 Denotational vs. Operational Semantics...............3 1.1.2 Denotational vs. Axiomatic Semantics................5 1.2 Towards Categorical Semantics........................6 1.2.1 Algebraic vs. Domain Semantics...................6 1.2.2 Domains and Universes........................7 1.2.3 Extensional Monads..........................8 1.2.4 Intensional Coalgebras.........................9 1.2.5 Extensional Collapse.......................... 10 1.2.6 Unifying Semantics........................... 11 2 Unifying Semantics: Worked Scenarios 12 2.1 Coalgebraic Machines and Process Algebra................. 12 2.1.1 Generic Observations and Coalgebraic Chomsky Hierarchy... 12 2.1.2 Coalgebraic Weak Bisimulation.................... 16 2.2 Monad-Based Program Logics......................... 17 2.2.1 Hoare Logic for Order-Enriched Effects............... 17 2.2.2 Calculi for Asynchronous Side-Effecting Processes......... 21 2.3 Guarded and Unguarded Iteration...................... 23 2.3.1 Unguarded Recursion via Complete Elgot Monads........ 23 2.3.2 Unifying Guarded and Unguarded Iteration............ 26 2.3.3 Monads for Iteration vs. Algebras for Iteration........... 30 2.4 Effect Combination............................... 31 3 Auhtor's Publications 33 4 References 34 1 1 Unifying Semantics: Methodology Correct well-designed semantics precedes solutions of principal research problems in computer science. As a somewhat allusive, but spectacular illustration of this motto we may view the seminal work of Turing [110], which arguably gave rise to computer science as a separate discipline not entirely reducible to pure mathematics. In his famous result of undecidability of the halting problem for what then became known as the Turing machine he made two essential steps to achieve the goal: 1.
    [Show full text]
  • Formalization of the Data Flow Diagram Rules for Consistency Check
    International Journal of Software Engineering & Applications (IJSEA), Vol.1, No.4, October 2010 FORMALIZATION OF THE DATA FLOW DIAGRAM RULES FOR CONSISTENCY CHECK Rosziati Ibrahim and Siow Yen Yen Department of Software Engineering, Faculty of Computer Science and Information Technology, Universiti Tun Hussein Onn Malaysia (UTHM), Parit Raja, 86400, Batu Pahat, Johor Malaysia [email protected] [email protected] ABSTRACT In system development life cycle (SDLC), a system model can be developed using Data Flow Diagram (DFD). DFD is graphical diagrams for specifying, constructing and visualizing the model of a system. DFD is used in defining the requirements in a graphical view. In this paper, we focus on DFD and its rules for drawing and defining the diagrams. We then formalize these rules and develop the tool based on the formalized rules. The formalized rules for consistency check between the diagrams are used in developing the tool. This is to ensure the syntax for drawing the diagrams is correct and strictly followed. The tool automates the process of manual consistency check between data flow diagrams. KEYWORDS Consistency Check, Context Diagram, Data Flow Diagram, Formal Method 1. INTRODUCTION System development life cycle (SDLC) is an essential process uses during the development of any system. SDLC consists of four main phases. They are planning, analysis, design and implementation. During analysis phase, context diagram and data flow diagrams are used to produce the process model of a system. A consistency of the context diagram to lower-level data flow diagrams is very important in smoothing up developing the process model of a system.
    [Show full text]
  • Introduction to Axiomatic Semantics
    Announcements Introduction to Axiomatic • Homework 3 due tonight Semantics • Homework 2 is graded Meeting 10, CSCI 5535, Spring 2009 – 13 (mean), 14 (median), out of 21 total, but… – Graduate class: final project is what counts, homeworks are to check understanding – Most difficult: comparing big-step and contextual for IMP with exceptions • Many did not answer the question, rather echoed general comparisons made in class. • “Both your ideas and the clarity with which they are expressed matter.” (like research papers) 2 Questions? Plan for Axiomatic Semantics • History and Motivation (last time) • Assertions (today) • Validity (today) • Derivation Rules (today) • Soundness (next time) • Completeness (next time) 3 4 Axiomatic Semantics One-Slide Summary • An axiomatic semantics consists of: – A language for stating assertions about programs, – Rules for establishing the truth of assertions • Some typical kinds of assertions: – This program terminates A semantics that is appropriate – If this program terminates, the variables x and y have the for arguing program correctness same value throughout the execution of the program – The array accesses are within the array bounds • Some typical languages of assertions – First-order logic – Other logics (temporal, linear, pointer-assertion) – Special-purpose specification languages (SLIC, Z, Larch) 5 6 1 Another Tony Hoare Quote Do you believe this? “It has been found a serious problem to define • Would such language specifications be these languages [ALGOL, FORTRAN, COBOL] useful to you? with sufficient rigor to ensure compatibility among all implementations. ... one way to achieve this would be to insist that all implementations of the language shall satisfy the axioms and rules of inference which underlie proofs of properties of programs expressed in the language.
    [Show full text]