Manydsl One Host for All Language Needs

Total Page:16

File Type:pdf, Size:1020Kb

Manydsl One Host for All Language Needs ManyDSL One Host for All Language Needs Piotr Danilewski March 2017 A dissertation submitted towards the degree (Dr.-Ing.) of the Faculty of Mathematics and Computer Science of Saarland University. Saarbrücken Dean Prof. Dr. Frank-Olaf Schreyer Date of Colloquium June 6, 2017 Examination Board: Chairman Prof. Dr. Sebastian Hack Reviewers Prof. Dr.-Ing. Philipp Slusallek Prof. Dr. Wilhelm Reinhard Scientific Asistant Dr. Tim Dahmen Piotr Danilewski, [email protected] Saarbrücken, June 6, 2017 Statement I hereby declare that this dissertation is my own original work except where otherwise indicated. All data or concepts drawn directly or indirectly from other sources have been correctly acknowledged. This dissertation has not been submitted in its present or similar form to any other academic institution either in Germany or abroad for the award of any degree. Saarbrücken, June 6, 2017 (Piotr Danilewski) Declaration of Consent Herewith I agree that my thesis will be made available through the library of the Computer Science Department. Saarbrücken, June 6, 2017 (Piotr Danilewski) Zusammenfassung Die Sprachen prägen die Denkweise. Das ist die Tatsache für die gesprochenen Sprachen aber auch für die Programmiersprachen. Da die Computer immer wichtiger in jedem Aspekt des menschlichen Lebens sind, steigt der Bedarf um entsprechend neue Konzepte in den Programmiersprachen auszudrücken. Jedoch, damit unsere Denkweise sich weiterentwicklen könnte, müssen sich auch die Programmiersprachen weiterentwickeln. Aber welche Hilfsmittel gibt es um die Programmiersprachen zu schaffen und aufzurüsten? Wie kann man Entwickler ermutigen damit sie eigene Sprachen definieren, die dem Bereich in dem sie arbeiten am besten passen? Heutzutage gibt es zwei Methoden. Die erste Methode: es gibt spezifische Werkzeuge und Parser-Generatoren, die zum Schaffen der unabhängigen Pro- grammiersprache von Anfang an dienen. Die zweite Methode: man kann die ausreichend flexiblen exisitierenden Hostsprachen ausnutzen, um in sie kleine DSL einzubetten. Die beiden Methoden haben eigene Beschränkungen. Einerseits braucht man viel Aufwand um die unabhängige Programiersprache zu schaffen. Diese Sprache ist es schwer mit den anderen Sprachen zu verbinden. Andererseits sind die eingebetteten DSLs durch Syntax der Hostsprache eingeschränkt. Außerdem wenn die eingebetteten DSLs einmal definiert sein werden, sind sie ständig gegenwärtig. Es gibt keine Abgrenzung zwischen den eingebetteten DSLs und der Host- sprache. Wenn man viele eingebettete DSLs verwendet, führt es zur Sprachen- mischung, die Syntax durcheinander hat. Diese Sprachenmischung hat auch unerwartete Interaktionen zwischen den Sprachen. In der vorliegenden Arbeit wird die alternative Lösung dargestellt: ManyDSL. Das ist ein einzigartiger Interpreter und Compiler, die aus diesen Lösungen Kraft schöpft und meidet die Schwächen dieser Lösungen. ManyDSL hat den eigegen LL1 Parser-Generator, der die Beschränkungen meidet, die von der Hostsprache aufgedrängt sind. Beschreibung der Grammatik ist definiert in derselben Programmiersprache wie die anderen Teile des Pro- gramms. Die Fragmente der Grammatiken können parametrisiert werden und aus diesen Fragmenten können Funktionen geschaffen werden. Diese Funktionen können zum Schaffen der nächsten Sprachen benutzt werden. Die Sprachen werden während des Interpretationsprozesses geschaffen und sie können benutzt werden um nächste Fragmente des Quellecodes zu parsen. Ähnlich den eingebetteten DSLs übersetzt ManyDSL alle Sprachen in die Hostsprache. Die Hostpsprache verwendet Continuation-Passing Style (CPS) mit der neuartigen, dynamischen Methode für Staging. Staging erlaubt Partial Evaluation und Ausführung von Quellecode in vielen Phasen. Das kann zum Definieren der Optimierung und der ’zusätzlichen Berechnung’ benutzt werden — alles das in der Funktionalen Methode, ohne Abstrakten Syntaxbaum (ASTs) zu benutzen. Mit der Hilfe von ManyDSL kann der Benutzer neue Sprachen mit der erkennbaren Syntax bauen. Außerdem kann er viele Sprachen innerhalb eines Projektes verwenden. Diese Sprachen haben genaue Grenzen und der Benutzer kann zwischen diesen Sprachen umschalten. Dank diesen Grenzen treten diese Sprachen miteinander in die Interaktion auf kontrollierte Art und Weise. ManyDSL ist der erste Schritt zum Sprachwechsel in den Programmier- sprachen. Mit der Hilfe von ManyDSL möchte ich die Entwickler zum Schaffen der Sprachen, die denen am besten passen, ermutigen. Ich hoffe, dass jeder Entwickler mit der Zeit mit der Hilfe von grammatischen Bibliotheken neue Sprachen schaffen kann. Abstract Languages shape thoughts. This is true for human spoken languages as much as for programming languages. As computers continue to expand their dominance in almost every aspect of our lives, the need to more adequately express new concepts and domains in computer languages arise. However, to evolve our thoughts we need to evolve the languages we speek in. But what tools are there to create and upgrade the computer languages? How can we encourage developers to define their own languages quickly to best match the domains they work in? Nowadays two main approaches exists. Dedicated language tools and parser generators allows to define new standalone languages from scratch. Alternatively, one can “abuse” sufficiently flexible host languages to embed small domain- specific languages within them. Both approaches have their own respective limitations. Creating standalone languages is a major endeavor. Such languages cannot be combined easily with other languages. Embedding, on the other hand, is limited by the syntax of the host language. Embedded languages, once defined, are always present without clear distinction between them and the host language. When used extensively, it leads to one humungous conglomerate of languages, with confusing syntax and unexpected interactions. In this work we present an alternative: ManyDSL. It is a unique interpreter and compiler taking strength from both approaches, while avoiding the above weaknesses. ManyDSL features its own LL1 parser generator, breaking the limits of the syntax of the host language. The grammar description is given in the same host language as the rest of the program. Portions of the grammar can be parametrized and abstracted into functions, in order to be used in other language definitions. Languages are created on the fly during the interpretation process and may be used to parse selected fragments of the subsequent source files. Similarly to embedded languages, ManyDSL translates all custom languages to the same host language before execution. The host language uses a continuation- passing style approach with a novel, dynamic approach to staging. The staging allows for arbitrary partial evaluation, and executing code at different phases of the compilation process. This can be used to define domain-specific optimiza- tions and auxiliary computation (e.g. for verification) — all within an entirely functional approach, without any explicit use of abstract syntax trees and code transformations. With the help of ManyDSL a user is able to create new languages with distinct, easily recognizable syntax. Moreover, he is able to define and use many of such languages within a single project. Languages can be switched with a well-defined boundary, enabling their interaction in a clear and controlled way. ManyDSL is meant to be the first step towards a broader language pluralism. With it we want to encourage developers to design and use languages that best suit their needs. We believe that over time, with the help of grammar libraries, creating new languages will become accessible to every programmer. Contents 1 Introduction1 1.1 Motivation..............................1 1.2 Solutions Today............................4 1.3 Our Work...............................6 1.4 The Structure of this Work..................... 10 2 Background 13 2.1 Language Clasification........................ 13 2.1.1 Language Generations.................... 13 2.1.2 Language Paradigms..................... 15 2.2 Compilation and Interpretation................... 17 2.2.1 Compilation Phases..................... 17 2.2.2 Type Checking........................ 18 2.3 Staging................................ 22 2.3.1 Fixed Staging......................... 23 2.3.2 Textual Staging........................ 25 2.3.3 Structured Staging...................... 26 2.3.4 Dynamic Code Generation.................. 28 2.3.5 Code as a First Class Citizen................ 29 2.3.6 Automated Staging...................... 32 2.3.7 Staging in ManyDSL..................... 33 2.4 Language Construction........................ 34 2.4.1 Parser Generators...................... 34 2.4.2 Parser Combinators..................... 35 2.4.3 Code Generation....................... 36 2.5 Language Embedding........................ 37 2.5.1 Plain Shallow Embedding.................. 38 2.5.2 Deep Embedding....................... 39 2.5.3 Shallow Embedding with Staging.............. 42 2.6 Metamorphic Languages....................... 43 2.6.1 The Importance of Syntax.................. 43 2.6.2 Macro Languages....................... 48 2.6.3 Racket............................. 50 2.6.4 Grammar Extension..................... 51 2.6.5 Grammar replacement.................... 53 2.6.6 Metamorphism in ManyDSL................ 54 xi 3 ManyDSL Overview 57 3.1 The Main Goal............................ 57 3.2 Properties............................... 59 3.3 Design Decisions........................... 64 3.4 Separation of Concerns.......................
Recommended publications
  • Working on ENIAC: the Lost Labors of the Information Age
    Working on ENIAC: The Lost Labors of the Information Age Thomas Haigh www.tomandmaria.com/tom University of Wisconsin—Milwaukee & Mark Priestley www.MarkPriestley.net This Research Is Sponsored By • Mrs L.D. Rope’s Second Charitable Trust • Mrs L.D. Rope’s Third Charitable Trust Thanks for contributions by my coauthors Mark Priestley & Crispin Rope. And to assistance from others including Ann Graf, Peter Sachs Collopy, and Stephanie Dick. www.EniacInAction.com CONVENTIONAL HISTORY OF COMPUTING www.EniacInAction.com The Battle for “Firsts” www.EniacInAction.com Example: Alan Turing • A lone genius, according to The Imitation Game – “I don’t have time to explain myself as I go along, and I’m afraid these men will only slow me down” • Hand building “Christopher” – In reality hundreds of “bombes” manufactured www.EniacInAction.com Isaacson’s “The Innovators” • Many admirable features – Stress on teamwork – Lively writing – References to scholarly history – Goes back beyond 1970s – Stresses role of liberal arts in tech innovation • But going to disagree with some basic assumptions – Like the subtitle! www.EniacInAction.com Amazon • Isaacson has 7 of the top 10 in “Computer Industry History” – 4 Jobs – 3 Innovators www.EniacInAction.com Groundbreaking for “Pennovation Center” Oct, 2014 “Six women Ph.D. students were tasked with programming the machine, but when the computer was unveiled to the public on Valentine’s Day of 1946, Isaacson said, the women programmers were not invited to the black tie event after the announcement.” www.EniacInAction.com Teams of Superheroes www.EniacInAction.com ENIAC as one of the “Great Machines” www.EniacInAction.com ENIAC Life Story • 1943: Proposed and approved.
    [Show full text]
  • Herman Heine Goldstine
    Herman Heine Goldstine Born September 13, 1913, Chicago, Ill.; Army representative to the ENIAC Project, who later worked with John von Neumann on the logical design of the JAS computer which became the prototype for many early computers-ILLIAC, JOHNNIAC, MANIAC author of The Computer from Pascal to von Neumann, one of the earliest textbooks on the history of computing. Education: BS, mathematics, University of Chicago, 1933; MS, mathematics, University of Chicago, 1934; PhD, mathematics, University of Chicago, 1936. Professional Experience: University of Chicago: research assistant, 1936-1937, instructor, 1937-1939; assistant professor, University of Michigan, 1939-1941; US Army, Ballistic Research Laboratory, Aberdeen, Md., 1941-1946; Institute for Advanced Study, Princeton University, 1946-1957; IBM: director, Mathematics Sciences Department, 1958-1965, IBM fellow, 1969. Honors and Awards: IEEE Computer Society Pioneer Award, 1980; National Medal of Science, 1985; member, Information Processing Hall of Fame, Infornart, Dallas, Texas, 1985. Herman H. Goldstine began his scientific career as a mathematician and had a life-long interest in the interaction of mathematical ideas and technology. He received his PhD in mathematics from the University of Chicago in 1936 and was an assistant professor at the University of Michigan when he entered the Army in 1941. After participating in the development of the first electronic computer (ENIAC), he left the Army in 1945, and from 1946 to 1957 he was a member of the Institute for Advanced Study (IAS), where he collaborated with John von Neumann in a series of scientific papers on subjects related to their work on the Institute computer. In 1958 he joined IBM Corporation as a member of the research planning staff.
    [Show full text]
  • “Scrap Your Boilerplate” Reloaded
    “Scrap Your Boilerplate” Reloaded Ralf Hinze1, Andres L¨oh1, and Bruno C. d. S. Oliveira2 1 Institut f¨urInformatik III, Universit¨atBonn R¨omerstraße164, 53117 Bonn, Germany {ralf,loeh}@informatik.uni-bonn.de 2 Oxford University Computing Laboratory Wolfson Building, Parks Road, Oxford OX1 3QD, UK [email protected] Abstract. The paper “Scrap your boilerplate” (SYB) introduces a com- binator library for generic programming that offers generic traversals and queries. Classically, support for generic programming consists of two es- sential ingredients: a way to write (type-)overloaded functions, and in- dependently, a way to access the structure of data types. SYB seems to lack the second. As a consequence, it is difficult to compare with other approaches such as PolyP or Generic Haskell. In this paper we reveal the structural view that SYB builds upon. This allows us to define the combinators as generic functions in the classical sense. We explain the SYB approach in this changed setting from ground up, and use the un- derstanding gained to relate it to other generic programming approaches. Furthermore, we show that the SYB view is applicable to a very large class of data types, including generalized algebraic data types. 1 Introduction The paper “Scrap your boilerplate” (SYB) [1] introduces a combinator library for generic programming that offers generic traversals and queries. Classically, support for generic programming consists of two essential ingredients: a way to write (type-)overloaded functions, and independently, a way to access the structure of data types. SYB seems to lacks the second, because it is entirely based on combinators.
    [Show full text]
  • On Specifying and Visualising Long-Running Empirical Studies
    On Specifying and Visualising Long-Running Empirical Studies Peter Y. H. Wong and Jeremy Gibbons Computing Laboratory, University of Oxford, United Kingdom fpeter.wong,[email protected] Abstract. We describe a graphical approach to formally specifying tem- porally ordered activity routines designed for calendar scheduling. We introduce a workflow model OWorkflow, for constructing specifications of long running empirical studies such as clinical trials in which obser- vations for gathering data are performed at strict specific times. These observations, either manually performed or automated, are often inter- leaved with scientific procedures, and their descriptions are recorded in a calendar for scheduling and monitoring to ensure each observation is carried out correctly at a specific time. We also describe a bidirectional transformation between OWorkflow and a subset of Business Process Modelling Notation (BPMN), by which graphical specification, simula- tion, automation and formalisation are made possible. 1 Introduction A typical long-running empirical study consists of a series of scientific proce- dures interleaved with a set of observations performed over a period of time; these observations may be manually performed or automated, and are usually recorded in a calendar schedule. An example of a long-running empirical study is a clinical trial, where observations, specifically case report form submissions, are performed at specific points in the trial. In such examples, observations are interleaved with clinical interventions on patients; precise descriptions of these observations are then recorded in a patient study calendar similar to the one shown in Figure 1(a). Currently study planners such as trial designers supply information about observations either textually or by inputting textual infor- mation and selecting options on XML-based data entry forms [2], similar to the one shown in Figure 1(b).
    [Show full text]
  • Dec. 21St Ladies’ [May 00]
    recruited and trained some of the six ENIAC ‘Refrigerator Dec. 21st Ladies’ [May 00]. Lawrence (Larry) In 1945, she wrote the “Manual for the ENIAC”; the first Gilman Roberts George Barnard technical description of the machine, detailed right down to Born: Dec. 21, 1937; Grant the resistor level. Connecticut Died: Dec 30, 2018 Born: Dec. 21, 1849; In 1946, Goldstine, Jean Bartik Gardiner, Maine [Dec 27] and Dick Clippinger, Roberts is often called one of the Died: Aug. 16, 1917 implemented Clippinger’s stored “Fathers of the ARPANET,” [Oct 29] a title he earned by being its Grant is called the "Father of the program modifications to the principal architect, and directing American Gear Cutting ENIAC, with John von Neumann the team that built it. Other Industry,” because of how his [Dec 28] acting as a consultant ARPANET fathers include Bob work on building mechanical on the instruction set. Kahn [Dec 23], Vint Cerf [June calculating machines affected 23], and Jon Postel [Aug 6]. that industry. Roberts first became interested While a student at Harvard, he Douglas Taylor in timesharing networks after became interested in Charles reading J.C.R. Licklider’s [March Babbage’s [Dec 26] and Per Ross 11] memos on the “Intergalactic Georg Scheutz’s [Sept 23] Born: Dec. 21, 1929; Computer Network” [May 1] , differential engines, and China (his US parents were and after meeting him at a designed one himself. He missionaries) conference in Virginia in Nov. published his work in the Died: Jan. 31, 2007 1964. Aug.1871 issue of the American Journal of Science and Arts, and Ross developed the APT In Oct.
    [Show full text]
  • Lecture Notes in Computer Science 6120 Commenced Publication in 1973 Founding and Former Series Editors: Gerhard Goos, Juris Hartmanis, and Jan Van Leeuwen
    Lecture Notes in Computer Science 6120 Commenced Publication in 1973 Founding and Former Series Editors: Gerhard Goos, Juris Hartmanis, and Jan van Leeuwen Editorial Board David Hutchison Lancaster University, UK Takeo Kanade Carnegie Mellon University, Pittsburgh, PA, USA Josef Kittler University of Surrey, Guildford, UK Jon M. Kleinberg Cornell University, Ithaca, NY, USA Alfred Kobsa University of California, Irvine, CA, USA Friedemann Mattern ETH Zurich, Switzerland John C. Mitchell Stanford University, CA, USA Moni Naor Weizmann Institute of Science, Rehovot, Israel Oscar Nierstrasz University of Bern, Switzerland C. Pandu Rangan Indian Institute of Technology, Madras, India Bernhard Steffen TU Dortmund University, Germany Madhu Sudan Microsoft Research, Cambridge, MA, USA Demetri Terzopoulos University of California, Los Angeles, CA, USA Doug Tygar University of California, Berkeley, CA, USA Gerhard Weikum Max-Planck Institute of Computer Science, Saarbruecken, Germany Claude Bolduc Jules Desharnais Béchir Ktari (Eds.) Mathematics of Program Construction 10th International Conference, MPC 2010 Québec City, Canada, June 21-23, 2010 Proceedings 13 Volume Editors Claude Bolduc Jules Desharnais Béchir Ktari Université Laval, Département d’informatique et de génie logiciel Pavillon Adrien-Pouliot, 1065 Avenue de la Médecine Québec, QC, G1V 0A6, Canada E-mail: {Claude.Bolduc, Jules.Desharnais, Bechir.Ktari}@ift.ulaval.ca Library of Congress Control Number: 2010927075 CR Subject Classification (1998): F.3, D.2, F.4.1, D.3, D.2.4, D.1 LNCS Sublibrary: SL 1 – Theoretical Computer Science and General Issues ISSN 0302-9743 ISBN-10 3-642-13320-7 Springer Berlin Heidelberg New York ISBN-13 978-3-642-13320-6 Springer Berlin Heidelberg New York This work is subject to copyright.
    [Show full text]
  • Domain-Specific Languages for Modeling and Simulation
    Domain-specifc Languages for Modeling and Simulation Dissertation zur Erlangung des akademischen Grades Doktor-Ingenieur (Dr.-Ing.) der Fakultät für Informatik und Elektrotechnik der Universität Rostock vorgelegt von Tom Warnke, geb. am 25.01.1988 in Malchin aus Rostock Rostock, 14. September 2020 https://doi.org/10.18453/rosdok_id00002966 Dieses Werk ist lizenziert unter einer Creative Commons Namensnennung - Weitergabe unter gleichen Bedingungen 4.0 International Lizenz. Gutachter: Prof. Dr. Adelinde M. Uhrmacher (Universität Rostock) Prof. Rocco De Nicola (IMT Lucca) Prof. Hans Vangheluwe (Universität Antwerpen) Eingereicht am 14. September 2020 Verteidigt am 8. Januar 2021 Abstract Simulation models and simulation experiments are increasingly complex. One way to handle this complexity is developing software languages tailored to specifc application domains, so-called domain-specifc languages (DSLs). This thesis explores the potential of employing DSLs in modeling and simulation. We study diferent DSL design and implementation techniques and illustrate their benefts for expressing simulation models as well as simulation experiments with several examples. Regarding simulation models, we focus on discrete-event models based on continuous- time Markov chains (CTMCs). Most of our work revolves around ML-Rules, an rule-based modeling language for biochemical reaction networks. First, we relate the expressive power of ML-Rules to other currently available modeling languages for this application domain. Then we defne the abstract syntax and operational semantics for ML-Rules, mapping models to CTMCs in an unambiguous and precise way. Based on the formal defnitions, we present two approaches to implement ML-Rules as a DSL. The core of both implementations is fnding the matches for the patterns on the left side of ML-Rules’ rules.
    [Show full text]
  • Unbounded Spigot Algorithms for the Digits of Pi
    Unbounded Spigot Algorithms for the Digits of Pi Jeremy Gibbons 1 INTRODUCTION. Rabinowitz and Wagon [8] present a “remarkable” algorithm for com- puting the decimal digits of π, based on the expansion ∞ (i!)22i+1 π = ∑ . (1) i=0 (2i + 1)! Their algorithm uses only bounded integer arithmetic, and is surprisingly efficient. Moreover, it admits extremely concise implementations. Witness, for example, the following (deliberately obfuscated) C pro- gram due to Dik Winter and Achim Flammenkamp [1, p. 37], which produces the first 15,000 decimal digits of π: a[52514],b,c=52514,d,e,f=1e4,g,h;main(){for(;b=c-=14;h=printf("%04d", e+d/f))for(e=d%=f;g=--b*2;d/=g)d=d*b+f*(h?a[b]:f/5),a[b]=d%--g;} Rabinowitz and Wagon call their algorithm a spigot algorithm, because it yields digits incrementally and does not reuse digits after they have been computed. The digits drip out one by one, as if from a leaky tap. In contrast, most algorithms for computing the digits of π execute inscrutably, delivering no output until the whole computation is completed. However, the Rabinowitz–Wagon algorithm has its weaknesses. In particular, the computation is in- herently bounded: one has to commit in advance to computing a certain number of digits. Based on this commitment, the computation proceeds on an appropriate finite prefix of the infinite series (1). In fact, it is essentially impossible to determine in advance how big that finite prefix should be for a given number of digits—specifically, a computation that terminates with nines for the last few digits of the output is inconclusive, because there may be a “carry” from the first few truncated terms.
    [Show full text]
  • Towards a Repository of Bx Examples
    Towards a Repository of Bx Examples James Cheney, James McKinna, Jeremy Gibbons Perdita Stevens Department of Computer Science School of Informatics University of Oxford University of Edinburgh fi[email protected][email protected] ABSTRACT that researchers in bx will both add their examples to the reposi- We argue for the creation of a curated repository of examples of tory, and refer to examples from the repository as appropriate. This bidirectional transformations (bx). In particular, such a resource should have benefits both for authors and for readers. Naturally, may support research on bx, especially cross-fertilisation between papers will still have to be sufficiently self-contained; but we think the different communities involved. We have initiated a bx reposi- that the repository may still be helpful. For example, if one’s paper tory, which is introduced in this paper. We discuss our design deci- illustrates some new work using an existing example, one might sions and their rationale, and illustrate them using the now classic describe the example briefly (as at present), focusing on the as- Composers example. We discuss the difficulties that this undertak- pects most relevant to the work at hand. One can, however, also ing may face, and comment on how they may be overcome. give a reference into the repository, where there is more detail and discussion of the example, which some readers may find helpful. Over time, we might expect that certain examples in the repository 1. INTRODUCTION become familiar to most researchers in bx. Then, if a paper says Research into bidirectional transformations (henceforth: bx) in- it uses such an example, the reader’s task is eased.
    [Show full text]
  • The Women of ENIAC
    The Women of ENIAC W. BARKLEY FRITZ A group of young women college graduates involved with the EFJIAC are identified. As a result of their education, intelligence, as well as their being at the right place and at the right time, these young women were able to per- form important computer work. Many learned to use effectively “the machine that changed the world to assist in solving some of the important scientific problems of the time. Ten of them report on their background and experi- ences. It is now appropriate that these women be given recognition for what they did as ‘pioneers” of the Age of Computing. introduction any young women college graduates were involved in ties of some 50 years ago, you will note some minor inconsiskn- NI[ various ways with ENIAC (Electronic Numerical Integra- cies, which arc to be expected. In order to preserve the candor and tor And Computer) during the 1942-195.5 period covering enthusiasm of these women for what they did and also to provide ENIAC’s pre-development, development, and 10-year period of today’s reader and those of future generations with their First-hand its operational usage. ENIAC, as is well-known, was the first accounts, I have attempted to resolve only the more serious incon- general purpose electronic digital computer to be designed, built, sistencies. Each of the individuals quoted, however, has been and successfully used. After its initial use for the Manhattan Proj- given an opportunity to see the remarks of their colleagues and to ect in the fall of 194.5 and its public demonstration in February modify their own as desired.
    [Show full text]
  • A Separation Logic for Concurrent Randomized Programs
    A Separation Logic for Concurrent Randomized Programs JOSEPH TASSAROTTI, Carnegie Mellon University, USA ROBERT HARPER, Carnegie Mellon University, USA We present Polaris, a concurrent separation logic with support for probabilistic reasoning. As part of our logic, we extend the idea of coupling, which underlies recent work on probabilistic relational logics, to the setting of programs with both probabilistic and non-deterministic choice. To demonstrate Polaris, we verify a variant of a randomized concurrent counter algorithm and a two-level concurrent skip list. All of our results have been mechanized in Coq. CCS Concepts: • Theory of computation → Separation logic; Program verification; Additional Key Words and Phrases: separation logic, concurrency, probability ACM Reference Format: Joseph Tassarotti and Robert Harper. 2019. A Separation Logic for Concurrent Randomized Programs. Proc. ACM Program. Lang. 3, POPL, Article 64 (January 2019), 31 pages. https://doi.org/10.1145/3290377 1 INTRODUCTION Many concurrent algorithms use randomization to reduce contention and coordination between threads. Roughly speaking, these algorithms are designed so that if each thread makes a local random choice, then on average the aggregate behavior of the whole system will have some good property. For example, probabilistic skip lists [53] are known to work well in the concurrent setting [25, 32], because threads can independently insert nodes into the skip list without much synchronization. In contrast, traditional balanced tree structures are difficult to implement in a scalable way because re-balancing operations may require locking access to large parts of the tree. However, concurrent randomized algorithms are difficult to write and reason about. The useof just concurrency or randomness alone makes it hard to establish the correctness of an algorithm.
    [Show full text]
  • Profunctor Optics Modular Data Accessors
    Profunctor Optics Modular Data Accessors Matthew Pickeringa, Jeremy Gibbonsb, and Nicolas Wua a University of Bristol b University of Oxford Abstract Data accessors allow one to read and write components of a data structure, such as the fields of a record, the variants of a union, or the elements of a container. These data accessors are collectively known as optics; they are fundamental to programs that manipulate complex data. Individual data accessors for simple data structures are easy to write, for example as pairs of ‘getter’ and ‘setter’ methods. However, it is not obvious how to combine data accessors, in such a way that data accessors for a compound data structure are composed out of smaller data accessors for the parts of that structure. Generally, one has to write a sequence of statements or declarations that navigate step by step through the data structure, accessing one level at a time—which is to say, data accessors are traditionally not first-class citizens, combinable in their own right. We present a framework for modular data access, in which individual data accessors for simple data struc- tures may be freely combined to obtain more complex data accessors for compound data structures. Data accessors become first-class citizens. The framework is based around the notion of profunctors, a flexible gen- eralization of functions. The language features required are higher-order functions (‘lambdas’ or ‘closures’), parametrized types (‘generics’ or ‘abstract types’) of higher kind, and some mechanism for separating inter- faces from implementations (‘abstract classes’ or ‘modules’). We use Haskell as a vehicle in which to present our constructions, but other languages such as Scala that provide the necessary features should work just as well.
    [Show full text]