DOCSLIB.ORG

Making Classes Provable Through Contracts, Models and Frames

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

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. This thesis argues that modular verification is essential for the reuse of trusted object-oriented code. Modular verification introduces problems with hidden interference of components, known as the frame problem. This thesis introduces the concept of dynamic frame contracts and shows how such contracts can overcome the frame problem, at the same time retaining full information hiding and being faithful to the inheritance relation. The thesis includes an experimental implementation of a fully auto- mated verifier called Ballet. This verifier transforms Eiffel into proof obli- gations that are handed over to a fully automated theorem prover. i ii ZUSAMMENFASSUNG Korrekte Software beschreibt eine Relation zwischen Programmtext und ein- er Spezifikation des zu erwartenden Verhaltens einer Software-Kompo- nente. Ohne eine geeignete Spezifikation ist der Begriff korrekter Software bedeutungslos. Design by Contract ist eine Methode die Spezifikationen in den Softwa- reentwicklungsprozess einbindet. Sie hat sich bewahrt¨ als eine einfache und gleichermaßen machtige¨ Technologie und wird von Entwicklern an- genommen. In den 20 Jahren seit ihrer Entstehung haben sich viele An- wendungsfelder fur¨ Design by Contract ergeben: Dokumentation, Ver- standnis¨ der objektorientierten Vererbung, Uberpr¨ ufung¨ zur Laufzeit, oder vollautomatisches Testen. Diese Dissertation beschaftigt¨ sich mit der formalen Verifikation von contracted Code. Sie analysiert die Programmiersprache Eiffel und wie in dieser Programmiersprache Vertrage¨ (Contracts) benutzt werden konnen.¨ Eine operationelle Semantik formalisiert die Programmiersprache. Die Be- weisverpflichtungen zur Uberpr¨ ufung¨ der Korrektheit werde definiert. Sie entwickelt den Begriff der axiomatischen Klasse und entwickelt eine Bibliothek solcher Klassen, die Mathematical Model Library, um Probleme mit Vertragen¨ uber¨ unbeschrankten¨ Datenstrukturen zu beheben. Diese Dissertation argumentiert, dass modulares Beweisen essentiell fur¨ die Wiederverwendungen von vertrauenswurdigen,¨ objektorientierten Komponenten ist. Eine modulare Beweisfuhrung¨ scheitert an versteckten Interferenzen verschiedener Komponenten. Dieses Problem ist unter dem Namen Frame Problem bekannt. Diese Dissertation erweitert Design by Contracts um Dynamic Frame Contracts, um diese Probleme zu beheben. Dynamic Frame Contracts bewahren die Kapselung von Komponenten und sind vertraglich¨ mit der Vererbungsbeziehung der objektorientierten Entwicklung. iii Die Dissertation enthalt¨ die experimentelle Implementierung eines voll- automatischen Beweiswerkzeugs mit dem Namen Ballet. Dieses Werkzeug wandelt Eiffel Programmtext in Beweisverpflichtungen fur¨ einen automa- tischen Beweiser um. iv ACKNOWLEDGEMENTS First and foremost, I would like to thank my supervisor Prof. Bertrand Meyer. Working as part of his research group and his constant personal input and feedback formed the basis for my understanding of software engineering, language semantics and verification of object-oriented pro- grams. I would like to thank Prof. Jonathan Ostroff. The possibility to stay with his research group in Toronto had a great influence on my understanding of models and frames. I also want to include the other members of his research group, Faraz Torshizi, Hai Feng Huang, David Makalsky and Chen- Wei Wang. My gratitudes goes many people at the “Chair of Software Engineer- ing” at ETH Zurich.¨ This includes Prof. Peter M¨uller, who was always available for questions on Spec# and JML, and the other members: Manuel Oriol, Till Bay, Ilinca Ciupa, Adam Darvas, Werner Dietl, Hermann Lehner, An- dreas Leitner, Yann M¨uller, Martin Nordio, Michela Pedroni, Marco Piccioni, Joseph Ruskiewicz and Jason Wei, and the former members Vijay d’Silva, Ar- naud Bailly, Karine Arnout, Susanne Cech Previtali and Piotr Nienaltowski. Each one of them, through smaller or more extensive discussions, con- tributed to the overall result of this thesis. If would like to thank Prof. Martin Odersky, for volunteering on short notice to become second co-examiner, for giving me the opportunity to present my work at his research group at EPFL and for the feedback given. Finally, I would like to thank all members of my family (the number in- creased significantly during my studies) and my girlfriend, Jana Steinbr¨uck, for providing all the needed personal support required to endure the ups and downs of my scientific work. v vi CONTENTS 1 Introduction 1 1.1 Towards trusted components . 1 1.2 The grand challenge of the verifying compiler . 2 1.3 Summary and outlook . 3 2 Essential Results 5 2.1 Overview . 5 2.2 Language semantics . 7 2.3 Models and model contracts . 9 2.4 A library of models . 13 2.5 Composability and the frame problem . 18 2.6 The frame problem in Eiffel . 19 2.7 Dynamic frame contracts . 21 2.8 Ballet verifier . 23 3 Specifications in Eiffel 27 3.1 Type safety . 28 3.2 Contracts . 29 3.3 Side-effects of contracts . 31 3.4 Partial functions in contracts . 32 3.5 Pure object-orientation . 32 3.6 Axiomatic classes . 33 3.7 Language semantics . 34 3.8 Contract-based reasoning . 35 3.9 Recursive contracts . 37 3.10 Agent-based contracts . 39 3.11 Specification features . 39 4 Modular reasoning and verification 41 4.1 Modular boundary . 41 vii 4.2 Modularity in inheritance . 42 4.3 Modularity of suppliers . 43 4.4 The imperative of modular verification . 43 4.4.1 Non-modular verification is not easier . 44 4.4.2 Cluster development model . 44 4.4.3 Software reuse . 44 4.4.4 Modular continuity . 45 4.4.5 Complete functional specifications . 45 4.4.6 Subtyping and polymorphism . 45 4.5 Summary . 46 5 Language Semantics 47 5.1 Related Work . 48 5.2 Mathematical notation . 49 5.3 Static model . 50 5.3.1 Classes and Types . 50 5.3.2 Features . 51 5.3.3 Program text . 52 5.3.4 Language simpliciations . 54 5.3.5 Contracts . 56 5.3.6 Implementation . 57 5.4 State model . 57 5.4.1 Heap . 58 5.4.2 Environment . 59 5.4.3 Global State . 60 5.4.4 Monomorphic state relation . 61 5.5 Execution model . 62 5.5.1 Evaluating expressions . 63 5.5.2 Side effects in expressions . 64 5.5.3 Executing instructions . 66 5.6 Monotonic properties of the state . 67 5.6.1 Object allocation . 67 5.6.2 Once setting . 68 5.7 Weak purity . 68 5.8 Correctness . 70 6 Model-based contracts 73 6.1 Related work . 74 6.2 Mathematical language . 75 6.3 Finite and typed models . 75 6.4 MML: a mathematical model library . 76 viii 6.5 Library design . 77 6.6 Comparison of model libraries . 79 6.7 Applying models . 80 6.8 Models and inheritance . 82 6.9 Composite models . 83 6.10 Classic and model contracts . 85 6.11 Default implementation . 87 6.12 Implementing the abstraction function . 88 6.13 Applying models to EiffelBase . 89 6.13.1 Analyzing existing EiffeBase . 90 6.13.2 Designing a new EiffeBase . 93 6.14 Summary . 98 7 Dynamic Frame Contracts 103 7.1 Closed world reasoning . 104 7.2 Frame problem in software development . 105 7.3 Related work . 107 7.4 Frames in the object-oriented programs . 108 7.4.1 Read vs write effects . 109 7.5 Dynamic Frames . 110 7.5.1 Object-orientation . 111 7.5.2 Frame variables . 112 7.5.3 Modular reasoning . 114 7.5.4 Object creation . 115 7.5.5 Summary . 115 7.6 Frames as contracts . 116 7.7 Extending dynamic frames . 119 7.8 Granularity of Frames . 120 7.9 Confining change . 120 7.10 Formalization . 121 7.10.1 Use sets . 121 7.10.2 Modify sets . 124 7.10.3 Correctness . 125 7.11 Reasoning with frames . 126 7.11.1 Soundness . 126 7.12 Frames and Inheritance . 142 7.13 Applying frames . 142 7.13.1 Contracts for frames . 143 7.14 Patterns of frames . 144 7.14.1 Encapsulation . 144 7.14.2 Friend . 145 ix 7.14.3 View . 146 7.14.4 Proxy . 146 7.14.5 Wrapper . 147 7.15.
Recommended publications
  • JHDF5 (HDF5 for Java) 19.04

    JHDF5 (HDF5 for Java) 19.04

    JHDF5 (HDF5 for Java) 19.04 Introduction HDF5 is an efficient, well-documented, non-proprietary binary data format and library developed and maintained by the HDF Group. The library provided by the HDF Group is written in C and available under a liberal BSD-style Open Source software license. It has over 600 API calls and is very powerful and configurable, but it is not trivial to use. SIS (formerly CISD) has developed an easy-to-use high-level API for HDF5 written in Java and available under the Apache License 2.0 called JHDF5. The API works on top of the low-level API provided by the HDF Group and the files created with the SIS API are fully compatible with HDF5 1.6/1.8/1.10 (as you choose). Table of Content Introduction ................................................................................................................................ 1 Table of Content ...................................................................................................................... 1 Simple Use Case .......................................................................................................................... 2 Overview of the library ............................................................................................................... 2 Numeric Data Types .................................................................................................................... 3 Compound Data Types ................................................................................................................ 4 System
  • Operational Semantics Page 1

    Operational Semantics Page 1

    Operational Semantics Page 1 Operational Semantics Class notes for a lecture given by Mooly Sagiv Tel Aviv University 24/5/2007 By Roy Ganor and Uri Juhasz Reference Semantics with Applications, H. Nielson and F. Nielson, Chapter 2. http://www.daimi.au.dk/~bra8130/Wiley_book/wiley.html Introduction Semantics is the study of meaning of languages. Formal semantics for programming languages is the study of formalization of the practice of computer programming. A computer language consists of a (formal) syntax – describing the actual structure of programs and the semantics – which describes the meaning of programs. Many tools exist for programming languages (compilers, interpreters, verification tools, … ), the basis on which these tools can cooperate is the formal semantics of the language. Formal Semantics When designing a programming language, formal semantics gives an (hopefully) unambiguous definition of what a program written in the language should do. This definition has several uses: • People learning the language can understand the subtleties of its use • The model over which the semantics is defined (the semantic domain) can indicate what the requirements are for implementing the language (as a compiler/interpreter/…) • Global properties of any program written in the language, and any state occurring in such a program, can be understood from the formal semantics • Implementers of tools for the language (parsers, compilers, interpreters, debuggers etc) have a formal reference for their tool and a formal definition of its correctness/completeness
  • Constructive Design of a Hierarchy of Semantics of a Transition System by Abstract Interpretation

    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 .......................
  • Denotational Semantics

    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”.
  • Quantum Weakest Preconditions

    Quantum Weakest Preconditions

    Quantum Weakest Preconditions Ellie D’Hondt ∗ Prakash Panangaden †‡ Abstract We develop a notion of predicate transformer and, in particular, the weak- est precondition, appropriate for quantum computation. We show that there is a Stone-type duality between the usual state-transformer semantics and the weakest precondition semantics. Rather than trying to reduce quantum com- putation to probabilistic programming we develop a notion that is directly taken from concepts used in quantum computation. The proof that weak- est preconditions exist for completely positive maps follows from the Kraus representation theorem. As an example we give the semantics of Selinger’s language in terms of our weakest preconditions. 1 Introduction Quantum computation is a field of research that is rapidly acquiring a place as a significant topic in computer science. To be sure, there are still essential tech- nological and conceptual problems to overcome in building functional quantum computers. Nevertheless there are fundamental new insights into quantum com- putability [Deu85, DJ92], quantum algorithms [Gro96, Gro97, Sho94, Sho97] and into the nature of quantum mechanics itself [Per95], particularly with the emer- gence of quantum information theory [NC00]. These developments inspire one to consider the problems of programming full-fledged general purpose quantum computers. Much of the theoretical re- search is aimed at using the new tools available - superposition, entanglement and linearity - for algorithmic efficiency. However, the fact that quantum algorithms are currently done at a very low level only - comparable to classical computing 60 years ago - is a much less explored aspect of the field. The present paper is ∗Centrum Leo Apostel , Vrije Universiteit Brussel, Brussels, Belgium, [email protected].
  • Towards a Unified Theory of Operational and Axiomatic Semantics — Extended Abstract —

    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].
  • Axiomatic Semantics

    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.
  • Sun 64-Bit Binary Alignment Proposal

    Sun 64-Bit Binary Alignment Proposal

    1 KMIP 64-bit Binary Alignment Proposal 2 3 To: OASIS KMIP Technical Committee 4 From: Matt Ball, Sun Microsystems, Inc. 5 Date: May 1, 2009 6 Version: 1 7 Purpose: To propose a change to the binary encoding such that each part is aligned to an 8-byte 8 boundary 9 10 Revision History 11 Version 1, 2009-05-01: Initial version 12 Introduction 13 The binary encoding as defined in the 1.0 version of the KMIP draft does not maintain alignment to 8-byte 14 boundaries within the message structure. This causes problems on hard-aligned processors, such as the 15 ARM, that are not able to easily access memory on addresses that are not aligned to 4 bytes. 16 Additionally, it reduces performance on modern 64-bit processors. For hard-aligned processors, when 17 unaligned memory contents are requested, either the compiler has to add extra instructions to perform 18 two aligned memory accesses and reassemble the data, or the processor has to take a „trap‟ (i.e., an 19 interrupt generated on unaligned memory accesses) to correctly assemble the memory contents. Either 20 of these options results in reduced performance. On soft-aligned processors, the hardware has to make 21 two memory accesses instead of one when the contents are not properly aligned. 22 This proposal suggests ways to improve the performance on hard-aligned processors by aligning all data 23 structures to 8-byte boundaries. 24 Summary of Proposed Changes 25 This proposal includes the following changes to the KMIP 0.98 draft submission to the OASIS KMIP TC: 26 Change the alignment of the KMIP binary encoding such that each part is aligned to an 8-byte 27 boundary.
  • Operational Semantics with Hierarchical Abstract Syntax Graphs*

    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.
  • A Denotational Semantics Approach to Functional and Logic Programming

    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.
  • Denotational Semantics

    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).
  • 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

    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.