Bidirectional Programming Languages

Total Page:16

File Type:pdf, Size:1020Kb

Bidirectional Programming Languages University of Pennsylvania ScholarlyCommons Publicly Accessible Penn Dissertations Winter 2009 Bidirectional Programming Languages John Nathan Foster University of Pennsylvania, [email protected] Follow this and additional works at: https://repository.upenn.edu/edissertations Part of the Databases and Information Systems Commons, and the Programming Languages and Compilers Commons Recommended Citation Foster, John Nathan, "Bidirectional Programming Languages" (2009). Publicly Accessible Penn Dissertations. 56. https://repository.upenn.edu/edissertations/56 This paper is posted at ScholarlyCommons. https://repository.upenn.edu/edissertations/56 For more information, please contact [email protected]. Bidirectional Programming Languages Abstract The need to edit source data through a view arises in a host of applications across many different areas of computing. Unfortunately, few existing systems provide support for updatable views. In practice, when they are needed, updatable views are usually implemented using two separate programs: one that computes the view from the source and another that handles updates. This rudimentary design is tedious for programmers, difficult to reason about, and a nightmare to maintain. This dissertation presents bidirectional programming languages, which provide an elegant and effective mechanism for describing updatable views. Unlike programs written in an ordinary language, which only work in one direction, programs in a bidirectional language can be run both forwards and backwards: from left to right, they describe functions that map sources to views, and from right to left, they describe functions that map updated views back to updated sources. Besides eliminating redundancy, these languages can be designed to ensure correctness, guaranteeing by construction that the two functions work well together. Starting from the foundations, we define a general semantic space of well-behaved bidirectional transformations called lenses. Then, building on this foundation, we describe a particular language for defining lenses on strings with syntax based on the familiar egularr operators (union, concatenation, and Kleene star). We present extensions to the basic framework that address the subtle complications that arise when lenses are used to manipulate, data containing unimportant details, ordered data, and confidential data. Degree Type Dissertation Degree Name Doctor of Philosophy (PhD) Graduate Group Computer and Information Science First Advisor Benjamin C. Pierce Keywords bidirectional languages, lenses, view update, regular expression types Subject Categories Databases and Information Systems | Programming Languages and Compilers This dissertation is available at ScholarlyCommons: https://repository.upenn.edu/edissertations/56 BIDIRECTIONAL PROGRAMMING LANGUAGES John Nathan Foster A DISSERTATION in Computer and Information Science Presented to the Faculties of the University of Pennsylvania in Partial Fulllment of the Requirements for the Degree of Doctor of Philosophy 2009 Benjamin C. Pierce, Professor of Computer and Information Science Supervisor of Dissertation Jianbo Shi, Associate Professor of Computer and Information Science Graduate Group Chairperson Dissertation Committee Zachary G. Ives, Associate Professsor of Computer and Information Science Val Tannen, Professor of Computer and Information Science Philip Wadler, Professor of Theoretical Computer Science, University of Edinburgh Steve Zdancewic, Associate Professor of Computer and Information Science COPYRIGHT John Nathan Foster 2009 ABSTRACT Bidirectional Programming Languages John Nathan Foster Supervisor: Benjamin C. Pierce The need to edit source data through a view arises in a host of applications across many different areas of computing. Unfortunately, few existing systems provide support for updatable views. In practice, when they are needed, updatable views are usually implemented using two separate programs: one that computes the view from the source and another that handles updates. This rudimentary design is tedious for programmers, difcult to reason about, and a nightmare to maintain. This dissertation presents bidirectional programming languages, which provide an elegant and effective mechanism for describing updatable views. Unlike programs written in an ordi- nary language, which only work in one direction, programs in a bidirectional language can be run both forwards and backwards: from left to right, they describe functions that map sources to views, and from right to left, they describe functions that map updated views back to updated sources. Besides eliminating redundancy, these languages can be designed to ensure correctness, guaranteeing by construction that the two functions work well together. Starting from the foundations, we dene a general semantic space of well-behaved bidirec- tional transformations called lenses. Then, building on this foundation, we describe a particu- lar language for dening lenses on strings with syntax based on the familiar regular operators (union, concatenation, and Kleene star). We present extensions to the basic framework that address the subtle complications that arise when lenses are used to manipulate, data containing unimportant details, ordered data, and condential data. iii Acknowledgments Some dissertation projects go like this: the student arrives on campus, the adviser sets a topic, the student disappears into the lab, and emerges several years later with the nished product. Mine, thankfully, has been nothing like this. The work described in this dissertation is the result of an extended, close collaboration with Benjamin Pierce and Alan Schmitt, with additional contributions from Davi Barbosa, Aaron Bohannon, Julien Cretin, Malo Deni´elou, Michael Greenberg, Adam Magee, St´ephane Lescuyer, Danny Puller, Alexandre Pilkiewicz, and Steve Zdancewic. I am lucky to be able to count these talented individuals as my colleagues and friends, and I gratefully acknowledge their contributions to this project. Throughout my time at Penn, my adviser Benjamin Pierce, has always been available to brainstorm about research, crank through a proof, hack on some code, or polish a piece of writing. Thank you Benjamin for setting the standard high, and for encouraging me, nurturing me, and providing help along the way. Zack Ives, Val Tannen, Phil Wadler, and Steve Zdancewic all graciously agreed to serve on my dissertation committee. I wish to thank them for the many hours they spent reading my proposal and this dissertation. Their many insightful comments and valuable suggestions have improved it immensely. Kim Bruce gave me my rst research experience as an undergraduate and told me I would go to graduate school before I even knew I would want to. I am grateful for the opening into the research world he gave me and for close to ten years of guidance. Alan Schmitt helped me navigate the transition to graduate school during the last few months of his postdoc and has continued to be a collaborator, informal mentor, and close friend in the years since. He also hosted me at Rhone-Alpes^ for a productive and extremely enjoyable visit in the spring of 2006. I also wish to thank my mentors Ravi Konuru, J’erome^ iv Sim´eon, and Lionel Villard for an enjoyable internship at IBM Research during the summer of 2007. To the members of Penn’s PLClub and Database Groups, thank you for creating a stimulat- ing and friendly research environment. To my close friends in the department, Colin Blundell, TJ Green, Greg Karvounarakis, Micah Sherr, Nick Taylor, and Svilen Mihaylov, thank you for all the lunch runs, coffee breaks, and pleasant distractions from work. Thanks to my running partners Adam Aviv, John Blitzer, Pavol Cernˇ ´y, and Jeff Vaughan for many miles of good con- versation. To Dimitrios Vytiniotis, it’s been... OK :-) To Mike Felker and Gail Shannon, thank you for solving so many bureaucratic puzzles. The department wouldn’t function without you. To my family, especially Clare, Mollie, Tita Mary, Ahmad, my parents, stepparents, and grandparents thank you for keeping me grounded these past six years and for always believing in me. To Sara, thank you for reminding me how much fun life can be. I’ll meet you for coffee anytime. Philadelphia, PA December 7, 2009 This work was supported in part by an NSF Graduate Research Fellowship and NSF grants CPA-0429836 Harmony: The Art of Reconciliation, IIS-0534592 Linguistic Foundations for XML View Update, and CT-T-0716469 Manifest Security. v Contents 1 Introduction 1 1.1 The View Update Problem ............................. 2 1.2 Bidirectional Programming Languages ....................... 3 1.3 Goal and Contributions .............................. 7 1.4 Acknowledgments .................................. 10 2 Notational Preliminaries 11 2.1 Basic Concepts ................................... 11 2.2 Formal Language Theory .............................. 13 2.3 Regular Languages ................................. 15 3 Basic Lenses 18 3.1 Semantics ...................................... 18 3.2 Basic Lens Properties ................................ 24 3.3 Combinators .................................... 29 3.4 Summary ...................................... 44 4 Quotient Lenses 45 4.1 Semantics ...................................... 48 4.2 Quotient Lens Combinators ............................ 50 4.3 Regular Operators ................................. 59 4.4 Primitives ...................................... 66 4.5 Typechecking ...................................
Recommended publications
  • 15-122: Principles of Imperative Computation, Fall 2014 Lab 11: Strings in C
    15-122: Principles of Imperative Computation, Fall 2014 Lab 11: Strings in C Tom Cortina(tcortina@cs) and Rob Simmons(rjsimmon@cs) Monday, November 10, 2014 For this lab, you will show your TA your answers once you complete your activities. Autolab is not used for this lab. SETUP: Make a directory lab11 in your private 15122 directory and copy the required lab files to your lab11 directory: cd private/15122 mkdir lab11 cp /afs/andrew.cmu.edu/usr9/tcortina/public/15122-f14/*.c lab11 1 Storing and using strings using C Load the file lab11ex1.c into a text editor. Read through the file and write down what you think the output will be before you run the program. (The ASCII value of 'a' is 97.) Then compile and run the program. Be sure to use all of the required flags for the C compiler. Answer the following questions on paper: Exercise 1. When word is initially printed out character by character, why does only one character get printed? Exercise 2. Change the program so word[3] = 'd'. Recompile and rerun. Explain the change in the output. Run valgrind on your program. How do the messages from valgrind correspond to the change we made? Exercise 3. Change word[3] back. Uncomment the code that treats the four character array word as a 32-bit integer. Compile and run again. Based on the answer, how are bytes of an integer stored on the computer where you are running your code? 2 Arrays of strings Load the file lab11ex2.c into a text editor.
    [Show full text]
  • Configuration File Manipulation with Configuration Management Tools
    Configuration File Manipulation with Configuration Management Tools Student Paper for 185.307 Seminar aus Programmiersprachen, SS2016 Bernhard Denner, 0626746 Email: [email protected] Abstract—Manipulating and defining content of configuration popular CM-Tool in these days and offers a huge variety of files is one of the central tasks of configuration management configuration manipulation methods. But we will also take a tools. This is important to ensure a desired and correct behavior look at other CM-Tools to explore their view of configuration of computer systems. However, often considered very simple, this file handling. task can turn out to be very challenging. Configuration manage- ment tools provide different strategies for content manipulation In Section II an introduction will be given about CM- of files, hence an administrator should think twice to choose the Tools, examining which ones are established in the community best strategy for a specific task. This paper will explore different and how they work. Before we dive into file manipulation approaches of automatic configuration file manipulation with the strategies, Section III will give some introduction in configu- help of configuration management tools. We will take a close look at the configuration management tool Puppet, as is offers various ration stores. Section IV will describe different configuration different approaches to tackle content manipulation. We will also manipulation strategies of Puppet, whereas Section V will explore similarities and differences of approaches by comparing look at approaches of other CM-Tools. Section VI will show it with other configuration management tools. This should aid some scientific papers about CM-Tools.
    [Show full text]
  • Confex: a Framework for Automating Text-Based Software Configuration
    1 ConfEx: A Framework for Automating Text-based Software Configuration Analysis in the Cloud Ozan Tuncer, Anthony Byrne, Nilton Bila, Sastry Duri, Canturk Isci, and Ayse K. Coskun Abstract—Modern cloud services have complex architectures, often comprising many software components, and depend on hundreds of configurations parameters to function correctly, securely, and with high performance. Due to the prevalence of open-source software, developers can easily deploy services using third-party software without mastering the configurations of that software. As a result, configuration errors (i.e., misconfigurations) are among the leading causes of service disruptions and outages. While existing cloud automation tools ease the process of service deployment and management, support for detecting misconfigurations in the cloud has not been addressed thoroughly, likely due to the lack of frameworks suitable for consistent parsing of unstandardized configuration files. This paper introduces ConfEx, a framework that enables discovery and extraction of text-based software configurations in the cloud. ConfEx uses a novel vocabulary-based technique to identify configuration files in cloud system instances with unlabeled content. To extract the information in these files, ConfEx leverages existing configuration parsers and post-processes the extracted data for analysis. We show that ConfEx achieves over 99% precision and 100% recall in identifying configuration files on 7805 popular Docker Hub images. Using two applied examples, we demonstrate that ConfEx also enables detecting misconfigurations in the cloud via existing tools that are designed for configurations represented as key-value pairs, revealing 184 errors in public Docker Hub images. Index Terms—Software configuration, cloud, misconfiguration diagnosis. F 1 INTRODUCTION LOUD applications are designed in a highly config- Existing failure avoidance and mitigation mechanisms in C urable way to ensure high levels of reusability and the cloud (e.g., redundancy or recovery) are insufficient to portability.
    [Show full text]
  • Unibasic 9.3 Reference Guide
    Unibasic - Dynamic Concepts Wiki 6/19/17, 1244 PM Unibasic From Dynamic Concepts Wiki Contents 1 UniBasic 2 About this Guide 2.1 Conventions 3 Installation & Configuration 3.1 Configuring Unix for UniBasic 3.1.1 Number of Processes 3.1.2 Number of Open Files 3.1.3 Number of Open i-nodes 3.1.4 Number of Locks 3.1.5 Message Queues 3.2 Unix Accounting & Protection System 3.3 Creating a Unix Account for UniBasic 3.4 UniBasic Security & Licensing 3.4.1 Software Licensing 3.4.2 Hardware Licensing 3.5 Loading the Installation File 3.5.1 Loading the UniBasic Installation File 3.5.2 Loading the UniBasic Development File 3.6 ubinstall - Installing UniBasic Packages 3.6.1 Errors During Installation 3.7 Configuring a UniBasic Environment 3.7.1 Directories and Paths 3.7.2 Filenames and Pathnames 3.7.3 Organizing Logical Units and Packnames 3.7.4 Environment Variables 3.7.5 Setting up .profile for Multiple Users 3.8 Command Line Interpreter 3.9 Launching UniBasic From Unix 3.10 Terminating a UniBasic Process 3.11 Licensing a New Installation 3.12 Changing the SSN Activation Key 3.13 Launching UniBasic Ports at Startup 3.14 Configuring Printer Drivers 3.15 Configuring Serial Printers 3.16 Configuring Terminal Drivers 3.17 Creating a Customized Installation Media 4 Introduction To UniBasic 4.1 Data 4.1.1 Numeric Data 4.1.1.1 Numeric Precision 4.1.1.2 Special Notes on %3 and %6 Numerics https://engineering.dynamic.com/mediawiki/index.php?title=Unibasic&printable=yes Page 1 of 397 Unibasic - Dynamic Concepts Wiki 6/19/17, 1244 PM 4.1.1.3 Integers Stored in Floating-Point
    [Show full text]
  • IBM Education Assistance for Z/OS V2R1
    IBM Education Assistance for z/OS V2R1 Item: ASCII Unicode Option Element/Component: UNIX Shells and Utilities (S&U) Material is current as of June 2013 © 2013 IBM Corporation Filename: zOS V2R1 USS S&U ASCII Unicode Option Agenda ■ Trademarks ■ Presentation Objectives ■ Overview ■ Usage & Invocation ■ Migration & Coexistence Considerations ■ Presentation Summary ■ Appendix Page 2 of 19 © 2013 IBM Corporation Filename: zOS V2R1 USS S&U ASCII Unicode Option IBM Presentation Template Full Version Trademarks ■ See url http://www.ibm.com/legal/copytrade.shtml for a list of trademarks. Page 3 of 19 © 2013 IBM Corporation Filename: zOS V2R1 USS S&U ASCII Unicode Option IBM Presentation Template Full Presentation Objectives ■ Introduce the features and benefits of the new z/OS UNIX Shells and Utilities (S&U) support for working with ASCII/Unicode files. Page 4 of 19 © 2013 IBM Corporation Filename: zOS V2R1 USS S&U ASCII Unicode Option IBM Presentation Template Full Version Overview ■ Problem Statement –As a z/OS UNIX Shells & Utilities user, I want the ability to control the text conversion of input files used by the S&U commands. –As a z/OS UNIX Shells & Utilities user, I want the ability to run tagged shell scripts (tcsh scripts and SBCS sh scripts) under different SBCS locales. ■ Solution –Add –W filecodeset=codeset,pgmcodeset=codeset option on several S&U commands to enable text conversion – consistent with support added to vi and ex in V1R13. –Add –B option on several S&U commands to disable automatic text conversion – consistent with other commands that already have this override support. –Add new _TEXT_CONV environment variable to enable or disable text conversion.
    [Show full text]
  • Reference Manual for the Icon Programming Language Version 5 (( Implementation for Limx)*
    Reference Manual for the Icon Programming Language Version 5 (( Implementation for liMX)* Can A. Contain. Ralph £ Grixwoltl, and Stephen B. Watnplcr "RSI-4a December 1981, Corrected July 1982 Department of Computer Science The University of Arizona Tucson, Arizona 85721 This work was supported by the National Science Foundation under Grant MCS79-03890. Copyright © 1981 by Ralph E. Griswold All rights reserved. No part of this work may be reproduced, transmitted, or stored in any form or by any means without the prior written consent of the copyright owner. CONTENTS Chapter i Introduction 1.1 Background I 1.2 Scope ol the Manual 2 1.3 An Overview of Icon 2 1.4 Syntax Notation 2 1.5 Organization ol the Manual 3 Chapter 2 Basic Concepts and Operations 2.1 Types 4 2.2 Expressions 4 2.2.1 Variables and Assignment 4 2.2.2 Keywords 5 2.2.3 Functions 5 2.2.4 Operators 6 2.3 Evaluation of Expressions 6 2.3.1 Results 6 2.3.2 Success and Failure 7 2.4 Basic Control Structures 7 2.5 Compound Expressions 9 2.6 Loop Control 9 2.7 Procedures 9 Chapter 3 Generators and Expression Evaluation 3.1 Generators 11 3.2 Goal-Directed Evaluation 12 }.?> Evaluation of Expres.sions 13 3.4 I he Extent ol Backtracking 14 3.5 I he Reversal ol Effects 14 Chapter 4 Numbers and Arithmetic Operations 4.1 Integers 15 4.1.1 literal Integers 15 4.1.2 Integer Arithmetic 15 4.1.3 Integer Comparison 16 4.2 Real Numbers 17 4.2.1 literal Real Numbers 17 4.2.2 Real Arithmetic 17 4.2.3 Comparison of Real Numbers IS 4.3 Mixed-Mode Arithmetic IX 4.4 Arithmetic Type Conversion 19
    [Show full text]
  • Software II: Principles of Programming Languages
    Software II: Principles of Programming Languages Lecture 6 – Data Types Some Basic Definitions • A data type defines a collection of data objects and a set of predefined operations on those objects • A descriptor is the collection of the attributes of a variable • An object represents an instance of a user- defined (abstract data) type • One design issue for all data types: What operations are defined and how are they specified? Primitive Data Types • Almost all programming languages provide a set of primitive data types • Primitive data types: Those not defined in terms of other data types • Some primitive data types are merely reflections of the hardware • Others require only a little non-hardware support for their implementation The Integer Data Type • Almost always an exact reflection of the hardware so the mapping is trivial • There may be as many as eight different integer types in a language • Java’s signed integer sizes: byte , short , int , long The Floating Point Data Type • Model real numbers, but only as approximations • Languages for scientific use support at least two floating-point types (e.g., float and double ; sometimes more • Usually exactly like the hardware, but not always • IEEE Floating-Point Standard 754 Complex Data Type • Some languages support a complex type, e.g., C99, Fortran, and Python • Each value consists of two floats, the real part and the imaginary part • Literal form real component – (in Fortran: (7, 3) imaginary – (in Python): (7 + 3j) component The Decimal Data Type • For business applications (money)
    [Show full text]
  • Zentrale Verwaltung Mit Facter, Puppet Und Augeas
    System-Management-Trio Zentrale Verwaltung mit facter, puppet und augeas Verwaltung mit facter, puppet und augeas © SpeedPartner GmbH Seite: 1 / 34 GUUG Frühjahrsfachgespräch, 01.03.2012 Über den Vortrag Aufbau / Ziele: ● Einführung / Überblick ● Begriffsklärung ● Aufbau / Arbeitsweise von Manifests ● Templates, Klassen, Typen, Module ● Facter: Umgebungsparameter ermitteln ● Augeas: Konfigurationen bearbeiten ● Client-Server-Betrieb ● Arbeit mit mehreren Umgebungen ● Links / Hilfen Verwaltung mit facter, puppet und augeas © SpeedPartner GmbH Seite: 2 / 34 GUUG Frühjahrsfachgespräch, 01.03.2012 Über mich ● Stefan Neufeind ● Mit-Geschäftsführer der SpeedPartner GmbH aus Neuss ein Internet-Service-Provider (ISP) ● Individuelle TYPO3-Entwicklungen ● Hosting, Housing, Managed Services ● Domains / Domain-Services ● IPv6, DNSSEC, ... ● Aktive Mitarbeit im Community-Umfeld (PHP/PEAR, TYPO3, Linux) ● Freier Autor für z.B. t3n, iX, Internet World, ... Verwaltung mit facter, puppet und augeas © SpeedPartner GmbH Seite: 3 / 34 GUUG Frühjahrsfachgespräch, 01.03.2012 Aufgabenstellung Alltägliche Administrationsaufgaben für ein (Server-)System Basisinstallation Fehler bei Ausführung von Zugänge „Standard-Aufgaben“? Backup Monitoring Fehlersuche / Einrichtung / Fehlerkorrektur Konzeptfehler? Konfiguration Netzwerk Fehler durch die Systemstatistiken „Sonderlösungen“? Architektur Virtuell? Individuelle Anpassungen Aufgaben RAID? Verwaltung mit facter, puppet und augeas © SpeedPartner GmbH Seite: 4 / 34 GUUG Frühjahrsfachgespräch, 01.03.2012 Aufgabenstellung
    [Show full text]
  • Standard TECO (Text Editor and Corrector)
    Standard TECO TextEditor and Corrector for the VAX, PDP-11, PDP-10, and PDP-8 May 1990 This manual was updated for the online version only in May 1990. User’s Guide and Language Reference Manual TECO-32 Version 40 TECO-11 Version 40 TECO-10 Version 3 TECO-8 Version 7 This manual describes the TECO Text Editor and COrrector. It includes a description for the novice user and an in-depth discussion of all available commands for more advanced users. General permission to copy or modify, but not for profit, is hereby granted, provided that the copyright notice is included and reference made to the fact that reproduction privileges were granted by the TECO SIG. © Digital Equipment Corporation 1979, 1985, 1990 TECO SIG. All Rights Reserved. This document was prepared using DECdocument, Version 3.3-1b. Contents Preface ............................................................ xvii Introduction ........................................................ xix Preface to the May 1985 edition ...................................... xxiii Preface to the May 1990 edition ...................................... xxv 1 Basics of TECO 1.1 Using TECO ................................................ 1–1 1.2 Data Structure Fundamentals . ................................ 1–2 1.3 File Selection Commands ...................................... 1–3 1.3.1 Simplified File Selection .................................... 1–3 1.3.2 Input File Specification (ER command) . ....................... 1–4 1.3.3 Output File Specification (EW command) ...................... 1–4 1.3.4 Closing Files (EX command) ................................ 1–5 1.4 Input and Output Commands . ................................ 1–5 1.5 Pointer Positioning Commands . ................................ 1–5 1.6 Type-Out Commands . ........................................ 1–6 1.6.1 Immediate Inspection Commands [not in TECO-10] .............. 1–7 1.7 Text Modification Commands . ................................ 1–7 1.8 Search Commands .
    [Show full text]
  • Rehearsal: a Configuration Verification Tool for Puppet
    Rehearsal: A Configuration Verification Tool for Puppet t* Rian Shambaugh Aaron Weiss Arjun Guha ac AE f Comp C i * let t nt e e * r t is W s University of Massachusetts Amherst, United States e n A l o l D C * * o * c I u e E s frian,aaronweiss,[email protected] m u D e e v n R L t e o a t d P y * s a E l u * a d t e Abstract 1. Introduction Large-scale data centers and cloud computing have turned Consider the role of a system administrator at any organi- system configuration into a challenging problem. Several zation, from a large company to a small computer science widely-publicized outages have been blamed not on soft- department. Their job is to maintain computing infrastruc- ware bugs, but on configuration bugs. To cope, thousands of ture for everyone else. When a new software system, such as organizations use system configuration languages to manage a Web service, needs to be deployed, it is their job to pro- their computing infrastructure. Of these, Puppet is the most vision new servers, configure the firewall, and ensure that widely used with thousands of paying customers and many data is automatically backed up. If the Web service receives more open-source users. The heart of Puppet is a domain- a sudden spike in traffic, they must quickly deploy additional specific language that describes the state of a system. Pup- machines to handle the load. When a security vulnerability pet already performs some basic static checks, but they only is disclosed, they must patch and restart machines if neces- prevent a narrow range of errors.
    [Show full text]
  • Rc the Plan 9 Shell
    Rc ߞ The Plan 9 Shell Tom Duff [email protected]−labs.com ABSTRACT Rc is a command interpreter for Plan 9 that provides similar facilities to UNIXߣs Bourne shell, with some small additions and less idiosyncratic syntax. This paper uses numerous examples to describe rcߣs features, and contrasts rc with the Bourne shell, a model that many readers will be familiar with. 1. Introduction Rc is similar in spirit but different in detail from UNIXߣs Bourne shell. This paper describes rcߣs principal features with many small examples and a few larger ones. It assumes familiarity with the Bourne shell. 2. Simple commands For the simplest uses rc has syntax familiar to Bourne-shell users. All of the fol­ lowing behave as expected: date cat /lib/news/build who >user.names who >>user.names wc <file echo [a−f]*.c who | wc who; date vc *.c & mk && v.out /*/bin/fb/* rm −r junk || echo rm failed! 3. Quotation An argument that contains a space or one of rcߣs other syntax characters must be enclosed in apostrophes (’): rm ’odd file name’ An apostrophe in a quoted argument must be doubled: echo ’How’’s your father?’ 4. Patterns An unquoted argument that contains any of the characters *?[is a pattern to be matched against file names. A * character matches any sequence of characters, ? matches any single character, and [class] matches any character in the class, unless the first character of class is ~, in which case the class is complemented. The class may ­ 2 ­ also contain pairs of characters separated by −, standing for all characters lexically between the two.
    [Show full text]
  • IBM ILOG CPLEX Optimization Studio OPL Language Reference Manual
    IBM IBM ILOG CPLEX Optimization Studio OPL Language Reference Manual Version 12 Release 7 Copyright notice Describes general use restrictions and trademarks related to this document and the software described in this document. © Copyright IBM Corp. 1987, 2017 US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Trademarks IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at www.ibm.com/legal/copytrade.shtml. Adobe, the Adobe logo, PostScript, and the PostScript logo are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, and/or other countries. Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates. Other company, product, or service names may be trademarks or service marks of others. © Copyright IBM Corporation 1987, 2017. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Figures ............... v Limitations on constraints ........ 59 Formal parameters ...........
    [Show full text]