Typed Open Programming

Total Page:16

File Type:pdf, Size:1020Kb

Typed Open Programming Typed Open Programming A higher-order, typed approach to dynamic modularity and distribution Preliminary Version Andreas Rossberg Dissertation zur Erlangung des Grades des Doktors der Ingenieurwissenschaften der Naturwissenschaftlich-Technischen Fakult¨aten der Universit¨at des Saarlandes Saarbr¨ucken, 5. Januar 2007 Dekan: Prof. Dr. Andreas Sch¨utze Erstgutachter: Prof. Dr. Gert Smolka Zweitgutachter: Prof. Dr. Andreas Zeller ii Abstract In this dissertation we develop an approach for reconciling open programming – the development of programs that support dynamic exchange of higher-order values with other processes – with strong static typing in programming languages. We present the design of a concrete programming language, Alice ML, that consists of a conventional functional language extended with a set of orthogonal features like higher-order modules, dynamic type checking, higher-order serialisation, and concurrency. On top of these a flexible system of dynamic components and a simple but expressive notion of distribution is realised. The central concept in this design is the package, a first-class value embedding a module along with its interface type, which is dynamically checked whenever the module is extracted. Furthermore, we develop a formal model for abstract types that is not invalidated by the presence of primitives for dynamic type inspection, as is the case for the standard model based on existential quantification. For that purpose, we present an idealised language in form of an extended λ-calculus, which can express dynamic generation of types. This calculus is the first to combine and explore the interference of sealing and type inspection with higher-order singleton kinds, a feature for expressing sharing constraints on abstract types. A novel notion of abstracton kinds classifies abstract types. Higher-order type and kind coercions allow for modular translucent encapsulation of values at arbitrary type. Kurzdarstellung In dieser Dissertation entwickeln wir einen programmiersprachlichen Ansatz zur Verbindung offener Programmierung – der Entwicklung von Programmen, die das dynamische Laden und Austauschen h¨oherstufiger Werte mit anderen Prozessen erlauben – mit starker statischer Typ- isierung. Wir stellen das Design einer konkreten Programmiersprache namens Alice ML vor. Sie besteht aus einer konventionellen funktionalen Sprache, die um einen Satz orthogonaler Konzepte wie h¨oherstufige Modularisierung, dynamische Typ¨uberpr¨ufung, h¨oherstufige Serialisierung und Nebenl¨aufigkeit erweitert wurde. Darauf aufbauend ist ein flexibles System dynamischer Kom- ponenten sowie ein einfacher aber expressiver Ansatz f¨ur Verteilung verwirklicht. Zentral ist dabei das Konzept eines Pakets (package), welches ein Modul in Kombination mit seinem Schnittstellentyp in einen Wert einbettet, und bei der Extraktion des Moduls eine dynamis- che Typ¨uberpr¨ufung vornimmt. Weiterhin entwickeln wir einen theoretischen Ansatz zur Modellierung von abstrakten Typen, welcher im Gegensatz zum herk¨ommlichen formalen Modell existentieller Quantifizierung auch in Gegenwart dynamischer Typinspektion g¨ultig ist. Zu diesem Zweck definieren wir eine idealisierte Sprache in Form eines erweiterten λ-Kalk¨uls, der dynamische Typgenerierung ausdr¨ucken kann. Der Kalk¨ul kombiniert diese erstmals mit h¨oherstufigen ”Singleton Kinds, einem Sprachkonstrukt, welches Gleichheit von Typen ausdr¨ucken kann. Zur Klassifizierung abstrakter Typen werden Abstraktions-Kinds als verwandtes Konzept entwickelt. H¨oherstufige Konversionen auf Term- und Typebene erlauben zudem die nachtr¨agliche modulare Enkap- sulierung von Werten beliebigen Typs. iii Zusammenfassung Die zunehmende Verbreitung des Internets hat begonnen, die Struktur von Software nachhaltig zu ver¨andern. An die Stelle von in sich geschlossenen Programmen, die nur lokal operieren, treten mehr und mehr offene Applikationen, die dynamisch Daten mit anderen Prozessen im Netzwerk austauschen, oder von dort sogar neue Funktionalit¨at beziehen. Das offensichtlichste Beispiel f¨ur ein Programm dieser Kategorie ist ein Web-Browser. Auf programmiersprachlicher Ebene erfordert dieser Paradigmenwechsel eine verbesserte Un- terst¨utzung offener Programmierung, zu der wir Konzepte wie Modularit¨at, Dynamik, Porta- bilit¨at, Sicherheit, Verteilung und Nebenl¨aufigkeit z¨ahlen. Nur wenige existierende Sprachen sind bisher darauf ausgelegt. Zu ihnen geh¨oren vor allem die zu diesem Zweck entwickelte objektorientierte Sprache Java, die mittlerweile weite industrielle Verbreitung gefunden hat, und die im akademischen Umfeld entwickelte nebenl¨aufige Constraint-Sprache Oz. Diese setzt entsprechende Konzepte noch weitaus konsequenter um, insbesondere durch die einheitliche Repr¨asentation von Programmkomponenten und externen Daten, so dass beide beliebig gemis- cht werden k¨onnen. Diese Dissertation widmet sich einem spezifischen Aspekt offener Programmierung, der bis- lang von keinem der Vertreter auf befriedigende Weise gel¨ost wurde: der Kombination offener Programmierung mit einem expressiven, starken Typsystem. Ein Typsystem ist ein in die Pro- grammiersprache integriertes formales Werkzeug zur automatischen Verifikation bestimmter Pro- grammeigenschaften. Es weist jedem Programmkonstrukt einen Typ zu, eine logische Formel, die das bei Ausf¨uhrung des Konstrukts zu erwartende Resultat klassifiziert. Die damit m¨oglichen Konsistenzpr¨ufungen k¨onnen die Zuverl¨assigkeit von Software verbessern. Moderne Program- miersprachen bieten zudem die M¨oglichkeit, die Typstruktur um benutzerdefinierte, sogenannte abstrakte Typen zu erweitern, welche die Festlegung gewisser Zugriffsbeschr¨ankungen erlauben. Wenn die Semantik der Programmiersprache verhindert, dass diese Zugriffsbeschr¨ankungen um- gangen werden k¨onnen, so spricht man von Abstraktionssicherheit. Diese garantiert Modu- larit¨atseigenschaften und steigert damit vor allem die Wartbarkeit von Programmen. Typ¨uberpr¨ufungen erfolgen naturgem¨ass vor der Ausf¨uhrung eines Programmes, ¨ublicherweise durch den Ubersetzer¨ der verwendeten Programmiersprache. Dadurch entsteht ein inh¨arenter Konflikt mit offener Programmierung, da in einem offenen Ansatz im Allgemeinen nicht alle Programmteile vorweg bekannt sind und analysiert werden k¨onnen. Es ist deshalb unausweich- lich, bestimmte Typ¨uberpr¨ufungen in die Laufzeit des Programms zu verlagern. Ein seit langem bekannter Ansatz daf¨ur ist die Einbringung eines speziellen universellen Typs Dynamic, der Werte der Sprache gepaart mit ihrem jeweiligen Typ beinhaltet. Die Extraktion eines Wertes er- folgt explizit und erfordert die Angabe eines oder mehrerer erwarteter Zieltypen, die dynamisch abgeglichen werden. Leider haben sich Dynamics jedoch in der Praxis als zu unhandlich er- wiesen. Zudem ergeben sich durch die M¨oglichkeit des dynamischen Typabgleichs semantische Implikationen, die unter anderem die Abstraktionssicherheit abstrakter Typen beeintr¨achtigen. Wir n¨ahern uns diesen Problemen von zwei Seiten an. Zum einen beschreiben wir das Design einer konkreten Sprache names Alice ML, welche typisierte offene Programmierung erm¨oglicht. Dabei handelt es sich um einen Dialekt der funktionalen Sprache Standard ML, die durch einen relativ kleinen Satz orthogonaler und hinreichen einfacher Sprachkonstrukte erweitert wurde. Dabei handelt es sich zun¨achst um Pickling zum serialisierten Import und Export h¨oherstufiger iv Werte, verschiedene Formen von Futures f¨ur die Synchronisation nebenl¨aufiger Berechnungen, sowie Module h¨oherer Ordnung, welche die Sprache um wichtige Abstraktionsm¨oglichkeiten erg¨anzen. Die meisten dieser Konstrukte sind bekannt und f¨ur sich gut verstanden, aber bisher nicht in dieser Form und zu diesem Zweck in einem koh¨arenten Design integriert worden. Neu ist ausserdem das zentrale Konzept von Paketen (packages), welches das Kernproblem der dy- namischen Typisierung l¨ost. Es ¨ahnelt der Idee von Dynamics, jedoch werden nicht einzelne Werte, sondern komplette Module eingebettet. Die feink¨ornige Typunterscheidung weicht so einem strukturellen Inklusionstest auf Modulschnittstellen, der robust gegen¨uber Erweiterun- gen ist und eine Handhabung auf hohem Abstraktionsgrad erlaubt. Auf Grundlage dieser Ba- siskonzepte definiert die Sprache einen flexiblen, typsicheren Begriff von Komponenten, der nicht nur bedarfsgetriebenes dynamisches Laden erm¨oglicht, sondern Komponenten als Werte erster Klasse verf¨ugbar macht, die dynamisch berechnet und aus einem Prozess exportiert werden k¨onnen. Mit Hilfe dieser Idee wiederum ist ein vergleichsweise einfacher aber expressiver Ansatz f¨ur verteilte Programmierung m¨oglich, bei dem Verbindungen zwischen Prozessen durch den initialen Austausch einer dynamisch berechneten Komponente aufgebaut werden. Das Konzept von programmierbaren Komponentenmanagern erlaubt es dem Empf¨angerprozess dabei, gezielte Sicherheitsstrategien durch Einschr¨ankung der Importrechte f¨ur die empfangene Komponente zu realisieren. Eine nahezu vollst¨andige Implementation von Alice ML wurde realisiert und steht als offene Software zur Verf¨ugung. Zum anderen entwickeln wir einen theoretischen Ansatz zur Modellierung von Typabstrak- tion, der Abstraktionssicherheit auch in Gegenwart dynamischer Typinspektion sicherstellt. Zu diesem Zweck f¨uhren wir eine idealisierte Formalisierung der Sprache Alice ML ein, die auf dem polymorphen λ-Kalk¨ul basiert. Sie modelliert zentrale Konzepte des Typ- und Modulsys- tems: h¨oherstufige Typen spiegeln Polymorphismus und parametrisierte Module wider, Singleton Kinds k¨onnen
Recommended publications
  • Types and Programming Languages by Benjamin C
    < Free Open Study > . .Types and Programming Languages by Benjamin C. Pierce ISBN:0262162091 The MIT Press © 2002 (623 pages) This thorough type-systems reference examines theory, pragmatics, implementation, and more Table of Contents Types and Programming Languages Preface Chapter 1 - Introduction Chapter 2 - Mathematical Preliminaries Part I - Untyped Systems Chapter 3 - Untyped Arithmetic Expressions Chapter 4 - An ML Implementation of Arithmetic Expressions Chapter 5 - The Untyped Lambda-Calculus Chapter 6 - Nameless Representation of Terms Chapter 7 - An ML Implementation of the Lambda-Calculus Part II - Simple Types Chapter 8 - Typed Arithmetic Expressions Chapter 9 - Simply Typed Lambda-Calculus Chapter 10 - An ML Implementation of Simple Types Chapter 11 - Simple Extensions Chapter 12 - Normalization Chapter 13 - References Chapter 14 - Exceptions Part III - Subtyping Chapter 15 - Subtyping Chapter 16 - Metatheory of Subtyping Chapter 17 - An ML Implementation of Subtyping Chapter 18 - Case Study: Imperative Objects Chapter 19 - Case Study: Featherweight Java Part IV - Recursive Types Chapter 20 - Recursive Types Chapter 21 - Metatheory of Recursive Types Part V - Polymorphism Chapter 22 - Type Reconstruction Chapter 23 - Universal Types Chapter 24 - Existential Types Chapter 25 - An ML Implementation of System F Chapter 26 - Bounded Quantification Chapter 27 - Case Study: Imperative Objects, Redux Chapter 28 - Metatheory of Bounded Quantification Part VI - Higher-Order Systems Chapter 29 - Type Operators and Kinding Chapter 30 - Higher-Order Polymorphism Chapter 31 - Higher-Order Subtyping Chapter 32 - Case Study: Purely Functional Objects Part VII - Appendices Appendix A - Solutions to Selected Exercises Appendix B - Notational Conventions References Index List of Figures < Free Open Study > < Free Open Study > Back Cover A type system is a syntactic method for automatically checking the absence of certain erroneous behaviors by classifying program phrases according to the kinds of values they compute.
    [Show full text]
  • Language-Level Support for Exploratory Programming of Distributed Virtual Environments
    In Proc ACM UIST ‘96 (Symp. on User Interface Software and Technology), Seattle, WA, November 6–8, 1996, pp. 83–94. Language-Level Support for Exploratory Programming of Distributed Virtual Environments Blair MacIntyre and Steven Feiner Department of Computer Science, Columbia University, New York, NY, 10027 {bm,feiner}@cs.columbia.edu http://www.cs.columbia.edu/~{bm,feiner} Abstract resulted in an unmanageable welter of client-server relation- ships, with each of a dozen or more processes needing to We describe COTERIE, a toolkit that provides language- create and maintain explicit connections to each other and to level support for building distributed virtual environments. handle inevitable crashes. COTERIE is based on the distributed data-object paradigm for distributed shared memory. Any data object in COTE- We spent a sufficiently large portion of our time reengineer- RIE can be declared to be a Shared Object that is replicated ing client-server code that it became clear to us that our fully in any process that is interested in it. These Shared implementation of the client-server model was unsuitable Objects support asynchronous data propagation with atomic for exploratory programming of distributed research proto- serializable updates, and asynchronous notification of types. The heart of the problem, as we saw it, was a lack of updates. COTERIE is built in Modula-3 and uses existing support for data sharing that was both efficient and easy for Modula-3 packages that support an integrated interpreted programmers to use in the face of frequent and unantici- language, multithreading, and 3D animation. Unlike other pated changes.
    [Show full text]
  • A Nominal Theory of Objects with Dependent Types
    A Nominal Theory of Objects with Dependent Types Martin Odersky, Vincent Cremet, Christine R¨ockl, Matthias Zenger Ecole´ Polytechnique F´ed´eralede Lausanne INR Ecublens 1015 Lausanne, Switzerland Technical Report IC/2002/070 Abstract Simula 67 [DMN70], whereas virtual or abstract types are present in BETA [MMPN93], as well as more recently in We design and study νObj, a calculus and dependent type gbeta [Ern99], Rune [Tor02] and Scala [Ode02]. An es- system for objects and classes which can have types as mem- sential ingredient of these systems are objects with type bers. Type members can be aliases, abstract types, or new members. There is currently much work that explores types. The type system can model the essential concepts the uses of this concept in object-oriented programming of Java’s inner classes as well as virtual types and family [SB98, TT99, Ern01, Ost02]. But its type theoretic foun- polymorphism found in BETA or gbeta. It can also model dations are just beginning to be investigated. most concepts of SML-style module systems, including shar- As is the case for modules, dependent types are a promis- ing constraints and higher-order functors, but excluding ap- ing candidate for a foundation of objects with type mem- plicative functors. The type system can thus be used as a bers. Dependent products can be used to represent functors basis for unifying concepts that so far existed in parallel in in SML module systems as well as classes in object sys- advanced object systems and in module systems. The paper tems with virtual types [IP02].
    [Show full text]
  • Composable Concurrency Models
    Composable Concurrency Models Dan Stelljes Division of Science and Mathematics University of Minnesota, Morris Morris, Minnesota, USA 56267 [email protected] ABSTRACT Given that an application is likely to make use of more The need to manage concurrent operations in applications than one concurrency model, programmers would prefer that has led to the development of a variety of concurrency mod- different types of models could safely interact. However, dif- els. Modern programming languages generally provide sev- ferent models do not necessarily work well together, nor are eral concurrency models to serve different requirements, and they designed to. Recent work has attempted to identify programmers benefit from being able to use them in tandem. common \building blocks" that could be used to compose We discuss challenges surrounding concurrent programming a variety of models, possibly eliminating subtle problems and examine situations in which conflicts between models when different models interact and allowing models to be can occur. Additionally, we describe attempts to identify represented at lower levels without resorting to rough ap- features of common concurrency models and develop lower- proximations [9, 11, 12]. level abstractions capable of supporting a variety of models. 2. BACKGROUND 1. INTRODUCTION In a concurrent program, the history of operations may Most interactive computer programs depend on concur- not be the same for every execution. An entirely sequen- rency, the ability to perform different tasks at the same tial program could be proved to be correct by showing that time. A web browser, for instance, might at any point be its history (that is, the sequence in which its operations are rendering documents in multiple tabs, transferring files, and performed) always yields a correct result.
    [Show full text]
  • Reactive Async: Expressive Deterministic Concurrency
    Reactive Async: Expressive Deterministic Concurrency Philipp Haller Simon Geries Michael Eichberg Guido Salvaneschi KTH Royal Institute of Technology, Sweden TU Darmstadt, Germany [email protected] feichberg, [email protected] Abstract tion can generate non-deterministic results because of their Concurrent programming is infamous for its difficulty. An unpredictable scheduling. Traditionally, developers address important source of difficulty is non-determinism, stemming these problems by protecting state from concurrent access from unpredictable interleavings of concurrent activities. via synchronisation. Yet, concurrent programming remains Futures and promises are widely-used abstractions that help an art: insufficient synchronisation leads to unsound pro- designing deterministic concurrent programs, although this grams but synchronising too much does not exploit hardware property cannot be guaranteed statically in mainstream pro- capabilities effectively for parallel execution. gramming languages. Deterministic-by-construction con- Over the years researchers have proposed concurrency current programming models avoid this issue, but they typi- models that attempt to overcome these issues. For exam- cally restrict expressiveness in important ways. ple the actor model [13] encapsulates state into actors This paper introduces a concurrent programming model, which communicate via asynchronous messages–a solution Reactive Async, which decouples concurrent computations that avoids shared state and hence (low-level) race condi- using
    [Show full text]
  • A Reduction Semantics for Direct-Style Asynchronous Observables
    Journal of Logical and Algebraic Methods in Programming 105 (2019) 75–111 Contents lists available at ScienceDirect Journal of Logical and Algebraic Methods in Programming www.elsevier.com/locate/jlamp A reduction semantics for direct-style asynchronous observables ∗ Philipp Haller a, , Heather Miller b a KTH Royal Institute of Technology, Sweden b Carnegie Mellon University, USA a r t i c l e i n f o a b s t r a c t Article history: Asynchronous programming has gained in importance, not only due to hardware develop- Received 31 January 2016 ments like multi-core processors, but also due to pervasive asynchronicity in client-side Received in revised form 6 March 2019 Web programming and large-scale Web applications. However, asynchronous program- Accepted 6 March 2019 ming is challenging. For example, control-flow management and error handling are much Available online 18 March 2019 more complex in an asynchronous than a synchronous context. Programming with asyn- chronous event streams is especially difficult: expressing asynchronous stream producers and consumers requires explicit state machines in continuation-passing style when using widely-used languages like Java. In order to address this challenge, recent language designs like Google’s Dart introduce asynchronous generators which allow expressing complex asynchronous programs in a familiar blocking style while using efficient non-blocking concurrency control under the hood. However, several issues remain unresolved, including the integration of analogous constructs into statically-typed languages, and the formalization and proof of important correctness properties. This paper presents a design for asynchronous stream generators for Scala, thereby ex- tending previous facilities for asynchronous programming in Scala from tasks/futures to asynchronous streams.
    [Show full text]
  • Obliq, a Language with Distributed Scope
    Obliq A Language with Distributed Scope Luca Cardelli June 3, 1994 © Digital Equipment Corporation 1994 This work may not be copied or reproduced in whole or in part for any commercial purpose. Permis- sion to copy in whole or in part without payment of fee is granted for nonprofit educational and re- search purposes provided that all such whole or partial copies include the following: a notice that such copying is by permission of the Systems Research Center of Digital Equipment Corporation in Palo Alto, California; an acknowledgment of the authors and individual contributors to the work; and all applicable portions of the copyright notice. Copying, reproducing, or republishing for any other pur- pose shall require a license with payment of fee to the Systems Research Center. All rights reserved. Abstract Obliq is a lexically-scoped untyped interpreted language that supports distributed object-oriented computation. An Obliq computation may involve multiple threads of control within an address space, multiple address spaces on a machine, heterogeneous machines over a local network, and multiple net- works over the Internet. Obliq objects have state and are local to a site. Obliq computations can roam over the network, while maintaining network connections. Contents 1. Introduction ................................................................................................................................. 1 1.1 Language Overview ............................................................................................................
    [Show full text]
  • The Power of Interoperability: Why Objects Are Inevitable
    The Power of Interoperability: Why Objects Are Inevitable Jonathan Aldrich Carnegie Mellon University Pittsburgh, PA, USA [email protected] Abstract 1. Introduction Three years ago in this venue, Cook argued that in Object-oriented programming has been highly suc- their essence, objects are what Reynolds called proce- cessful in practice, and has arguably become the dom- dural data structures. His observation raises a natural inant programming paradigm for writing applications question: if procedural data structures are the essence software in industry. This success can be documented of objects, has this contributed to the empirical success in many ways. For example, of the top ten program- of objects, and if so, how? ming languages at the LangPop.com index, six are pri- This essay attempts to answer that question. After marily object-oriented, and an additional two (PHP reviewing Cook’s definition, I propose the term ser- and Perl) have object-oriented features.1 The equiva- vice abstractions to capture the essential nature of ob- lent numbers for the top ten languages in the TIOBE in- jects. This terminology emphasizes, following Kay, that dex are six and three.2 SourceForge’s most popular lan- objects are not primarily about representing and ma- guages are Java and C++;3 GitHub’s are JavaScript and nipulating data, but are more about providing ser- Ruby.4 Furthermore, objects’ influence is not limited vices in support of higher-level goals. Using examples to object-oriented languages; Cook [8] argues that Mi- taken from object-oriented frameworks, I illustrate the crosoft’s Component Object Model (COM), which has unique design leverage that service abstractions pro- a C language interface, is “one of the most pure object- vide: the ability to define abstractions that can be ex- oriented programming models yet defined.” Academ- tended, and whose extensions are interoperable in a ically, object-oriented programming is a primary focus first-class way.
    [Show full text]
  • Abstract Class Name Declaration
    Abstract Class Name Declaration Augustin often sallies sometime when gramophonic Regan denominating granularly and tessellates her zetas. Hanson pleasure her mujiks indifferently, she refining it deafeningly. Crumbiest Jo retrogresses some suspicion after chalcographical Georgia besprinkling downright. Abstract methods and other class that exist in abstract class name declaration, we should be the application using its variables Images are still loading. Java constructor declarations are not members. Not all fields need individual field accessors and mutators. Only elements that are listed as class members contribute to date type definition of a class. When you subclass an abstract class, improve service, etc. Be careful while extending above abstract class, with to little hitch. Abstract classes still in virtual tables, an abstract method is a method definition without braces and followed by a semicolon. Error while getting part list from Facebook! What makes this especially absurd is data most HTML classes are used purely to help us apply presentation with CSS. The separation of interface and implementation enables better software design, it all also supply useful to define constraint mechanisms to be used in expressions, an abstract class may contain implementation details for its members. Understanding which class will be bid for handling a message can illuminate complex when dealing with white than one superclass. How to compute the area if the dust is have known? If you nice a named widget pool, each subclass needs to know equity own table name, that any node can be considered a barn of work queue of linked elements. In only of a Java constructor data members are initialized.
    [Show full text]
  • Abstract Class Function Declaration Typescript
    Abstract Class Function Declaration Typescript Daniel remains well-established after Vale quote anemographically or singe any fortitude. Nigel never fightings Quintusany salpiglossis gone almost skitters floatingly, uncommendably, though Kristian is Nathanael rip-off his stout stotter and hunches. lived enough? Warped and sycophantish Also typescript abstract keyword within a method declaration declares an abstract class without specifying its classes. The typescript has only operate on structural typing appears. Methods in the classes are always defined. Working with JET Elements JET Elements are exported as Typescript interfaces. Example of implementing interface by abstract class the structure provided between their interface typescript abstract interface abstract. This allows you love, for all, implement the Singleton pattern where mercury one copy of an object anywhere be created at finish time. Interfaces can define a type variable declaration declares one value of other similar syntax. In ts provides names for every method declaration in typescript and whatnot in java and congratulations for this? Making thereby a typed language you need so expect until it makes more limitations on the code you write that help turkey avoid any bugs or errors at runtime. This project with class that handle your function abstract class we see, we are a method with classes! What country it together for a Linux distribution to house stable and how much dilute it matter other casual users? It simply visit that at compilation the typescript compiler will get separate type declarations into either single definition. Factory method declaration declares one and functionality has nobody means a common, start appearing now! Although we are obsolete instead of an instance of what you pass properties and be used to know that can access modifier they are abstract type? For function declarations with your post, declaration declares one you! Check out to declaration declares an abstract functionality errors at this function declarations can freely accessible module and there will.
    [Show full text]
  • Abstract Interface Behavior of an Object-Oriented Language with Futures and Promises
    Abstract interface behavior of an object-oriented language with futures and promises 3. September 2007 Erika Abrah´ am´ 1, and Immo Grabe2, and Andreas Gruner¨ 2, and Martin Steffen3 1 Albert-Ludwigs-University Freiburg, Germany 2 Christian-Albrechts-University Kiel, Germany 3 University of Oslo, Norway 1 Motivation How to marry concurrency and object-orientation has been a long-standing issue; see e.g., [2] for an early discussion of different design choices. Recently, the thread-based model of concurrency, prominently represented by languages like Java and C# has been criticized, especially in the context of component-based software development. As the word indicates, components are (software) artifacts intended for composition, i.e., open systems, interacting with a surrounding environment. To compare different concurrency models on a solid mathematical basis, a semantical description of the interface behavior is needed, and this is what we do in this work. We present an open semantics for a core of the Creol language [4,7], an object-oriented, concurrent language, featuring in particular asynchronous method calls and (since recently [5]) future-based concurrency. Futures and promises A future, very generally, represents a result yet to be computed. It acts as a proxy for, or reference to, the delayed result from a given sequential piece of code (e.g., a method or a function body in an object-oriented, resp. a functional setting). As the client of the delayed result can proceed its own execution until it actually needs the result, futures provide a natural, lightweight, and (in a functional setting) transparent mechanism to introduce parallelism into a language.
    [Show full text]
  • N4244: Resumable Lambdas
    Document Number: N4244 Date: 2014-10-13 Reply To Christopher Kohlhoff <[email protected]> Resumable Lambdas: A language extension for generators and coroutines 1 Introduction N3977 Resumable Functions and successor describe a language extension for resumable functions, or “stackless” coroutines. The earlier revision, N3858, states that the motivation is: [...] the increasing importance of efficiently handling I/O in its various forms and the complexities programmers are faced with using existing language features and existing libraries. In contrast to “stackful” coroutines, a prime use case for stackless coroutines is in server applications that handle many thousands or millions of clients. This is due to stackless coroutines having lower memory requirements than stackful coroutines, as the latter, like true threads, must have a reserved stack space. Memory cost per byte is dropping over time, but with server applications at this scale, per-machine costs, such as hardware, rack space, network connectivity and administration, are significant. For a given request volume, it is always cheaper if the application can be run on fewer machines. Existing best practice for stackless coroutines in C and C++ uses macros and a switch-based technique similar to Duff’s Device. Examples include the coroutine class included in Boost.Asio1, and Protothreads2. Simon Tatham’s web page3, Coroutines in C, inspired both of these implementations. A typical coroutine using this model looks like this: void operator()(error_code ec, size_t n) { if (!ec) reenter (this) { for (;;) { yield socket_->async_read_some(buffer(*data_), *this); yield async_write(*socket_, buffer(*data_, n), *this); } } } The memory overhead of a stackless coroutine can be as low as a single int.
    [Show full text]