DOCSLIB.ORG

Nominal Game Semantics

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Nominal Game Semantics Full text available at: http://dx.doi.org/10.1561/2500000017 Nominal Game Semantics Andrzej S. Murawski University of Warwick Nikos Tzevelekos Queen Mary University of London Boston — Delft Full text available at: http://dx.doi.org/10.1561/2500000017 Foundations and Trends R in Programming Languages Published, sold and distributed by: now Publishers Inc. PO Box 1024 Hanover, MA 02339 United States Tel. +1-781-985-4510 www.nowpublishers.com [email protected] Outside North America: now Publishers Inc. PO Box 179 2600 AD Delft The Netherlands Tel. +31-6-51115274 The preferred citation for this publication is A. S. Murawski and N. Tzevelekos. Nominal Game Semantics. Foundations and Trends R in Programming Languages, vol. 2, no. 4, pp. 191–269, 2015. R This Foundations and Trends issue was typeset in LATEX using a class file designed by Neal Parikh. Printed on acid-free paper. ISBN: 978-1-68083-107-8 c 2016 A. S. Murawski and N. Tzevelekos All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, mechanical, photocopying, recording or otherwise, without prior written permission of the publishers. Photocopying. In the USA: This journal is registered at the Copyright Clearance Cen- ter, Inc., 222 Rosewood Drive, Danvers, MA 01923. Authorization to photocopy items for internal or personal use, or the internal or personal use of specific clients, is granted by now Publishers Inc for users registered with the Copyright Clearance Center (CCC). The ‘services’ for users can be found on the internet at: www.copyright.com For those organizations that have been granted a photocopy license, a separate system of payment has been arranged. Authorization does not extend to other kinds of copy- ing, such as that for general distribution, for advertising or promotional purposes, for creating new collective works, or for resale. In the rest of the world: Permission to pho- tocopy must be obtained from the copyright owner. Please apply to now Publishers Inc., PO Box 1024, Hanover, MA 02339, USA; Tel. +1 781 871 0245; www.nowpublishers.com; [email protected] now Publishers Inc. has an exclusive license to publish this material worldwide. Permission to use this content must be obtained from the copyright license holder. Please apply to now Publishers, PO Box 179, 2600 AD Delft, The Netherlands, www.nowpublishers.com; e-mail: [email protected] Full text available at: http://dx.doi.org/10.1561/2500000017 Foundations and Trends R in Programming Languages Volume 2, Issue 4, 2015 Editorial Board Editor-in-Chief Mooly Sagiv Tel Aviv University Israel Editors Martín Abadi Robert Harper Ganesan Ramalingam Google & CMU Microsoft Research UC Santa Cruz Tim Harris Mooly Sagiv Anindya Banerjee Oracle Tel Aviv University IMDEA Fritz Henglein Davide Sangiorgi Patrick Cousot University of Copenhagen University of Bologna ENS Paris & NYU Rupak Majumdar David Schmidt Oege De Moor MPI-SWS & UCLA Kansas State University University of Oxford Kenneth McMillan Peter Sewell Matthias Felleisen Microsoft Research University of Cambridge Northeastern University J. Eliot B. Moss Scott Stoller John Field UMass, Amherst Stony Brook University Google Andrew C. Myers Peter Stuckey Cormac Flanagan Cornell University University of Melbourne UC Santa Cruz Hanne Riis Nielson Jan Vitek Philippa Gardner TU Denmark Purdue University Imperial College Peter O’Hearn Philip Wadler Andrew Gordon UCL University of Edinburgh Microsoft Research & Benjamin C. Pierce David Walker University of Edinburgh UPenn Princeton University Dan Grossman Andrew Pitts Stephanie Weirich University of Washington University of Cambridge UPenn Full text available at: http://dx.doi.org/10.1561/2500000017 Editorial Scope Topics Foundations and Trends R in Programming Languages publishes survey and tutorial articles in the following topics: • Abstract interpretation • Programming languages for concurrency • Compilation and interpretation techniques • Programming languages for • Domain specific languages parallelism • Formal semantics, including • Program synthesis lambda calculi, process calculi, and process algebra • Program transformations and optimizations • Language paradigms • Mechanical proof checking • Program verification • Memory management • Runtime techniques for • Partial evaluation programming languages • Program logic • Software model checking • Programming language • Static and dynamic program implementation analysis • Programming language security • Type theory and type systems Information for Librarians Foundations and Trends R in Programming Languages, 2015, Volume 2, 4 issues. ISSN paper version 2325-1107. ISSN online version 2325-1131. Also available as a combined paper and online subscription. Full text available at: http://dx.doi.org/10.1561/2500000017 Foundations and Trends R in Programming Languages Vol. 2, No. 4 (2015) 191–269 c 2016 A. S. Murawski and N. Tzevelekos DOI: 10.1561/2500000017 Nominal Game Semantics Andrzej S. Murawski Nikos Tzevelekos University of Warwick Queen Mary University of London Full text available at: http://dx.doi.org/10.1561/2500000017 Contents 1 Introduction 2 2 Elements of Nominal Set Theory 6 3 GroundML 10 3.1 Syntax............................ 10 3.2 Operationalsemantics. 12 4 ToyML: A First-Order Language with Integer References 18 4.1 Typesandterms....................... 18 4.2 Concretegames ....................... 19 4.3 Interpretation of ToyML terms . 22 5 Game Model 32 5.1 Moves,arenas,plays,strategies . 32 5.2 Fullabstraction ....................... 58 5.3 Chapter Appendix: deferred proofs . 68 6 Conclusions 71 6.1 Other paradigms: higher-order references . 71 6.2 From references to Java objects . 73 6.3 Algorithmicgamesemantics. 74 ii Full text available at: http://dx.doi.org/10.1561/2500000017 iii 6.4 Operationalgamesemantics . 75 References 76 Full text available at: http://dx.doi.org/10.1561/2500000017 Abstract These tutorial notes present nominal game semantics, a denotational technique for modelling higher-order programs. A. S. Murawski and N. Tzevelekos. Nominal Game Semantics. Foundations and Trends R in Programming Languages, vol. 2, no. 4, pp. 191–269, 2015. DOI: 10.1561/2500000017. Full text available at: http://dx.doi.org/10.1561/2500000017 1 Introduction Game semantics is a branch of denotational semantics that uses the metaphor of game playing to model computation. The game models of PCF [5, 21, 35] constructed in the 1990s have led to an unprecedented series of full abstraction results for a range of functional/imperative programming languages. A result of this kind characterises contextual equivalence between terms semantically, i.e. equality of denotations co- incides with the fact that terms can be used interchangeably in any context. As such, full abstraction results can be said to capture the computational essence of programs. The fully abstract game models from the 1990s covered a plethora of computational effects, contributing to a general picture referred to as Abramsky’s cube [8]: by selectively weakening the combinatorial con- ditions on plays of the games, one was able to increase the expressivity of the games and capture desired computational effects. Although those works successfully constructed models of state [7, 6, 4, 9], the techniques used to interpret reference types did not make them fully compatible with what constitutes the norm in languages such as ML or Java. In particular, references were modelled through a form of indirection originating in the work of Reynolds [39], namely 2 Full text available at: http://dx.doi.org/10.1561/2500000017 3 by assuming that ref θ = (θ → unit) × (unit → θ). The approach led to identification of references with pairs of arbitrary reading (unit → θ) and writing (θ → unit) functions. While this view is elegant and cer- tainly comprises the range of behaviours corresponding to references, it does not enforce a relationship between reading and writing, as wit- nessed by the presence of the product type. This causes a significant strengthening of the semantic universe used for modelling references and, consequently, many desirable equivalences are not satisfied in the model. For example, the interpretation of (x := 0; x := 1) is different from that of x := 1 and, similarly, for x := !x and (). We list the inter- pretations below using the terminology of [6]. x := 0; x := 1 run write(0) ok write(1) ok done x := 1 run write(1) ok done x := !x run read i write(i) ok done () run done Thus, for the first term, the semantic translation treats both updates as observable events and therefore both are recorded in the game play.1 This immediately distinguishes semantically the first term from the second one, for which only a single update is recorded. On the other hand, the translation of the third term is more verbose, registering calls to both the read and write methods of x, even though the computa- tional content of the term is in fact that of the skip command () in the modelled language. To prove full abstraction in this setting, it is then necessary to enrich the syntax with terms that will populate the whole semantic space of references. Such terms are often referred to as bad variables, because they are objects of reference type equipped with potentially unrelated reading and writing methods. These terms, if used by the context, can distinguish the pairs of terms discussed above. For instance, a context that instantiates x to a bad variable with divergent reading and writing capabilities will be able
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]
  • Denotational Semantics
    Denotational Semantics CS 6520, Spring 2006 1 Denotations So far in class, we have studied operational semantics in depth. In operational semantics, we define a language by describing the way that it behaves. In a sense, no attempt is made to attach a “meaning” to terms, outside the way that they are evaluated. For example, the symbol ’elephant doesn’t mean anything in particular within the language; it’s up to a programmer to mentally associate meaning to the symbol while defining a program useful for zookeeppers. Similarly, the definition of a sort function has no inherent meaning in the operational view outside of a particular program. Nevertheless, the programmer knows that sort manipulates lists in a useful way: it makes animals in a list easier for a zookeeper to find. In denotational semantics, we define a language by assigning a mathematical meaning to functions; i.e., we say that each expression denotes a particular mathematical object. We might say, for example, that a sort implementation denotes the mathematical sort function, which has certain properties independent of the programming language used to implement it. In other words, operational semantics defines evaluation by sourceExpression1 −→ sourceExpression2 whereas denotational semantics defines evaluation by means means sourceExpression1 → mathematicalEntity1 = mathematicalEntity2 ← sourceExpression2 One advantage of the denotational approach is that we can exploit existing theories by mapping source expressions to mathematical objects in the theory. The denotation of expressions in a language is typically defined using a structurally-recursive definition over expressions. By convention, if e is a source expression, then [[e]] means “the denotation of e”, or “the mathematical object represented by e”.
    [Show full text]
  • Operational Semantics with Hierarchical Abstract Syntax Graphs*
    Operational Semantics with Hierarchical Abstract Syntax Graphs* Dan R. Ghica Huawei Research, Edinburgh University of Birmingham, UK This is a motivating tutorial introduction to a semantic analysis of programming languages using a graphical language as the representation of terms, and graph rewriting as a representation of reduc- tion rules. We show how the graphical language automatically incorporates desirable features, such as a-equivalence and how it can describe pure computation, imperative store, and control features in a uniform framework. The graph semantics combines some of the best features of structural oper- ational semantics and abstract machines, while offering powerful new methods for reasoning about contextual equivalence. All technical details are available in an extended technical report by Muroya and the author [11] and in Muroya’s doctoral dissertation [21]. 1 Hierarchical abstract syntax graphs Before proceeding with the business of analysing and transforming the source code of a program, a com- piler first parses the input text into a sequence of atoms, the lexemes, and then assembles them into a tree, the Abstract Syntax Tree (AST), which corresponds to its grammatical structure. The reason for preferring the AST to raw text or a sequence of lexemes is quite obvious. The structure of the AST incor- porates most of the information needed for the following stage of compilation, in particular identifying operations as nodes in the tree and operands as their branches. This makes the AST algorithmically well suited for its purpose. Conversely, the AST excludes irrelevant lexemes, such as separators (white-space, commas, semicolons) and aggregators (brackets, braces), by making them implicit in the tree-like struc- ture.
    [Show full text]
  • A Game Theoretical Semantics for a Logic of Formal Inconsistency
    A game theoretical semantics for a logic of formal inconsistency CAN BA¸SKENT∗, Department of Computer Science, University of Bath, BA2 7AY, England. Downloaded from https://academic.oup.com/jigpal/article/28/5/936/5213088 by guest on 25 September 2020 PEDRO HENRIQUE CARRASQUEIRA∗∗, Center for Logic, Epistemology and the History of Science (CLE), Institute of Philosophy and the Humanities (IFCH), State University of Campinas (UNICAMP), Campinas 13083-896, Brazil. Abstract This paper introduces a game theoretical semantics for a particular logic of formal inconsistency called mbC. Keywords: Game theoretical semantics, logic of formal inconsistency, mbC, non-deterministic runs, oracles 1 Motivation Paraconsistent logics are the logics of inconsistencies. They are designed to reason about and with inconsistencies and generate formal systems that do not get trivialized under the presence of inconsistencies. Formally, a logic is paraconsistent if the explosion principle does not hold—in paraconsistent systems, there exist some formulas ϕ, ψ such that ϕ, ¬ϕ ψ. Within the broad class of paraconsistent logics, Logics of Formal Inconsistency (LFIs, for short) present an original take on inconsistencies. Similar to the da Costa systems, LFIs form a large class of paraconsistent logics and make use of a special operator to control inconsistencies [8, 9]. Another interesting property of LFIs is that they internalize consistency and inconsistency at the object level. To date, the semantics for LFIs has been suggested using truth tables and algebraic structures. What we aim for in this paper is to present a game theoretical semantics for a particular logic within the class of LFIs. By achieving this, we attempt at both presenting a wider perspective for the semantics of paraconsistency and a broader, more nuanced understanding of semantic games.
    [Show full text]
  • Game Semantics of Homotopy Type Theory
    Game Semantics of Homotopy Type Theory Norihiro Yamada [email protected] University of Minnesota Homotopy Type Theory Electronic Seminar Talks (HoTTEST) Department of Mathematics, Western University February 11, 2021 N. Yamada (Univ. of Minnesota) Game semantics of HoTT Feb. 11, 2021, Western 1 / 19 Just like axiomatic set theory is explained by sets in an informal sense, the conceptual foundation of Martin-L¨oftype theory (MLTT) is computations in an informal sense (a.k.a. the BHK-interpretation). Proofs/objects as computations (e.g., succ : : max N); MLTT as a foundation of constructive maths. On the other hand, homotopy type theory (HoTT) is motivated by the homotopical interpretation of MLTT. HoTT = MLTT + univalence + higher inductive types (HITs); Homotopical interpretation: formulas as spaces, proofs/objects as points, and higher proofs/objects as paths/homotopies. Introduction Background: MLTT vs. HoTT N. Yamada (Univ. of Minnesota) Game semantics of HoTT Feb. 11, 2021, Western 2 / 19 Proofs/objects as computations (e.g., succ : : max N); MLTT as a foundation of constructive maths. On the other hand, homotopy type theory (HoTT) is motivated by the homotopical interpretation of MLTT. HoTT = MLTT + univalence + higher inductive types (HITs); Homotopical interpretation: formulas as spaces, proofs/objects as points, and higher proofs/objects as paths/homotopies. Introduction Background: MLTT vs. HoTT Just like axiomatic set theory is explained by sets in an informal sense, the conceptual foundation of Martin-L¨oftype theory (MLTT) is computations in an informal sense (a.k.a. the BHK-interpretation). N. Yamada (Univ. of Minnesota) Game semantics of HoTT Feb. 11, 2021, Western 2 / 19 MLTT as a foundation of constructive maths.
    [Show full text]
  • A Denotational Semantics Approach to Functional and Logic Programming
    A Denotational Semantics Approach to Functional and Logic Programming TR89-030 August, 1989 Frank S.K. Silbermann The University of North Carolina at Chapel Hill Department of Computer Science CB#3175, Sitterson Hall Chapel Hill, NC 27599-3175 UNC is an Equal OpportunityjAfflrmative Action Institution. A Denotational Semantics Approach to Functional and Logic Programming by FrankS. K. Silbermann A dissertation submitted to the faculty of the University of North Carolina at Chapel Hill in par­ tial fulfillment of the requirements for the degree of Doctor of Philosophy in Computer Science. Chapel Hill 1989 @1989 Frank S. K. Silbermann ALL RIGHTS RESERVED 11 FRANK STEVEN KENT SILBERMANN. A Denotational Semantics Approach to Functional and Logic Programming (Under the direction of Bharat Jayaraman.) ABSTRACT This dissertation addresses the problem of incorporating into lazy higher-order functional programming the relational programming capability of Horn logic. The language design is based on set abstraction, a feature whose denotational semantics has until now not been rigorously defined. A novel approach is taken in constructing an operational semantics directly from the denotational description. The main results of this dissertation are: (i) Relative set abstraction can combine lazy higher-order functional program­ ming with not only first-order Horn logic, but also with a useful subset of higher­ order Horn logic. Sets, as well as functions, can be treated as first-class objects. (ii) Angelic powerdomains provide the semantic foundation for relative set ab­ straction. (iii) The computation rule appropriate for this language is a modified parallel­ outermost, rather than the more familiar left-most rule. (iv) Optimizations incorporating ideas from narrowing and resolution greatly improve the efficiency of the interpreter, while maintaining correctness.
    [Show full text]
  • Denotational Semantics
    Denotational Semantics 8–12 lectures for Part II CST 2010/11 Marcelo Fiore Course web page: http://www.cl.cam.ac.uk/teaching/1011/DenotSem/ 1 Lecture 1 Introduction 2 What is this course about? • General area. Formal methods: Mathematical techniques for the specification, development, and verification of software and hardware systems. • Specific area. Formal semantics: Mathematical theories for ascribing meanings to computer languages. 3 Why do we care? • Rigour. specification of programming languages . justification of program transformations • Insight. generalisations of notions computability . higher-order functions ... data structures 4 • Feedback into language design. continuations . monads • Reasoning principles. Scott induction . Logical relations . Co-induction 5 Styles of formal semantics Operational. Meanings for program phrases defined in terms of the steps of computation they can take during program execution. Axiomatic. Meanings for program phrases defined indirectly via the ax- ioms and rules of some logic of program properties. Denotational. Concerned with giving mathematical models of programming languages. Meanings for program phrases defined abstractly as elements of some suitable mathematical structure. 6 Basic idea of denotational semantics [[−]] Syntax −→ Semantics Recursive program → Partial recursive function Boolean circuit → Boolean function P → [[P ]] Concerns: • Abstract models (i.e. implementation/machine independent). Lectures 2, 3 and 4. • Compositionality. Lectures 5 and 6. • Relationship to computation (e.g. operational semantics). Lectures 7 and 8. 7 Characteristic features of a denotational semantics • Each phrase (= part of a program), P , is given a denotation, [[P ]] — a mathematical object representing the contribution of P to the meaning of any complete program in which it occurs. • The denotation of a phrase is determined just by the denotations of its subphrases (one says that the semantics is compositional).
    [Show full text]
  • Mechanized Semantics of Simple Imperative Programming Constructs*
    App eared as technical rep ort UIB Universitat Ulm Fakultat fur Informatik Dec Mechanized Semantics of Simple Imp erative Programming Constructs H Pfeifer A Dold F W von Henke H Rue Abt Kunstliche Intelligenz Fakultat fur Informatik Universitat Ulm D Ulm verifixkiinformatikuniulmde Abstract In this pap er a uniform formalization in PVS of various kinds of semantics of imp er ative programming language constructs is presented Based on a comprehensivede velopment of xed p oint theory the denotational semantics of elementary constructs of imp erative programming languages are dened as state transformers These state transformers induce corresp onding predicate transformers providing a means to for mally derivebothaweakest lib eral precondition semantics and an axiomatic semantics in the style of Hoare Moreover algebraic laws as used in renement calculus pro ofs are validated at the level of predicate transformers Simple reformulations of the state transformer semantics yield b oth a continuationstyle semantics and rules similar to those used in Structural Op erational Semantics This formalization provides the foundations on which formal sp ecication of program ming languages and mechanical verication of compilation steps are carried out within the Verix pro ject This research has b een funded in part by the Deutsche Forschungsgemeinschaft DFG under pro ject Verix Contents Intro duction Related Work Overview A brief description of PVS Mechanizing Domain
    [Show full text]
  • The Game Semantics of Game Theory
    The game semantics of game theory Jules Hedges We use a reformulation of compositional game theory to reunite game theory with game semantics, by viewing an open game as the System and its choice of contexts as the Environment. Specifically, the system is jointly controlled by n ≥ 0 noncooperative players, each independently optimising a real-valued payoff. The goal of the system is to play a Nash equilibrium, and the goal of the environment is to prevent it. The key to this is the realisation that lenses (from functional programming) form a dialectica category, which have an existing game-semantic interpretation. In the second half of this paper, we apply these ideas to build a com- pact closed category of ‘computable open games’ by replacing the underly- ing dialectica category with a wave-style geometry of interaction category, specifically the Int-construction applied to the traced cartesian category of directed-complete partial orders. 1 Introduction Although the mathematics of games shares a common ancestor in Zermelo’s work on backward induction, it split early on into two subjects that are essentially disjoint: game theory and game semantics. Game theory is the applied study of modelling real-world interacting agents, for example in economics or artificial intelligence. Game semantics, by contrast, uses agents to model – this time in the sense of semantics rather than mathematical modelling – situations in which a system interacts with an environment, but neither would usually be thought of as agents in a philosophical sense. On a technical level, game semantics not only restricts to the two-player zero-sum case, but moreover promotes one of the players to be the Player, and demotes the other to mere Opponent.
    [Show full text]
  • Chapter 3 – Describing Syntax and Semantics CS-4337 Organization of Programming Languages
    !" # Chapter 3 – Describing Syntax and Semantics CS-4337 Organization of Programming Languages Dr. Chris Irwin Davis Email: [email protected] Phone: (972) 883-3574 Office: ECSS 4.705 Chapter 3 Topics • Introduction • The General Problem of Describing Syntax • Formal Methods of Describing Syntax • Attribute Grammars • Describing the Meanings of Programs: Dynamic Semantics 1-2 Introduction •Syntax: the form or structure of the expressions, statements, and program units •Semantics: the meaning of the expressions, statements, and program units •Syntax and semantics provide a language’s definition – Users of a language definition •Other language designers •Implementers •Programmers (the users of the language) 1-3 The General Problem of Describing Syntax: Terminology •A sentence is a string of characters over some alphabet •A language is a set of sentences •A lexeme is the lowest level syntactic unit of a language (e.g., *, sum, begin) •A token is a category of lexemes (e.g., identifier) 1-4 Example: Lexemes and Tokens index = 2 * count + 17 Lexemes Tokens index identifier = equal_sign 2 int_literal * mult_op count identifier + plus_op 17 int_literal ; semicolon Formal Definition of Languages • Recognizers – A recognition device reads input strings over the alphabet of the language and decides whether the input strings belong to the language – Example: syntax analysis part of a compiler - Detailed discussion of syntax analysis appears in Chapter 4 • Generators – A device that generates sentences of a language – One can determine if the syntax of a particular sentence is syntactically correct by comparing it to the structure of the generator 1-5 Formal Methods of Describing Syntax •Formal language-generation mechanisms, usually called grammars, are commonly used to describe the syntax of programming languages.
    [Show full text]
  • 1 a Denotational Semantics for IMP
    CS 4110 – Programming Languages and Logics .. Lecture #8: Denotational Semantics . We have now seen two operational models for programming languages: small-step and large-step. In this lecture, we consider a different semantic model, called denotational semantics. The idea in denotational semantics is to express the meaning of a program as the mathematical function that expresses what the program computes. We can think of an IMP program c as a function from stores to stores: given an an initial store, the program produces a nal store. For example, the program foo := bar+1 0 can be thought of as a function that when given an input store σ, produces a nal store σ that is identical 0 to σ except that it maps foo to the integer σ(bar) + 1; that is, σ = σ[foo 7! σ(bar) + 1]. We will model programs as functions from input stores to output stores. As opposed to operational models, which tell us how programs execute, the denotational model shows us what programs compute. 1 A Denotational Semantics for IMP For each program c, we write C[[c]] for the denotation of c, that is, the mathematical function that c represents: C[[c]] : Store * Store: Note that C[[c]] is actually a partial function (as opposed to a total function), both because the store may not be dened on the free variables of the program and because program may not terminate for certain input stores. The function C[[c]] is not dened for non-terminating programs as they have no corresponding output stores. We will write C[[c]]σ for the result of applying the function C[[c]] to the store σ.
    [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]