DOCSLIB.ORG

Context-Aware Programming Languages

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Context-Aware Programming Languages UCAM-CL-TR-906 Technical Report ISSN 1476-2986 Number 906 Computer Laboratory Context-aware programming languages Tomas Petricek March 2017 15 JJ Thomson Avenue Cambridge CB3 0FD United Kingdom phone +44 1223 763500 http://www.cl.cam.ac.uk/ c 2017 Tomas Petricek This technical report is based on a dissertation submitted March 2017 by the author for the degree of Doctor of Philosophy to the University of Cambridge, Clare Hall. Technical reports published by the University of Cambridge Computer Laboratory are freely available via the Internet: http://www.cl.cam.ac.uk/techreports/ ISSN 1476-2986 ABSTRACT The development of programming languages needs to reflect important changes in the way programs execute. In recent years, this has included the development of parallel programming models (in reaction to the multi- core revolution) or improvements in data access technologies. This thesis is a response to another such revolution – the diversification of devices and systems where programs run. The key point made by this thesis is the realization that an execution en- vironment or a context is fundamental for writing modern applications and that programming languages should provide abstractions for programming with context and verifying how it is accessed. We identify a number of program properties that were not connected before, but model some notion of context. Our examples include tracking different execution platforms (and their versions) in cross-platform devel- opment, resources available in different execution environments (e. g. GPS sensor on a phone and database on the server), but also more traditional notions such as variable usage (e. g. in liveness analysis and linear logics) or past values in stream-based dataflow programming. Our first contribution is the discovery of the connection between the above examples and their novel presentation in the form of calculi (coeffect systems). The presented type systems and formal semantics highlight the relationship between dif- ferent notions of context. Our second contribution is the definition of two unified coeffect calculi that capture the common structure of the examples. In particular, our flat co- effect calculus models languages with contextual properties of the execution environment and our structural coeffect calculus models languages where the contextual properties are attached to the variable usage. We define the se- mantics of the calculi in terms of category theoretical structure of an indexed comonad (based on dualisation of the well-known monad structure), use it to define operational semantics and prove type safety of the calculi. Our third contribution is a novel presentation of our work in the form of web-based interactive essay. This provides a simple implementation of three context-aware programming languages and lets the reader write and run simple context-aware programs, but also explore the theory behind the implementation including the typing derivation and semantics. 3 ACKNOWLEDGEMENTS Thanks to: ALAN MYCROFT HDNORAAMPMM TARMO UUSTALU AOARDELIEYY DAN GHICA LMTNAOARTCO JEREMY GIBBONS LIOAIONORRR MARCELO FIORE GNWLREUSIOC DOMINIC ORCHARD IIFIGMLLCFH DON SYME SCUECHOAKTA RAOUL GABRIEL URMA TMASLLIVOER STEPHEN KELL EEPBELACVPD ANTRANIG BASMAN PGEEMPERARO SAM AARON HITTYLPKEIL LIESBETH DE MOL ENRHSESEUME GIUSEPPE PRIMIERO NAIYZINNLIC CLARE HALL ERCMYROAAER MATFYZ RTEEFBBMTRA DANIELA PETRICKOVA ONKRTABSSOM MIROSLAV PETRICEK IAVEAGIAUER FLIJMNGBUAU And most importantly: ............. CONTENTS i context-aware programming 11 1 why context-aware programming matters 13 1.1 Why context-aware programming matters . 14 1.1.1 Context awareness #1: Platform versioning . 15 1.1.2 Context awareness #2: System capabilities . 16 1.1.3 Context awareness #3: Confidentiality and provenance 17 1.1.4 Context-awareness #4: Checking array access patterns 17 1.2 Towards context-aware languages . 18 1.2.1 Context-aware languages in action . 19 1.2.2 Understanding context with types . 19 1.3 Theory of context dependence . 21 1.4 Thesis outline . 23 2 pathways to coeffects 25 2.1 Coeffects via static and dynamic binding . 25 2.1.1 Variable binding . 25 2.1.2 Implicit parameter binding . 26 2.1.3 Resolving ambiguity . 27 2.2 Coeffects via type and effect systems . 29 2.2.1 Simple effect system. 29 2.2.2 Simple coeffect system. 30 2.3 Coeffects via language semantics . 30 2.3.1 Effectful languages and meta-languages . 31 2.3.2 Marriage of effects and monads . 33 2.3.3 Context-dependent languages and meta-languages . 33 2.4 Coeffects via substructural and bunched logics . 37 2.4.1 Substructural type systems. 37 2.4.2 Bunched type systems. 38 2.5 Context oriented programming . 39 2.6 Summary . 39 3 context-aware systems 41 3.1 Structure of coeffect systems . 41 3.1.1 Effectful lambda abstraction . 42 3.1.2 Notions of context . 42 3.1.3 Scalars and vectors . 44 3.2 Flat coeffect systems . 45 3.2.1 Implicit parameters and type classes . 45 3.2.2 Distributed computing . 50 3.2.3 Liveness analysis . 53 3.2.4 Dataflow languages . 58 3.2.5 Permissions and safe locking . 63 3.3 Structural coeffect systems . 64 3.3.1 Liveness analysis revisited . 64 3.3.2 Bounded variable use . 69 3.3.3 Dataflow languages revisited . 72 3.3.4 Security, tainting and provenance . 75 3.4 Beyond passive contexts . 76 3.5 Summary . 78 7 8 contents ii coeffect calculi 79 4 types for flat coeffect calculus 83 4.1 Introduction . 83 4.1.1 A unified treatment of lambda abstraction . 84 4.2 Flat coeffect calculus . 84 4.2.1 Flat coeffect algebra . 85 4.2.2 Type system . 87 4.2.3 Understanding flat coeffects . 87 4.2.4 Examples of flat coeffects . 88 4.3 Choosing a unique typing . 90 4.3.1 Implicit parameters . 90 4.3.2 Dataflow and liveness . 93 4.4 Syntactic equational theory . 94 4.4.1 Syntactic properties . 94 4.4.2 Call-by-value evaluation . 95 4.4.3 Call-by-name evaluation . 97 4.5 Syntactic properties and extensions . 100 4.5.1 Subcoeffecting and subtyping . 100 4.5.2 Typing of let binding . 101 4.5.3 Properties of lambda abstraction . 102 4.5.4 Language with pairs and unit . 103 4.6 Summary . 104 5 semantics of flat coeffect calculus 105 5.1 Introduction and safety . 106 5.2 Categorical motivation . 107 5.2.1 Comonads are to coeffects what monads are to effects 107 5.2.2 Categorical semantics . 107 5.2.3 Introducing comonads . 108 5.2.4 Generalising to indexed comonads . 109 5.2.5 Flat indexed comonads . 111 5.2.6 Semantics of flat calculus . 114 5.3 Translational semantics . 116 5.3.1 Functional target language . 117 5.3.2 Safety of functional target language . 117 5.3.3 Comonadically-inspired translation . 119 5.4 Safety of context-aware languages . 121 5.4.1 Coeffect language for dataflow . 122 5.4.2 Coeffect language for implicit parameters . 124 5.5 Generalized safety of comonadic embedding . 128 5.6 Related categorical structures . 130 5.6.1 Indexed categorical structures . 131 5.6.2 When is a coeffect not a monad . 131 5.6.3 When is coeffect a monad . 132 5.7 Summary . 134 6 structural coeffect calculus 135 6.1 Introduction . 136 6.1.1 Related work . 136 6.2 Structural coeffect calculus . 136 6.2.1 Structural coeffect algebra . 137 6.2.2 Structural coeffect types . 138 6.2.3 Understanding structural coeffects . 140 6.2.4 Examples of structural coeffects . 140 6.3 Choosing a unique typing . 141 contents 9 6.3.1 Syntax-directed type system . 141 6.3.2 Properties . 143 6.4 Syntactic properties and extensions . 144 6.4.1 Let binding . 144 6.4.2 Subcoeffecting . 145 6.5 Syntactic equational theory . 145 6.5.1 From flat coeffects to structural coeffects . 146 6.5.2 Holes and substitution lemma . 147 6.5.3 Reduction and expansion . 148 6.6 Categorical motivation . 153 6.6.1 Indexed comonads, revisited . 153 6.6.2 Structural indexed comonads . 154 6.6.3 Semantics of structural calculus . 154 6.6.4 Examples of structural indexed comonads . 157 6.7 Translational semantics . 160 6.7.1 Comonadically-inspired language extensions . 160 6.7.2 Comonadically-inspired translation . 161 6.7.3 Structural coeffect language for dataflow . 163 6.8 Summary . 166 iii towards practical coeffects 169 7 implementation 171 7.1 From theory to implementation . 172 7.1.1 Type checking and inference . 172 7.1.2 Execution of context-aware programs . 173 7.1.3 Supporting additional context-aware languages . 174 7.2 Case studies . 174 7.2.1 Typing context-aware programs . 175 7.2.2 Comonadically-inspired translation . 175 7.3 Interactive essay . 177 7.3.1 Explorable language implementation . 178 7.3.2 Implementation overview . 180 7.4 Related work . 181 7.5 Summary . 182 8 unified coeffect systems 183 8.1 The unified coeffect calculus . 183 8.1.1 Shapes and containers . 184 8.1.2 Structure of coeffects . 185 8.1.3 Unified coeffect type system . 187 8.1.4 Structural coeffects . 189 8.1.5 Flat coeffects . 190 8.2 Coeffect meta-language . 192 8.2.1 Coeffects and contextual modal type theory . 192 8.2.2 Coeffect meta-language . 193 8.2.3 Embedding flat coeffect calculus . 195 8.3 Related and future work . 195 8.3.1 Embedded context-aware DSLs . 195 8.3.2 Extending the theory of coeffects . 197 8.4 Summary . ..
Load more

Recommended publications
  • Typescript Language Specification
    TypeScript Language Specification Version 1.8 January, 2016 Microsoft is making this Specification available under the Open Web Foundation Final Specification Agreement Version 1.0 ("OWF 1.0") as of October 1, 2012. The OWF 1.0 is available at http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0. TypeScript is a trademark of Microsoft Corporation. Table of Contents 1 Introduction ................................................................................................................................................................................... 1 1.1 Ambient Declarations ..................................................................................................................................................... 3 1.2 Function Types .................................................................................................................................................................. 3 1.3 Object Types ...................................................................................................................................................................... 4 1.4 Structural Subtyping ....................................................................................................................................................... 6 1.5 Contextual Typing ............................................................................................................................................................ 7 1.6 Classes .................................................................................................................................................................................
    [Show full text]
  • Typescript-Handbook.Pdf
    This copy of the TypeScript handbook was created on Monday, September 27, 2021 against commit 519269 with TypeScript 4.4. Table of Contents The TypeScript Handbook Your first step to learn TypeScript The Basics Step one in learning TypeScript: The basic types. Everyday Types The language primitives. Understand how TypeScript uses JavaScript knowledge Narrowing to reduce the amount of type syntax in your projects. More on Functions Learn about how Functions work in TypeScript. How TypeScript describes the shapes of JavaScript Object Types objects. An overview of the ways in which you can create more Creating Types from Types types from existing types. Generics Types which take parameters Keyof Type Operator Using the keyof operator in type contexts. Typeof Type Operator Using the typeof operator in type contexts. Indexed Access Types Using Type['a'] syntax to access a subset of a type. Create types which act like if statements in the type Conditional Types system. Mapped Types Generating types by re-using an existing type. Generating mapping types which change properties via Template Literal Types template literal strings. Classes How classes work in TypeScript How JavaScript handles communicating across file Modules boundaries. The TypeScript Handbook About this Handbook Over 20 years after its introduction to the programming community, JavaScript is now one of the most widespread cross-platform languages ever created. Starting as a small scripting language for adding trivial interactivity to webpages, JavaScript has grown to be a language of choice for both frontend and backend applications of every size. While the size, scope, and complexity of programs written in JavaScript has grown exponentially, the ability of the JavaScript language to express the relationships between different units of code has not.
    [Show full text]
  • Comparative Studies of Programming Languages; Course Lecture Notes
    Comparative Studies of Programming Languages, COMP6411 Lecture Notes, Revision 1.9 Joey Paquet Serguei A. Mokhov (Eds.) August 5, 2010 arXiv:1007.2123v6 [cs.PL] 4 Aug 2010 2 Preface Lecture notes for the Comparative Studies of Programming Languages course, COMP6411, taught at the Department of Computer Science and Software Engineering, Faculty of Engineering and Computer Science, Concordia University, Montreal, QC, Canada. These notes include a compiled book of primarily related articles from the Wikipedia, the Free Encyclopedia [24], as well as Comparative Programming Languages book [7] and other resources, including our own. The original notes were compiled by Dr. Paquet [14] 3 4 Contents 1 Brief History and Genealogy of Programming Languages 7 1.1 Introduction . 7 1.1.1 Subreferences . 7 1.2 History . 7 1.2.1 Pre-computer era . 7 1.2.2 Subreferences . 8 1.2.3 Early computer era . 8 1.2.4 Subreferences . 8 1.2.5 Modern/Structured programming languages . 9 1.3 References . 19 2 Programming Paradigms 21 2.1 Introduction . 21 2.2 History . 21 2.2.1 Low-level: binary, assembly . 21 2.2.2 Procedural programming . 22 2.2.3 Object-oriented programming . 23 2.2.4 Declarative programming . 27 3 Program Evaluation 33 3.1 Program analysis and translation phases . 33 3.1.1 Front end . 33 3.1.2 Back end . 34 3.2 Compilation vs. interpretation . 34 3.2.1 Compilation . 34 3.2.2 Interpretation . 36 3.2.3 Subreferences . 37 3.3 Type System . 38 3.3.1 Type checking . 38 3.4 Memory management .
    [Show full text]
  • Semantic Casts Contracts and Structural Subtyping in a Nominal World
    Semantic Casts Contracts and Structural Subtyping in a Nominal World Robert Bruce Findler, Matthew Flatt, and Matthias Felleisen 1 University of Chicago; Chicago, IL, USA; [email protected] 2 University of Utah; Salt Lake City, UT, USA; [email protected] 3 Northeastern University; Boston, MA, USA; [email protected] Abstract Nominal subtyping forces programmers to explicitly state all of the subtyping re- lationships in the program. This limits component reuse, because programmers cannot anticipate all of the contexts in which a particular class might be used. In contrast, structural subtyping implicitly allows any type with appropriate structure to be used in a given context. Languagues with contracts exacerbate the problem. Since contracts are typically expressed as refinements of types, contracts in nominally typed languages introduce additional obstacles to reuse. To overcome this problem we show how to extend a nominally typed language with semantic casts that introduce a limited form of structural subtyping. The new language must dynamically monitor contracts, as new subtyping relationships are exploited via semantic casts. In addition, it must also track the casts to properly assign blame in case interface contract are violated. 1 Enriching Nominal Subtypes with Semantic Casts Conventional class-based object-oriented languages like C++ [45], C# [34], Eiffel [33], and Java [18] come with nominal typing systems. In such systems, a programmer ex- plicitly names the superclass(es) and the implemented interfaces of a class. Thus, the declared type of any instance of a class must be one of the explicitly named interfaces or classes. Language designers choose nominal type systems because they are easy to under- stand and easy to implement.
    [Show full text]
  • 03 a Pril , 2011 S Aarbrücken , G Ermany
    E UROPEAN J OINT C ONFERENCES ON T HEORY AND P RACTICE OF S OFTWARE 26 M ARCH – 03 A PRIL , 2011 S AARBRÜCKEN , G ERMANY BYTECODE 2011 6 TH W ORKSHOP ON BYTECODE S EMANTICS , V ERIFICATION , A NALYSIS AND T RANSFORMATION P IERRE G ANTY AND M ARK M ARRON (E DS .) http://www.etaps.org http://etaps2011.cs.uni-saarland.de ByteCode 2011 Complete and Platform-Independent Calling Context Profiling for the Java Virtual Machine Aibek Sarimbekov Philippe Moret Walter Binder1 Faculty of Informatics University of Lugano Lugano, Switzerland Andreas Sewe Mira Mezini2 Software Technology Group Technische Universit¨atDarmstadt Darmstadt, Germany Abstract Calling context profiling collects statistics separately for each calling context. Complete calling con- text profiles that faithfully represent overall program execution are important for a sound analysis of program behavior, which in turn is important for program understanding, reverse engineering, and workload characterization. Many existing calling context profilers for Java rely on sampling or on incomplete instrumentation techniques, yielding incomplete profiles; others rely on Java Virtual Machine (JVM) modifications or work only with one specific JVM, thus compromising portability. In this paper we present a new calling context profiler for Java that reconciles completeness of the collected profiles and full compatibility with any standard JVM. In order to reduce measurement perturbation, our profiler collects platform-independent dynamic metrics, such as the number of method invocations and the number of executed bytecodes. In contrast to prevailing calling con- text profilers, our tool is able to distinguish between multiple call sites in a method and supports selective profiling of (the dynamic extent of) certain methods.
    [Show full text]
  • Concrete Types for Typescript
    Concrete Types for TypeScript Abstract preservation in favor of improved error reporting. The pragmatic TypeScript extends the JavaScript programming language with a justification for optional types is that developers should have con- set of optional type annotations that are, by design, unsound and, fidence that adding type annotation to a well-tested dynamic pro- that the TypeScript compiler discards as it emits plain JavaScript gram will neither cause the program to get stuck nor degrade its code. The motivation for this choice is to preserve the programming performance. idioms developers are familiar with, and their legacy code, while This paper presents a design for a gradual type system for Type- offering them a measure of static error checking. This paper details Script that lets developers choose between writing code that has no an alternative design for TypeScript, one where it is possible to type annotations (implicitly variables are of type any), with op- support the same degree of dynamism, but also where types can tional type annotations that are trace-preserving (types are erased), be strengthened to provide runtime guarantees. We report on an and finally with concrete type annotations that provide correct- implementation of our design, called StrongScript, that improves ness guarantees but are not trace-preserving (types are retained and runtime performance of typed programs when run on an optimizing are used by the compiler). We name the language StrongScript in JavaScript engine. homage to StrongTalk. Its type system is inspired by ideas devel- oped in Thorn [2] but terminology and syntax are aligned to Type- Script. Our design goals were as follows: 1.
    [Show full text]
  • Gradual Typing for Smalltalk
    Gradual Typing for Smalltalk Esteban Allendea,∗∗, Oscar Calla´ua, Johan Fabrya, Eric´ Tantera, Marcus Denkerb aPLEIAD Laboratory Computer Science Department (DCC) | University of Chile bINRIA Lille Nord Europe CNRS UMR 8022 | University of Lille Abstract Being able to combine static and dynamic typing within the same language has clear benefits in order to support the evolution of prototypes or scripts into mature robust programs. While being an emblematic dynamic object-oriented language, Smalltalk is lagging behind in this regard. We report on the design, implementation and application of Gradualtalk, a gradually-typed Smalltalk meant to enable incremental typing of existing programs. The main design goal of the type system is to support the features of the Smalltalk language, like metaclasses and blocks, live programming, and to accomodate the programming idioms used in practice. We studied a number of existing projects in order to determine the features to include in the type system. As a result, Gradualtalk is a practical approach to gradual types in Smalltalk, with a novel blend of type system features that accomodate most programming idioms. Keywords: Type systems, gradual typing, Smalltalk 1. Introduction The popularity of dynamic languages has led programs in these languages to become larger and more com- plex. A number of frameworks like Ruby on Rails, the Google Javascript library suite, Seaside (Smalltalk), Django (Python), etc. are regularly used to build large and complex systems. In this context, the possibility to consolidate grown prototypes or scripts with the guarantees of a static type system is appealing. While research in combining static and dynamic typing started more than twenty years ago, recent years have seen a lot of proposals of either static type systems for dynamic languages, or partial type systems that allow a combination of both approaches [1, 2, 3, 4, 5, 6, 7].
    [Show full text]
  • University of Southampton Research Repository Eprints Soton
    University of Southampton Research Repository ePrints Soton Copyright © and Moral Rights for this thesis are retained by the author and/or other copyright owners. A copy can be downloaded for personal non-commercial research or study, without prior permission or charge. This thesis cannot be reproduced or quoted extensively from without first obtaining permission in writing from the copyright holder/s. The content must not be changed in any way or sold commercially in any format or medium without the formal permission of the copyright holders. When referring to this work, full bibliographic details including the author, title, awarding institution and date of the thesis must be given e.g. AUTHOR (year of submission) "Full thesis title", University of Southampton, name of the University School or Department, PhD Thesis, pagination http://eprints.soton.ac.uk UNIVERSITY OF SOUTHAMPTON FACULTY OF PHYSICAL SCIENCES AND ENGINEERING Electronics and Computer Science Preemptive type checking in dynamically typed programs by Neville Grech Thesis for the degree of Doctor of Philosophy November 2013 The research work disclosed in this publication is partially funded by the Strategic Educational Pathways Scholarship (Malta). This Scholarship is part-financed by the European Union – European Social Fund (ESF) under Operational Programme II – Cohesion Policy 2007-2013, “Empowering People for More Jobs and a Better Quality Of Life”. Operational Programme II – Cohesion Policy 2007-2013 Empowering People for More Jobs and a Better Quality of Life Scholarship part-financed by the European Union European Social Fund (ESF) Co-financing rate: 85% EU Funds; 15%National Funds Investing in your future UNIVERSITY OF SOUTHAMPTON ABSTRACT FACULTY OF PHYSICAL SCIENCES AND ENGINEERING Electronics and Computer Science Doctor of Philosophy PREEMPTIVE TYPE CHECKING IN DYNAMICALLY TYPED PROGRAMS by Neville Grech With the rise of languages such as JavaScript, dynamically typed languages have gained a strong foothold in the programming language landscape.
    [Show full text]
  • UC Santa Cruz UC Santa Cruz Electronic Theses and Dissertations
    UC Santa Cruz UC Santa Cruz Electronic Theses and Dissertations Title Executable Refinement Types Permalink https://escholarship.org/uc/item/92c8b5hp Author Knowles, Kenneth Lorenz Publication Date 2014 Peer reviewed|Thesis/dissertation eScholarship.org Powered by the California Digital Library University of California UNIVERSITY OF CALIFORNIA SANTA CRUZ EXECUTABLE REFINEMENT TYPES A dissertation submitted in partial satisfaction of the requirements for the degree of DOCTOR OF PHILOSOPHY in COMPUTER SCIENCE by Kenneth L. Knowles March 2014 The dissertation of Kenneth L. Knowles is approved: Professor Cormac Flanagan, Chair Professor Luca de Alfaro Professor Ranjit Jhala Tyrus Miller Vice Provost and Dean of Graduate Studies Copyright c by Kenneth L. Knowles 2014 Table of Contents List of Figures vii Abstract ix Acknowledgments xii 1 Introduction1 1.1 Specification Disciplines...........................3 1.1.1 Dynamic Contracts..........................4 1.1.2 Refinement Types..........................6 1.1.3 Extended Static Checking......................7 1.2 Thesis Overview...............................8 2 Preliminaries 13 2.1 Preparatory Readings............................ 13 2.2 The Simply-Typed λ-Calculus........................ 14 2.2.1 Syntax of STLC........................... 15 2.2.2 Operational Semantics of STLC................... 17 2.2.3 The STLC Type System....................... 19 3 Executable Refinement Types 23 3.1 The Language λH ............................... 25 3.2 Operational Semantics of λH ........................ 28 3.3 Denotation of λH types to sets of ST LC terms.............. 30 3.4 The λH Type System............................ 32 3.4.1 Typing for λH ............................ 33 3.4.2 Type well-formedness for λH .................... 34 3.4.3 Environment well-formedness for λH ................ 35 3.4.4 Subtyping for λH ..........................
    [Show full text]
  • Typed First-Class Traits
    Typed First-Class Traits Xuan Bi The University of Hong Kong, Hong Kong, China [email protected] Bruno C. d. S. Oliveira The University of Hong Kong, Hong Kong, China [email protected] Abstract Many dynamically-typed languages (including JavaScript, Ruby, Python or Racket) support first-class classes, or related concepts such as first-class traits and/or mixins. In those languages classes are first-class values and, like any other values, they can be passed as an argument, or returned from a function. Furthermore first-class classes support dynamic inheritance: i.e. they can inherit from other classes at runtime, enabling programmers to abstract over the inheritance hierarchy. In contrast, type system limitations prevent most statically-typed languages from having first-class classes and dynamic inheritance. This paper shows the design of SEDEL: a polymorphic statically-typed language with first- class traits, supporting dynamic inheritance as well as conventional OO features such as dynamic dispatching and abstract methods. To address the challenges of type-checking first-class traits, SEDEL employs a type system based on the recent work on disjoint intersection types and dis- joint polymorphism. The novelty of SEDEL over core disjoint intersection calculi are source level features for practical OO programming, including first-class traits with dynamic inherit- ance, dynamic dispatching and abstract methods. Inspired by Cook and Palsberg’s work on the denotational semantics for inheritance, we show how to design a source language that can be elaborated into Alpuim et al.’s Fi (a core polymorphic calculus with records supporting disjoint polymorphism). We illustrate the applicability of SEDEL with several example uses for first- class traits, and a case study that modularizes programming language interpreters using a highly modular form of visitors.
    [Show full text]
  • Universidad De Chile Facultad De Ciencias Físicas Y Matem´Aticas Departamento De Ciencias De La Computaci´On Empirically-Driv
    UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS F´ISICAS Y MATEMATICAS´ DEPARTAMENTO DE CIENCIAS DE LA COMPUTACION´ EMPIRICALLY-DRIVEN DESIGN AND IMPLEMENTATION OF GRADUALTALK TESIS PARA OPTAR AL GRADO DE DOCTOR EN CIENCIAS MENCION´ COMPUTACION´ OSCAR EDWIN ALVAREZ CALLAU´ PROFESORES GU´IAS: ERIC´ TANTER ROMAIN ROBBES MIEMBROS DE LA COMISION:´ MAR´IA CECILIA BASTARRICA PINEYRO~ ALEXANDRE BERGEL OSCAR NIERSTRASZ Este trabajo ha sido parcialmente financiado por CONICYT, NIC Chile y Microsoft Research SANTIAGO DE CHILE 2015 Resumen Los lenguajes de tipado din´amicopermiten un desarrollo ´agil. Sin embargo, cuando estos peque~nosprogramas se convierten en aplicaciones grandes, depurar se vuelve una tarea tediosa. Esto se debe principalmente a que los errores son solo detectables en tiempo de ejecuci´on. Smalltalk, al ser un lenguaje de tipado din´amico,sufre de estos problemas. Los sistemas de tipos pueden disminuir ciertos errores de los lenguajes de tipado din´amico. Adem´as,la inserci´onde tipos mejora la documentaci´onde APIs, provee un mejor soporte a los editores y ayuda a optimizar la compilaci´on.Los sistema de tipos, especialmente dise~nadospara lenguajes existentes, son llamados sistema de tipos retro-alimentados (retrofitted type systems en ingl´es). Dise~narun sistema de tipos retro-alimentado es una tarea complicada. Esto se debe a que tales sistemas de tipos deben soportar patrones de programaci´onmuy particulares (llamados idioms), minimizar la refactorizaci´onde c´odigopor la inserci´onde tipos, y proveer una integraci´onentre las partes (ej. m´odulos)con y sin tipos. Estos problemas son exacerbados cuando el lenguaje destino es altamente din´amico,como Smalltalk.
    [Show full text]
  • Brand Objects for Nominal Typing
    Brand Objects for Nominal Typing Timothy Jones, Michael Homer, and James Noble Victoria University of Wellington New Zealand {tim,mwh,kjx}@ecs.vuw.ac.nz Abstract Combinations of structural and nominal object typing in systems such as Scala, Whiteoak, and Unity have focused on extending existing nominal, class-based systems with structural subtyping. The typical rules of nominal typing do not lend themselves to such an extension, resulting in major modifications. Adding object branding to an existing structural system integrates nominal and structural typing without excessively complicating the type system. We have implemented brand objects to explicitly type objects, using existing features of the structurally typed language Grace, along with a static type checker which treats the brands as nominal types. We demonstrate that the brands are useful in an existing implementation of Grace, and provide a formal model of the extension to the language. 1998 ACM Subject Classification D.3.3 Classes and objects Keywords and phrases brands, types, structural, nominal, Grace Digital Object Identifier 10.4230/LIPIcs.ECOOP.2015.198 Supplementary Material ECOOP Artifact Evaluation approved artifact available at http://dx.doi.org/10.4230/DARTS.1.1.4 1 Introduction Most statically typed object-oriented languages use nominal subtyping. From Simula [5] and C++, through to Java, C] and Dart, an instance of one type can only be considered an instance of another type if the subtyping relationship is declared in advance, generally at the time the subtype is declared. Some modern languages have adopted structural subtyping. In Go, for example, types are declared as interfaces, and an object conforms to a type if the object declares at least the methods required by the interface [41].
    [Show full text]