DOCSLIB.ORG

The Formal Semantics of Programming Languages: an Introduction, Glynn Winskel, 1993 the Formal Semantics of Programming Languages an Introduction

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Foundations of Computing Michael Garey and Albert Meyer, editors Complexity Issues in VLSI: Optimal Layouts for the Shuffle-Exchange Graph and Other Networks, Frank Thomson Leighton, 1983 Equational Logic as a Programming Language, Michael J. 0 'Donnell, 1985 General Theory of Deductive Systems and Its Applications, S. Yu Maslov, 1987 Resource Allocation Problems: Algorithmic Approaches, Toshihide Ibaraki and Naoki Katoh, 1988 Algebraic Theory of Processes, Matthew Hennessy, 1988 PX: A Computational Logic, Susumu Hayashi and Hiroshi Nakano, 1989 The Stable Marriage Problem: Structure and Algorithms, Dan Gusfield and Robert Irving, 1989 Realistic Compiler Generation, Peter Lee, 1989 Single-Layer Wire Routing and Compaction,F. Miller Maley, 1990 Basic Category Theory for Computer Scientists, Benjamin C. Pierce, 1991 Categories, Types, and Structures: An Introduction to Category Theory for the Working Computer Scientist, Andrea Asperti and Giuseppe Longo, 1991 Semantics of Programming Languages: Structures and Techniques, Carl A. Gunter, 1992 The Formal Semantics of Programming Languages: An Introduction, Glynn Winskel, 1993 The Formal Semantics of Programming Languages An Introduction Glynn Winskel The MIT Press Cambridge, Massachusetts London, England Second printing, 1994 ©1993 Massachusetts Institute of Technology All rights reserved. No part ofthis book may be reproduced in any form by any electronic or mechanical means (including photocopying, recording, or information storage and retrieval) without permission in writing from the publisher. This book was printed and bound in the United States of America. Library of Congress Cataloging-in-Publication Data Winskel, G. (Glynn) The formal semantics of programming languages : an introduction Glynn Winskel. p. cm. - (Foundations of computing) Includes bibliographical references and index. ISBN 0-262-23169-7 1. Programming languages (Electronic computers )-Semantics. 1. Title. II. Series. QA76.7.W555 1993 005.13'1--dc20 92-36718 CIP To Kirsten, Sofie and Stine Contents Series foreword xiii Preface xv 1 Basic set theory 1 1.1 Logical notation 1 1.2 Sets 2 1.2.1 Sets and properties 3 1.2.2 Some important sets 3 1.2.3 Constructions on sets 4 1.2.4 The axiom of foundation 6 1.3 Relations and functions 6 1.3.1 Lambda notation 7 1.3.2 Composing relations and functions 7 1.3.3 Direct and inverse image of a relation 9 1.3.4 Equivalence relations 9 1.4 FUrther reading 10 2 Introduction to operational semantics 11 2.1 IMP-a simple imperative language 11 2.2 The evaluation of arithmetic expressions 13 2.3 The evaluation of boolean expressions 17 2.4 The execution of commands 19 2.5 A simple proof 20 2.6 Alternative semantics 24 2.7 FUrther reading 26 3 Some principles of induction 27 3.1 Mathematical induction 27 3.2 Structural induction 28 3.3 Well-founded induction 31 3.4 Induction on derivations 35 3.5 Definitions by induction 39 viii Contents 3.6 Further reading 40 4 Inductive definitions 41 4.1 Rule induction 41 4.2 Special rule induction 44 4.3 Proof rules for operational semantics 45 4.3.1 Rule induction for arithmetic expressions 45 4.3.2 Rule induction for boolean expressions 46 4.3.3 Rule induction for commands 47 4.4 Operators and their least fixed points 52 4.5 Further reading 54 5 The denotational semantics of IMP 55 5.1 Motivation 55 5.2 Denotational semantics 56 5.3 Equivalence of the semantics 61 5.4 Complete partial orders and continuous functions 68 5.5 The Knaster-Tarski Theorem 74 5.6 Further reading 75 6 The axiomatic semantics of IMP 77 6.1 The idea 77 6.2 The assertion language Assn 80 6.2.1 Free and bound variables 81 6.2.2 Substitution 82 6.3 Semantics of assertions 84 6.4 Proof rules for partial correctness 89 6.5 Soundness 91 6.6 Using the Hoare rules-an example 93 6.7 Further reading 96 7 Completeness of the Hoare rules 99 Contents ix 7.1 Codel's Incompleteness Theorem 99 7.2 Weakest preconditions and expressiveness 100 7.3 Proof of Codel's Theorem 110 7.4 Verification conditions 112 7.5 Predicate transformers 115 7.6 Further reading 117 8 Introduction to domain theory 119 8.1 Basic definitions 119 8.2 Streams-an example 121 8.3 Constructions on cpo's 123 8.3.1 Discrete cpo's 124 8.3.2 Finite products 125 8.3.3 Function space 128 8.3.4 Lifting 131 8.3.5 Sums 133 8.4 A metalanguage 135 8.5 Further reading 139 9 Recursion equations 141 9.1 The language REC 141 9.2 Operational semantics of call-by-value 143 9.3 Denotational semantics of call-by-value 144 9.4 Equivalence of semantics for call-by-value 149 9.5 Operational semantics of call-by-name 153 9.6 Denotational semantics of call-by-name 154 9.7 Equivalence of semantics for call-by-name 157 9.8 Local declarations 161 9.9 Further reading 162 10 Techniques for recursion 163 10.1 BekiC's Theorem 163 x Contents 10.2 Fixed-point induction 166 10.3 Well-founded induction 174 10.4 Well-founded recursion 176 10.5 An exercise 179 10.6 Further reading 181 11 Languages with higher types 183 11.1 An eager language 183 11.2 Eager operational semantics 186 11.3 Eager denotational semantics 188 11.4 Agreement of eager semantics 190 11.5 A lazy language 200 11.6 Lazy operational semantics 201 11.7 Lazy denotational semantics 203 11.8 Agreement of lazy semantics 204 11.9 Fixed-point operators 209 11.10 Observations and full abstraction 215 11.11 Sums 219 11.12 Further reading 221 12 Information systems 223 12.1 Recursive types 223 12.2 Information systems 225 12.3 Closed families and Scott predomains 228 12.4 A cpo of information systems 233 12.5 Constructions 236 12.5.1 Lifting 237 12.5.2 Sums 239 12.5.3 Product 241 12.5.4 Lifted function space 243 12.6 Further reading 249 Contents xi 13 Recursive types 251 13.1 An eager language 251 13.2 Eager operational semantics 255 13.3 Eager denotational semantics 257 13.4 Adequacy of eager semantics 262 13.5 The eager A-calculus 267 13.5.1 Equational theory 269 13.5.2 A fixed-point operator 272 13.6 A lazy language 278 13.7 Lazy operational semantics 278 13.8 Lazy denotational semantics 281 13.9 Adequacy of lazy semantics 288 13.10 The lazy A-calculus 290 13.10.1 Equational theory 291 13.10.2 A fixed-point operator 292 13.11 Further reading 295 14 N ondeterminism and parallelism 297 14.1 Introduction 297 14.2 Guarded commands 298 14.3 Communicating processes 303 14.4 Milner's CCS 308 14.5 Pure CCS 311 14.6 A specification language 316 14.7 The modal v-calculus 321 14.8 Local model checking 327 14.9 Further reading 335 A Incompleteness and undecidability 337 Bibliography 353 Index 357 Series foreword Theoretical computer science has now undergone several decades of development. The "classical" topics of automata theory, formal languages, and computational complexity have become firmly established, and their importance to other theoretical work and to practice is widely recognized. Stimulated by technological advances, theoreticians have been rapidly expanding the areas under study, and the time delay between theoreti­ cal progress and its practical impact has been decreasing dramatically. Much publicity has been given recently to breakthroughs in cryptography and linear programming, and steady progress is being made on programming language semantics, computational ge­ ometry, and efficient data structures. Newer, more speculative, areas of study include relational databases, VLSI theory, and parallel and distributed computation. As this list of topics continues expanding, it is becoming more and more difficult to stay abreast of the progress that is being made and increasingly important that the most significant work be distilled and communicated in a manner that will facilitate further research and application of this work. By publishing comprehensive books and specialized monographs on the theoretical aspects of computer science, the series on Foundations of Computing provides a forum in which important research topics can be presented in their entirety and placed in perspective for researchers, students, and practitioners alike. Michael R. Garey Albert R. Meyer Preface In giving a formal semantics to a programming language we are concerned with building a mathematical model. Its purpose is to serve as a basis for understanding and reasoning about how programs behave. Not only is a mathematical model useful for various kinds of analysis and verification, but also, at a more fundamental level, because simply the activity of trying to define the meaning of program constructions precisely can reveal all kinds of subtleties of which it is important to be aware. This book introduces the mathematics, techniques and concepts on which formal semantics rests. For historical reasons the semantics of programming languages is often viewed as con­ sisting of three strands: Operational semantics describes the meaning of a programming language by spec­ ifying how it executes on an abstract machine. We concentrate on the method advocated by Gordon Plotkin in his lectures at Aarhus on "structural operational semantics" in which evaluation and execution relations are specified by rules in a way directed by the syntax. Denotational semantics is a technique for defining the meaning of programming languages pioneered by Christopher Strachey and provided with a mathematical foundation by Dana Scott. At one time called "mathematical semantics," it uses the more abstract mathematical concepts of complete partial orders, continuous functions and least fixed points.
Recommended publications
  • Types and Programming Languages by Benjamin C

    Types and Programming Languages by Benjamin C

    < Free Open Study > . .Types and Programming Languages by Benjamin C. Pierce ISBN:0262162091 The MIT Press © 2002 (623 pages) This thorough type-systems reference examines theory, pragmatics, implementation, and more Table of Contents Types and Programming Languages Preface Chapter 1 - Introduction Chapter 2 - Mathematical Preliminaries Part I - Untyped Systems Chapter 3 - Untyped Arithmetic Expressions Chapter 4 - An ML Implementation of Arithmetic Expressions Chapter 5 - The Untyped Lambda-Calculus Chapter 6 - Nameless Representation of Terms Chapter 7 - An ML Implementation of the Lambda-Calculus Part II - Simple Types Chapter 8 - Typed Arithmetic Expressions Chapter 9 - Simply Typed Lambda-Calculus Chapter 10 - An ML Implementation of Simple Types Chapter 11 - Simple Extensions Chapter 12 - Normalization Chapter 13 - References Chapter 14 - Exceptions Part III - Subtyping Chapter 15 - Subtyping Chapter 16 - Metatheory of Subtyping Chapter 17 - An ML Implementation of Subtyping Chapter 18 - Case Study: Imperative Objects Chapter 19 - Case Study: Featherweight Java Part IV - Recursive Types Chapter 20 - Recursive Types Chapter 21 - Metatheory of Recursive Types Part V - Polymorphism Chapter 22 - Type Reconstruction Chapter 23 - Universal Types Chapter 24 - Existential Types Chapter 25 - An ML Implementation of System F Chapter 26 - Bounded Quantification Chapter 27 - Case Study: Imperative Objects, Redux Chapter 28 - Metatheory of Bounded Quantification Part VI - Higher-Order Systems Chapter 29 - Type Operators and Kinding Chapter 30 - Higher-Order Polymorphism Chapter 31 - Higher-Order Subtyping Chapter 32 - Case Study: Purely Functional Objects Part VII - Appendices Appendix A - Solutions to Selected Exercises Appendix B - Notational Conventions References Index List of Figures < Free Open Study > < Free Open Study > Back Cover A type system is a syntactic method for automatically checking the absence of certain erroneous behaviors by classifying program phrases according to the kinds of values they compute.
  • The Gnu Binary Utilities

    The Gnu Binary Utilities

    The gnu Binary Utilities Version cygnus-2.7.1-96q4 May 1993 Roland H. Pesch Jeffrey M. Osier Cygnus Support Cygnus Support TEXinfo 2.122 (Cygnus+WRS) Copyright c 1991, 92, 93, 94, 95, 1996 Free Software Foundation, Inc. Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modi®ed versions of this manual under the conditions for verbatim copying, provided also that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modi®ed versions. The GNU Binary Utilities Introduction ..................................... 467 1ar.............................................. 469 1.1 Controlling ar on the command line ................... 470 1.2 Controlling ar with a script ............................ 472 2ld.............................................. 477 3nm............................................ 479 4 objcopy ....................................... 483 5 objdump ...................................... 489 6 ranlib ......................................... 493 7 size............................................ 495 8 strings ........................................ 497 9 strip........................................... 499 Utilities 10 c++®lt ........................................ 501 11 nlmconv ....................................
  • 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 .......................
  • Computer Matching Agreement

    Computer Matching Agreement

    COMPUTER MATCHING AGREEMENT BETWEEN NEW tvIEXICO HUMAN SERVICES DEPARTMENT AND UNIVERSAL SERVICE ADMINISTRATIVE COMPANY AND THE FEDERAL COMMUNICATIONS COMMISSION INTRODUCTION This document constitutes an agreement between the Universal Service Administrative Company (USAC), the Federal Communications Commission (FCC or Commission), and the New Mexico Human Services Department (Department) (collectively, Parties). The purpose of this Agreement is to improve the efficiency and effectiveness of the Universal Service Fund (U SF’) Lifeline program, which provides support for discounted broadband and voice services to low-income consumers. Because the Parties intend to share information about individuals who are applying for or currently receive Lifeline benefits in order to verify the individuals’ eligibility for the program, the Parties have determined that they must execute a written agreement that complies with the Computer Matching and Privacy Protection Act of 1988 (CMPPA), Public Law 100-503, 102 Stat. 2507 (1988), which was enacted as an amendment to the Privacy Act of 1974 (Privacy Act), 5 U.S.C. § 552a. By agreeing to the terms and conditions of this Agreement, the Parties intend to comply with the requirements of the CMPPA that are codified in subsection (o) of the Privacy Act. 5 U.S.C. § 552a(o). As discussed in section 11.B. below, U$AC has been designated by the FCC as the permanent federal Administrator of the Universal Service funds programs, including the Lifeline program that is the subject of this Agreement. A. Title of Matching Program The title of this matching program as it will be reported by the FCC and the Office of Management and Budget (0MB) is as follows: “Computer Matching Agreement with the New Mexico Human Services Department.” B.
  • Project1: Build a Small Scanner/Parser

    Project1: Build a Small Scanner/Parser

    Project1: Build A Small Scanner/Parser Introducing Lex, Yacc, and POET cs5363 1 Project1: Building A Scanner/Parser Parse a subset of the C language Support two types of atomic values: int float Support one type of compound values: arrays Support a basic set of language concepts Variable declarations (int, float, and array variables) Expressions (arithmetic and boolean operations) Statements (assignments, conditionals, and loops) You can choose a different but equivalent language Need to make your own test cases Options of implementation (links available at class web site) Manual in C/C++/Java (or whatever other lang.) Lex and Yacc (together with C/C++) POET: a scripting compiler writing language Or any other approach you choose --- must document how to download/use any tools involved cs5363 2 This is just starting… There will be two other sub-projects Type checking Check the types of expressions in the input program Optimization/analysis/translation Do something with the input code, output the result The starting project is important because it determines which language you can use for the other projects Lex+Yacc ===> can work only with C/C++ POET ==> work with POET Manual ==> stick to whatever language you pick This class: introduce Lex/Yacc/POET to you cs5363 3 Using Lex to build scanners lex.yy.c MyLex.l lex/flex lex.yy.c a.out gcc/cc Input stream a.out tokens Write a lex specification Save it in a file (MyLex.l) Compile the lex specification file by invoking lex/flex lex MyLex.l A lex.yy.c file is generated
  • 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.
  • 'Unix' in a File

    'Unix' in a File

    ============================ AWK COMMANDS ================================ 1) find the total occurances of pattern of 'unix' in a file. ==> $awk '/unix/ {count++} END{print count}' nova.txt 2) find the total line of a file. ==> $awk 'END{print NR}' nova.txt 3) print the total number of even line of a file. ==> $awk 'NR % 2' nova.txt 4) print the total number of odd line of a file. ==> $awk 'NR % 2 == 1' nova.txt 5) print the sums of the field of every line of a file. ==> $awk '{ sum = $3+sum } END{print sum}' emp.txt 6) display those words whose length greater than 10 and consist of digits only in file awk ==> $awk '/^[0-9]+$/ length<10 {print}' t3.txt 7) display those words whose length less than 10 and consist of alpha only in file awk ==> $awk '/^[a-zA-Z]+$/ length >3 {print}' t3.txt 8) print odd number of word in each line ==> awk -F\| '{s="";for (i=1;i<=NF;i+=2) { {s=s? $i:$i} print s }}' nova.txt { s = ""; for (i = 1; i <= NF; i+=2) { s = s ? $i : $i } print s } 9) print even number of word in each line ==> awk -F\| '{s="";for (i=0;i<=NF;i+=2) { {s=s? $i:$i} print s }}' nova.txt ==> { s = ""; for (i = 0; i <= NF; i+=2) { s = s ? $i : $i } print s } 10) print the last character of a string using awk ==> awk '{print substr($0,length($0),1)}' nova.txt ============================ MIX COMMANDS ================================ 1) Assign value of 10th positional parameter to 1 variable x. ==> x=${10} 2) Display system process; ==> ps -e ==> ps -A 3) Display number of process; ==> ps aux 4) to run a utility x1 at 11:00 AM ==> at 11:00 am x1 5) Write a command to print only last 3 characters of a line or string.
  • 5 Command Line Functions by Barbara C

    5 Command Line Functions by Barbara C

    ADAPS: Chapter 5. Command Line Functions 5 Command Line Functions by Barbara C. Hoopes and James F. Cornwall This chapter describes ADAPS command line functions. These are functions that are executed from the UNIX command line instead of from ADAPS menus, and that may be run manually or by automated means such as “cron” jobs. Most of these functions are NOT accessible from the ADAPS menus. These command line functions are described in detail below. 5.1 Hydra Although Hydra is available from ADAPS at the PR sub-menu, Edit Time Series Data using Hydra (TS_EDIT), it can also be started from the command line. However, to start Hydra outside of ADAPS, a DV or UV RDB file needs to be available to edit. The command is “hydra rdb_file_name.” For a complete description of using Hydra, refer to Section 4.5.2 Edit Time-Series Data using Hydra (TS_EDIT). 5.2 nwrt2rdb This command is used to output rating information in RDB format. It writes RDB files with a table containing the rating equation parameters or the rating point pairs, with all other information contained in the RDB comments. The following arguments can be used with this command: nwrt2rdb -ooutfile -zdbnum -aagency -nstation -dddid -trating_type -irating_id -e (indicates to output ratings in expanded form; it is ignored for equation ratings.) -l loctzcd (time zone code or local time code "LOC") -m (indicates multiple output files.) -r (rounding suppression) Rules • If -o is omitted, nwrt2rdb writes to stdout; AND arguments -n, -d, -t, and -i must be present. • If -o is present, no other arguments are required, and the program will use ADAPS routines to prompt for them.
  • The AWK Programming Language

    The AWK Programming Language

    The Programming ~" ·. Language PolyAWK- The Toolbox Language· Auru:o V. AHo BRIAN W.I<ERNIGHAN PETER J. WEINBERGER TheAWK4 Programming~ Language TheAWI(. Programming~ Language ALFRED V. AHo BRIAN w. KERNIGHAN PETER J. WEINBERGER AT& T Bell Laboratories Murray Hill, New Jersey A ADDISON-WESLEY•• PUBLISHING COMPANY Reading, Massachusetts • Menlo Park, California • New York Don Mills, Ontario • Wokingham, England • Amsterdam • Bonn Sydney • Singapore • Tokyo • Madrid • Bogota Santiago • San Juan This book is in the Addison-Wesley Series in Computer Science Michael A. Harrison Consulting Editor Library of Congress Cataloging-in-Publication Data Aho, Alfred V. The AWK programming language. Includes index. I. AWK (Computer program language) I. Kernighan, Brian W. II. Weinberger, Peter J. III. Title. QA76.73.A95A35 1988 005.13'3 87-17566 ISBN 0-201-07981-X This book was typeset in Times Roman and Courier by the authors, using an Autologic APS-5 phototypesetter and a DEC VAX 8550 running the 9th Edition of the UNIX~ operating system. -~- ATs.T Copyright c 1988 by Bell Telephone Laboratories, Incorporated. 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, electronic, mechanical, photocopy­ ing, recording, or otherwise, without the prior written permission of the publisher. Printed in the United States of America. Published simultaneously in Canada. UNIX is a registered trademark of AT&T. DEFGHIJ-AL-898 PREFACE Computer users spend a lot of time doing simple, mechanical data manipula­ tion - changing the format of data, checking its validity, finding items with some property, adding up numbers, printing reports, and the like.
  • Making Classes Provable Through Contracts, Models and Frames

    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.
  • UNIX (Solaris/Linux) Quick Reference Card Logging in Directory Commands at the Login: Prompt, Enter Your Username

    UNIX (Solaris/Linux) Quick Reference Card Logging in Directory Commands at the Login: Prompt, Enter Your Username

    UNIX (Solaris/Linux) QUICK REFERENCE CARD Logging In Directory Commands At the Login: prompt, enter your username. At the Password: prompt, enter ls Lists files in current directory your system password. Linux is case-sensitive, so enter upper and lower case ls -l Long listing of files letters as required for your username, password and commands. ls -a List all files, including hidden files ls -lat Long listing of all files sorted by last Exiting or Logging Out modification time. ls wcp List all files matching the wildcard Enter logout and press <Enter> or type <Ctrl>-D. pattern Changing your Password ls dn List files in the directory dn tree List files in tree format Type passwd at the command prompt. Type in your old password, then your new cd dn Change current directory to dn password, then re-enter your new password for verification. If the new password cd pub Changes to subdirectory “pub” is verified, your password will be changed. Many systems age passwords; this cd .. Changes to next higher level directory forces users to change their passwords at predetermined intervals. (previous directory) cd / Changes to the root directory Changing your MS Network Password cd Changes to the users home directory cd /usr/xx Changes to the subdirectory “xx” in the Some servers maintain a second password exclusively for use with Microsoft windows directory “usr” networking, allowing you to mount your home directory as a Network Drive. mkdir dn Makes a new directory named dn Type smbpasswd at the command prompt. Type in your old SMB passwword, rmdir dn Removes the directory dn (the then your new password, then re-enter your new password for verification.