DOCSLIB.ORG

Extensible Languages for Flexible and Principled Domain Abstraction

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Extensible Languages for Flexible and Principled Domain Abstraction Extensible Languages for Flexible and Principled Domain Abstraction Dissertation for the degree of Doctor of Natural Sciences Submitted by Sebastian Thore Erdweg, MSc born March 14, 1985 in Frankfurt/Main Department of Mathematics and Computer Science Philipps-Universität Marburg Referees: Prof. Dr. Klaus Ostermann Dr. Eelco Visser Prof. Dr. Ralf Lämmel Submitted November 28, 2012. Defended March 06, 2013. Marburg, 2013. Erdweg, Sebastian: Extensible Languages for Flexible and Principled Domain Abstraction Dissertation, Philipps-Universität Marburg (1180), 2013. Curriculum vitae 2007, Bachelor of Science, TU Darmstadt 2009, Master of Science, Aarhus University Cover photo by Tellerdreher Photography, 2012. Abstract Most programming languages are designed for general-purpose software deve- lopment in a one-size-fits-all fashion: They provide the same set of language features and constructs for all possible applications programmers ever may want to develop. As with shoes, the one-size-fits-all solution grants a good fit to few applications only. The trend toward domain-specific languages, model-driven development, and language-oriented programming counters general-purpose languages by promo- ting the use of domain abstractions that facilitate domain-specific language features and constructs tailored to certain application domains. In particular, domain abstraction avoids the need for encoding domain concepts with general- purpose language features and thus allows programmers to program at the same abstraction level as they think. Unfortunately, current approaches to domain abstraction cannot deliver on the promises of domain abstraction. On the one hand, approaches that target internal domain-specific languages lack flexibility regarding the syntax, static checking, and tool support of domain abstractions, which limits the level of actually achieved domain abstraction. On the other hand, approaches that target external domain-specific languages lack important principles, such as modular reasoning and composition of domain abstractions, which inhibits the applicability of these approaches in the development of larger software systems. In this thesis, we pursue a novel approach that unifies the advantages of internal and external domain-specific languages to support flexible and principled domain abstraction. We propose library-based extensible programming languages as a basis for do- main abstraction. In an extensible language, domain abstraction can be realized by extending the language with domain-specific syntax, static analysis, and tool support. This enables domain abstractions as flexible as external domain-specific languages. To ensure the compliance with important software-development principles, we organize language extensions as libraries and use simple import statements to activate extensions. This facilitates modular reasoning (by inspec- ting import statements), supports the composition of domain abstractions (by iii importing multiple extensions), and allows uniform self-application of language extensions in the development of further extensions (by importing extensions in an extension definition). A library-based organization of extensions enables domain abstractions as principled as internal domain-specific languages. We designed and implemented SugarJ, a library-based extensible programming language on top of Java. SugarJ libraries can declare and export extensions of SugarJ’s syntax, static analysis, and editor support. Thereby, a syntactic extension consists of an extended syntax and a desugaring transformation from the extended syntax into SugarJ base syntax, an analysis extension matches on part of the current file’s abstract syntax tree and produces a list of errors, and an editor extension declares editor services such as coloring or code completion for certain language constructs. SugarJ extensions are fully self-applicable: An exten- ded syntax can desugar into the declaration of another extensions, an extended analysis can check the declaration of an extension, and an extended editor can assist developers in writing extensions. To process a source file with extensions, the SugarJ compiler and IDE inspect the imported libraries to determine active extensions. The compiler and IDE adapt the parser, code generator, analyzer, and editor of the source file according to the active extensions. In this thesis, we do not only describe the design and implementation of SugarJ, but also report on extensions of the original design. In particular, we designed and implemented a generalization of the SugarJ compiler that supports alternative base languages besides Java. Using this generalization, we developed the library-based extensible programming languages SugarHaskell, SugarPro- log, and SugarFomega. Furthermore, we developed an extension of SugarJ that supports polymorphic domain abstraction and ensures communication integri- ty. Polymorphic domain abstraction enables programmers to provide multiple desugarings for the same domain-specific syntax. This increases the flexibili- ty of SugarJ and supports scenarios known from model-driven development. Communication integrity specifies that components of a software system may communicate over explicit channels only. This is interesting in the context of code generation where it effectively prohibits the generation of implicit module dependencies. We augmented SugarJ’s principles by enforcing communication integrity. On the basis of SugarJ and numerous case studies, we argue that flexible and principled domain abstraction constitutes a scalable programming model for the development of complex software systems. Zusammenfassung Die meisten Programmiersprachen werden als Universalsprachen entworfen. Un- abhängig von der zu entwickelnden Anwendung, stellen sie die gleichen Sprach- features und Sprachkonstrukte zur Verfügung. Solch universelle Sprachfeatures ignorieren jedoch die spezifischen Anforderungen, die viele Softwareprojekte mit sich bringen. Als Gegenkraft zu Universalsprachen fördern domänenspezifische Program- miersprachen, modellgetriebene Softwareentwicklung und sprachorientierte Pro- grammierung die Verwendung von Domänenabstraktion, welche den Einsatz von domänenspezifischen Sprachfeatures und Sprachkonstrukten ermöglicht. Insbesondere erlaubt Domänenabstraktion Programmieren auf dem selben Ab- straktionsniveau zu programmieren wie zu denken und vermeidet dadurch die Notwendigkeit Domänenkonzepte mit universalsprachlichen Features zu kodieren. Leider ermöglichen aktuelle Ansätze zur Domänenabstraktion nicht die Ent- faltung ihres ganzen Potentials. Einerseits mangelt es den Ansätzen für interne domänenspezifische Sprachen an Flexibilität bezüglich der Syntax, statischer Analysen, und Werkzeugunterstützung, was das tatsächlich erreichte Abstrakti- onsniveau beschränkt. Andererseits mangelt es den Ansätzen für externe domä- nenspezifische Sprachen an wichtigen Prinzipien, wie beispielsweise modularem Schließen oder Komposition von Domänenabstraktionen, was die Anwendbarkeit dieser Ansätze in der Entwicklung größerer Softwaresysteme einschränkt. Wir verfolgen in der vorliegenden Doktorarbeit einen neuartigen Ansatz, welcher die Vorteile von internen und externen domänenspezifischen Sprachen vereint um flexible und prinzipientreue Domänenabstraktion zu unterstützen. Wir schlagen bibliotheksbasierte erweiterbare Programmiersprachen als Grund- lage für Domänenabstraktion vor. In einer erweiterbaren Sprache kann Domä- nenabstraktion durch die Erweiterung der Sprache mit domänenspezifischer Syntax, statischer Analyse, und Werkzeugunterstützung erreicht werden . Dies ermöglicht Domänenabstraktionen die selbe Flexibilität wie externe domänen- spezifische Sprachen. Um die Einhaltung üblicher Prinzipien zu gewährleisten, organisieren wir Spracherweiterungen als Bibliotheken und verwenden einfache Import-Anweisungen zur Aktivierung von Erweiterungen. Dies erlaubt modu- v lares Schließen (durch die Inspektion der Import-Anweisungen), unterstützt die Komposition von Domänenabstraktionen (durch das Importieren mehrerer Erweiterungen), und ermöglicht die uniforme Selbstanwendbarkeit von Spracher- weiterungen in der Entwicklung zukünftiger Erweiterungen (durch das Importie- ren von Erweiterungen in einer Erweiterungsdefinition). Die Organisation von Erweiterungen in Form von Bibliotheken ermöglicht Domänenabstraktionen die selbe Prinzipientreue wie interne domänenspezifische Sprachen. Wir haben die bibliotheksbasierte erweiterbare Programmiersprache SugarJ entworfen und implementiert. SugarJ Bibliotheken können Erweiterungen der Syntax, der statischen Analyse, und der Werkzeugunterstützung von SugarJ deklarieren. Eine syntaktische Erweiterung besteht dabei aus einer erweiterten Syntax und einer Transformation der erweiterten Syntax in die Basissyntax von SugarJ. Eine Erweiterung der Analyse testet Teile des abstrakten Syn- taxbaums der aktuellen Datei und produziert eine Liste von Fehlern. Eine Erweiterung der Werkzeugunterstützung deklariert Dienste wie Syntaxfärbung oder Codevervollständigung für bestimmte Sprachkonstrukte. SugarJ Erweite- rungen sind vollkommen selbstanwendbar: Eine erweiterte Syntax kann in eine Erweiterungsdefinition transformiert werden, eine erweiterte Analyse kann Er- weiterungsdefinitionen testen, und eine erweiterte Werkzeugunterstützung kann Entwicklern beim Definieren von Erweiterungen assistieren. Um eine Quelldatei mit Erweiterungen zu verarbeiten, inspizieren der SugarJ Compiler und die SugarJ IDE die importierten Bibliotheken um die aktiven Erweiterungen zu be- stimmen. Der
Load more

Recommended publications
  • Lecture 4. Higher-Order Functions Functional Programming
    Lecture 4. Higher-order functions Functional Programming [Faculty of Science Information and Computing Sciences] 0 I function call and return as only control-flow primitive I no loops, break, continue, goto I (almost) unique types I no inheritance hell I high-level declarative data-structures I no explicit reference-based data structures Goal of typed purely functional programming Keep programs easy to reason about by I data-flow only through function arguments and return values I no hidden data-flow through mutable variables/state [Faculty of Science Information and Computing Sciences] 1 I (almost) unique types I no inheritance hell I high-level declarative data-structures I no explicit reference-based data structures Goal of typed purely functional programming Keep programs easy to reason about by I data-flow only through function arguments and return values I no hidden data-flow through mutable variables/state I function call and return as only control-flow primitive I no loops, break, continue, goto [Faculty of Science Information and Computing Sciences] 1 I high-level declarative data-structures I no explicit reference-based data structures Goal of typed purely functional programming Keep programs easy to reason about by I data-flow only through function arguments and return values I no hidden data-flow through mutable variables/state I function call and return as only control-flow primitive I no loops, break, continue, goto I (almost) unique types I no inheritance hell [Faculty of Science Information and Computing Sciences] 1 Goal
    [Show full text]
  • Higher-Order Functions 15-150: Principles of Functional Programming – Lecture 13
    Higher-order Functions 15-150: Principles of Functional Programming { Lecture 13 Giselle Reis By now you might feel like you have a pretty good idea of what is going on in functional program- ming, but in reality we have used only a fragment of the language. In this lecture we see what more we can do and what gives the name functional to this paradigm. Let's take a step back and look at ML's typing system: we have basic types (such as int, string, etc.), tuples of types (t*t' ) and functions of a type to a type (t ->t' ). In a grammar style (where α is a basic type): τ ::= α j τ ∗ τ j τ ! τ What types allowed by this grammar have we not used so far? Well, we could, for instance, have a function below a tuple. Or even a function within a function, couldn't we? The following are completely valid types: int*(int -> int) int ->(int -> int) (int -> int) -> int The first one is a pair in which the first element is an integer and the second one is a function from integers to integers. The second one is a function from integers to functions (which have type int -> int). The third type is a function from functions to integers. The two last types are examples of higher-order functions1, i.e., a function which: • receives a function as a parameter; or • returns a function. Functions can be used like any other value. They are first-class citizens. Maybe this seems strange at first, but I am sure you have used higher-order functions before without noticing it.
    [Show full text]
  • Programming Language
    Programming language A programming language is a formal language, which comprises a set of instructions that produce various kinds of output. Programming languages are used in computer programming to implement algorithms. Most programming languages consist of instructions for computers. There are programmable machines that use a set of specific instructions, rather than general programming languages. Early ones preceded the invention of the digital computer, the first probably being the automatic flute player described in the 9th century by the brothers Musa in Baghdad, during the Islamic Golden Age.[1] Since the early 1800s, programs have been used to direct the behavior of machines such as Jacquard looms, music boxes and player pianos.[2] The programs for these The source code for a simple computer program written in theC machines (such as a player piano's scrolls) did not programming language. When compiled and run, it will give the output "Hello, world!". produce different behavior in response to different inputs or conditions. Thousands of different programming languages have been created, and more are being created every year. Many programming languages are written in an imperative form (i.e., as a sequence of operations to perform) while other languages use the declarative form (i.e. the desired result is specified, not how to achieve it). The description of a programming language is usually split into the two components ofsyntax (form) and semantics (meaning). Some languages are defined by a specification document (for example, theC programming language is specified by an ISO Standard) while other languages (such as Perl) have a dominant implementation that is treated as a reference.
    [Show full text]
  • Safe, Fast and Easy: Towards Scalable Scripting Languages
    Safe, Fast and Easy: Towards Scalable Scripting Languages by Pottayil Harisanker Menon A dissertation submitted to The Johns Hopkins University in conformity with the requirements for the degree of Doctor of Philosophy. Baltimore, Maryland Feb, 2017 ⃝c Pottayil Harisanker Menon 2017 All rights reserved Abstract Scripting languages are immensely popular in many domains. They are char- acterized by a number of features that make it easy to develop small applications quickly - flexible data structures, simple syntax and intuitive semantics. However they are less attractive at scale: scripting languages are harder to debug, difficult to refactor and suffers performance penalties. Many research projects have tackled the issue of safety and performance for existing scripting languages with mixed results: the considerable flexibility offered by their semantics also makes them significantly harder to analyze and optimize. Previous research from our lab has led to the design of a typed scripting language built specifically to be flexible without losing static analyzability. Inthis dissertation, we present a framework to exploit this analyzability, with the aim of producing a more efficient implementation Our approach centers around the concept of adaptive tags: specialized tags attached to values that represent how it is used in the current program. Our frame- work abstractly tracks the flow of deep structural types in the program, and thuscan ii ABSTRACT efficiently tag them at runtime. Adaptive tags allow us to tackle key issuesatthe heart of performance problems of scripting languages: the framework is capable of performing efficient dispatch in the presence of flexible structures. iii Acknowledgments At the very outset, I would like to express my gratitude and appreciation to my advisor Prof.
    [Show full text]
  • Clojure, Given the Pun on Closure, Representing Anything Specific
    dynamic, functional programming for the JVM “It (the logo) was designed by my brother, Tom Hickey. “It I wanted to involve c (c#), l (lisp) and j (java). I don't think we ever really discussed the colors Once I came up with Clojure, given the pun on closure, representing anything specific. I always vaguely the available domains and vast emptiness of the thought of them as earth and sky.” - Rich Hickey googlespace, it was an easy decision..” - Rich Hickey Mark Volkmann [email protected] Functional Programming (FP) In the spirit of saying OO is is ... encapsulation, inheritance and polymorphism ... • Pure Functions • produce results that only depend on inputs, not any global state • do not have side effects such as Real applications need some changing global state, file I/O or database updates side effects, but they should be clearly identified and isolated. • First Class Functions • can be held in variables • can be passed to and returned from other functions • Higher Order Functions • functions that do one or both of these: • accept other functions as arguments and execute them zero or more times • return another function 2 ... FP is ... Closures • main use is to pass • special functions that retain access to variables a block of code that were in their scope when the closure was created to a function • Partial Application • ability to create new functions from existing ones that take fewer arguments • Currying • transforming a function of n arguments into a chain of n one argument functions • Continuations ability to save execution state and return to it later think browser • back button 3 ..
    [Show full text]
  • Topic 6: Partial Application, Function Composition and Type Classes
    Recommended Exercises and Readings Topic 6: Partial Application, • From Haskell: The craft of functional programming (3rd Ed.) Function Composition and Type • Exercises: • 11.11, 11.12 Classes • 12.30, 12.31, 12.32, 12.33, 12.34, 12.35 • 13.1, 13.2, 13.3, 13.4, 13.7, 13.8, 13.9, 13.11 • If you have time: 12.37, 12.38, 12.39, 12.40, 12.41, 12.42 • Readings: • Chapter 11.3, and 11.4 • Chapter 12.5 • Chapter 13.1, 13.2, 13.3 and 13.4 1 2 Functional Forms Curried and Uncurried Forms • The parameters to a function can be viewed in two different ways • Uncurried form • As a single combined unit • Parameters are bundled into a tuple and passed as a group • All values are passed as one tuple • Can be used in Haskell • How we typically think about parameter passing in Java, C++, Python, Pascal, C#, … • Typically only when there is a specific need to do • As a sequence of values that are passed one at a time • As each value is passed, a new function is formed that requires one fewer parameters • Curried form than its predecessor • Parameters are passed to a function sequentially • How parameters are passed in Haskell • Standard form in Haskell • But it’s not a detail that we need to concentrate on except when we want to make use of it • Functions can be transformed from one form to the other 3 4 Curried and Uncurried Forms Curried and Uncurried Forms • A function in curried form • Why use curried form? • Permits partial application multiply :: Int ‐> Int ‐> Int • Standard way to define functions in Haskell multiply x y = x * y • A function of n+1
    [Show full text]
  • Dynamic Extension of Typed Functional Languages
    Dynamic Extension of Typed Functional Languages Don Stewart PhD Dissertation School of Computer Science and Engineering University of New South Wales 2010 Supervisor: Assoc. Prof. Manuel M. T. Chakravarty Co-supervisor: Dr. Gabriele Keller Abstract We present a solution to the problem of dynamic extension in statically typed functional languages with type erasure. The presented solution re- tains the benefits of static checking, including type safety, aggressive op- timizations, and native code compilation of components, while allowing extensibility of programs at runtime. Our approach is based on a framework for dynamic extension in a stat- ically typed setting, combining dynamic linking, runtime type checking, first class modules and code hot swapping. We show that this framework is sufficient to allow a broad class of dynamic extension capabilities in any statically typed functional language with type erasure semantics. Uniquely, we employ the full compile-time type system to perform run- time type checking of dynamic components, and emphasize the use of na- tive code extension to ensure that the performance benefits of static typing are retained in a dynamic environment. We also develop the concept of fully dynamic software architectures, where the static core is minimal and all code is hot swappable. Benefits of the approach include hot swappable code and sophisticated application extension via embedded domain specific languages. We instantiate the concepts of the framework via a full implementation in the Haskell programming language: providing rich mechanisms for dy- namic linking, loading, hot swapping, and runtime type checking in Haskell for the first time. We demonstrate the feasibility of this architecture through a number of novel applications: an extensible text editor; a plugin-based network chat bot; a simulator for polymer chemistry; and xmonad, an ex- tensible window manager.
    [Show full text]
  • Proceedings of the 8Th European Lisp Symposium Goldsmiths, University of London, April 20-21, 2015 Julian Padget (Ed.) Sponsors
    Proceedings of the 8th European Lisp Symposium Goldsmiths, University of London, April 20-21, 2015 Julian Padget (ed.) Sponsors We gratefully acknowledge the support given to the 8th European Lisp Symposium by the following sponsors: WWWLISPWORKSCOM i Organization Programme Committee Julian Padget – University of Bath, UK (chair) Giuseppe Attardi — University of Pisa, Italy Sacha Chua — Toronto, Canada Stephen Eglen — University of Cambridge, UK Marc Feeley — University of Montreal, Canada Matthew Flatt — University of Utah, USA Rainer Joswig — Hamburg, Germany Nick Levine — RavenPack, Spain Henry Lieberman — MIT, USA Christian Queinnec — University Pierre et Marie Curie, Paris 6, France Robert Strandh — University of Bordeaux, France Edmund Weitz — University of Applied Sciences, Hamburg, Germany Local Organization Christophe Rhodes – Goldsmiths, University of London, UK (chair) Richard Lewis – Goldsmiths, University of London, UK Shivi Hotwani – Goldsmiths, University of London, UK Didier Verna – EPITA Research and Development Laboratory, France ii Contents Acknowledgments i Messages from the chairs v Invited contributions Quicklisp: On Beyond Beta 2 Zach Beane µKanren: Running the Little Things Backwards 3 Bodil Stokke Escaping the Heap 4 Ahmon Dancy Unwanted Memory Retention 5 Martin Cracauer Peer-reviewed papers Efficient Applicative Programming Environments for Computer Vision Applications 7 Benjamin Seppke and Leonie Dreschler-Fischer Keyboard? How quaint. Visual Dataflow Implemented in Lisp 15 Donald Fisk P2R: Implementation of
    [Show full text]
  • A Type and Scope Safe Universe of Syntaxes with Binding: Their Semantics and Proofs
    ZU064-05-FPR jfp19 26 March 2020 16:6 Under consideration for publication in J. Functional Programming 1 A Type and Scope Safe Universe of Syntaxes with Binding: Their Semantics and Proofs GUILLAUME ALLAIS, ROBERT ATKEY University of Strathclyde (UK) JAMES CHAPMAN Input Output HK Ltd. (HK) CONOR MCBRIDE University of Strathclyde (UK) JAMES MCKINNA University of Edinburgh (UK) Abstract Almost every programming language’s syntax includes a notion of binder and corresponding bound occurrences, along with the accompanying notions of α-equivalence, capture-avoiding substitution, typing contexts, runtime environments, and so on. In the past, implementing and reasoning about programming languages required careful handling to maintain the correct behaviour of bound variables. Modern programming languages include features that enable constraints like scope safety to be expressed in types. Nevertheless, the programmer is still forced to write the same boilerplate over again for each new implementation of a scope safe operation (e.g., renaming, substitution, desugaring, printing, etc.), and then again for correctness proofs. We present1 an expressive universe of syntaxes with binding and demonstrate how to (1) implement scope safe traversals once and for all by generic programming; and (2) how to derive properties of these traversals by generic proving. Our universe description, generic traversals and proofs, and our examples have all been formalised in Agda and are available in the accompanying material available online at https://github.com/gallais/generic-syntax. 1 Introduction In modern typed programming languages, programmers writing embedded DSLs (Hudak (1996)) and researchers formalising them can now use the host language’s type system to help them.
    [Show full text]
  • Functional Programming Lecture 1: Introduction
    Functional Programming Lecture 13: FP in the Real World Viliam Lisý Artificial Intelligence Center Department of Computer Science FEE, Czech Technical University in Prague [email protected] 1 Mixed paradigm languages Functional programming is great easy parallelism and concurrency referential transparency, encapsulation compact declarative code Imperative programming is great more convenient I/O better performance in certain tasks There is no reason not to combine paradigms 2 3 Source: Wikipedia 4 Scala Quite popular with industry Multi-paradigm language • simple parallelism/concurrency • able to build enterprise solutions Runs on JVM 5 Scala vs. Haskell • Adam Szlachta's slides 6 Is Java 8 a Functional Language? Based on: https://jlordiales.me/2014/11/01/overview-java-8/ Functional language first class functions higher order functions pure functions (referential transparency) recursion closures currying and partial application 7 First class functions Previously, you could pass only classes in Java File[] directories = new File(".").listFiles(new FileFilter() { @Override public boolean accept(File pathname) { return pathname.isDirectory(); } }); Java 8 has the concept of method reference File[] directories = new File(".").listFiles(File::isDirectory); 8 Lambdas Sometimes we want a single-purpose function File[] csvFiles = new File(".").listFiles(new FileFilter() { @Override public boolean accept(File pathname) { return pathname.getAbsolutePath().endsWith("csv"); } }); Java 8 has lambda functions for that File[] csvFiles = new File(".")
    [Show full text]
  • Agda User Manual Release 2.6.3
    Agda User Manual Release 2.6.3 The Agda Team Sep 23, 2021 Contents 1 Overview 3 2 Getting Started 5 2.1 What is Agda?..............................................5 2.2 Installation................................................7 2.3 ‘Hello world’ in Agda.......................................... 13 2.4 A Taste of Agda............................................. 14 2.5 A List of Tutorials............................................ 22 3 Language Reference 25 3.1 Abstract definitions............................................ 25 3.2 Built-ins................................................. 27 3.3 Coinduction............................................... 40 3.4 Copatterns................................................ 42 3.5 Core language.............................................. 45 3.6 Coverage Checking............................................ 48 3.7 Cubical.................................................. 51 3.8 Cumulativity............................................... 65 3.9 Data Types................................................ 66 3.10 Flat Modality............................................... 69 3.11 Foreign Function Interface........................................ 70 3.12 Function Definitions........................................... 75 3.13 Function Types.............................................. 78 3.14 Generalization of Declared Variables.................................. 79 3.15 Guarded Cubical............................................. 84 3.16 Implicit Arguments...........................................
    [Show full text]
  • Current Issue of FACS FACTS
    Issue 2021-2 July 2021 FACS A C T S The Newsletter of the Formal Aspects of Computing Science (FACS) Specialist Group ISSN 0950-1231 FACS FACTS Issue 2021-2 July 2021 About FACS FACTS FACS FACTS (ISSN: 0950-1231) is the newsletter of the BCS Specialist Group on Formal Aspects of Computing Science (FACS). FACS FACTS is distributed in electronic form to all FACS members. Submissions to FACS FACTS are always welcome. Please visit the newsletter area of the BCS FACS website for further details at: https://www.bcs.org/membership/member-communities/facs-formal-aspects- of-computing-science-group/newsletters/ Back issues of FACS FACTS are available for download from: https://www.bcs.org/membership/member-communities/facs-formal-aspects- of-computing-science-group/newsletters/back-issues-of-facs-facts/ The FACS FACTS Team Newsletter Editors Tim Denvir [email protected] Brian Monahan [email protected] Editorial Team: Jonathan Bowen, John Cooke, Tim Denvir, Brian Monahan, Margaret West. Contributors to this issue: Jonathan Bowen, Andrew Johnstone, Keith Lines, Brian Monahan, John Tucker, Glynn Winskel BCS-FACS websites BCS: http://www.bcs-facs.org LinkedIn: https://www.linkedin.com/groups/2427579/ Facebook: http://www.facebook.com/pages/BCS-FACS/120243984688255 Wikipedia: http://en.wikipedia.org/wiki/BCS-FACS If you have any questions about BCS-FACS, please send these to Jonathan Bowen at [email protected]. 2 FACS FACTS Issue 2021-2 July 2021 Editorial Dear readers, Welcome to the 2021-2 issue of the FACS FACTS Newsletter. A theme for this issue is suggested by the thought that it is just over 50 years since the birth of Domain Theory1.
    [Show full text]