DOCSLIB.ORG

Polytypic Functional Programming and Data Abstraction

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Polytypic Functional Programming and Data Abstraction Polytypic Functional Programming and Data Abstraction by Pablo Nogueira Iglesias, MSc Thesis submitted to the University of Nottingham for the degree of Doctor of Philosophy. September 2005 abstract Structural polymorphism is a generic programming technique known within the func- tional programming community under the names of polytypic or datatype-generic pro- gramming. In this thesis we show that such a technique conflicts with the principle of data abstraction and propose a solution for reconciliation. More concretely, we show that popular polytypic extensions of the functional programming language Haskell, namely, Generic Haskell and Scrap your Boilerplate have their genericity limited by data abstraction. We propose an extension to the Generic Haskell language where the `structure' in `structural polymorphism' is defined around the concept of interface and not the representation of a type. More precisely, polytypic functions capture families of polymorphic functions in one single template definition. Instances of a polytypic function for specific algebraic types can be generated automatically by a compiler following the definitional structure of the types. However, the definitional structure of an abstract type is, for maintainability reasons, logically hidden and, sometimes, even physically unavailable (e.g., precompiled libraries). Even if the representation is known, the semantic gap between an abstract type and its representation type makes automatic generation difficult, if not impossible. Furthermore, if it were possible it would nevertheless be impractical: the code generated from the definitional structure of the internal representation is rendered obsolete when the representation changes. The purpose of an abstract type is to minimise the impact of representation changes on client code. Data abstraction is upheld by client code, whether polytypic or not, when it works with abstract types through their public interfaces. Fortunately, interfaces can provide enough description of `structure' to guide the automatic construction of two polytypic functions that extract and insert data from abstract types to concrete types and vice versa. Polytypic functions can be defined in this setting in terms of polytypic inser- tion, polytypic extraction, and ordinary polytypic functions on concrete types. We propose the extension of the Generic Haskell language with mechanisms that enable programmers to supply the necessary information. The scheme relies on another pro- posed extension to support polytypic programming with type-class constrained types, which we show are not supported by Generic Haskell. Contents 1 Introduction 1 1.1 General theme and contribution . 1 1.2 Notes to the reader . 1 1.3 The problem in a nutshell . 5 1.4 Contributions . 8 1.5 Structure and organisation . 9 I Prerequisites 15 2 Language Games 16 2.1 Object versus meta . 16 2.2 Definitions and equality . 16 2.3 Grammatical conventions . 17 2.4 Quantification . 17 2.5 The importance of types . 17 2.6 Denoting functions . 22 2.7 Lambda Calculi . 22 2.7.1 Pure Simply Typed Lambda Calculus . 23 2.7.2 Adding primitive types and values. 27 2.7.3 Adding parametric polymorphism: System F . 28 2.7.4 Adding type operators: System F! . 30 2.7.5 Adding general recursion . 34 3 Bits of Category Theory 38 3.1 Categories and abstraction . 38 3.2 Direction of arrows . 39 3.3 Definition of category . 41 3.4 Example categories . 42 3.5 Duality . 43 3.6 Initial and final objects . 43 3 3.7 Isomorphisms . 44 3.8 Functors . 44 3.9 (Co)Limits . 46 3.9.1 (Co)Products . 47 3.9.2 (Co)Products and abstraction . 49 3.10 Arrow functor . 51 3.11 Algebra of functors . 52 3.12 Natural transformations . 55 4 Generic Programming 59 4.1 Genericity and the two uses of abstraction . 59 4.2 Data abstraction . 62 4.3 Generic Programming and Software Engineering . 63 4.4 Generic Programming and Generative Programming . 66 4.5 Types and Generic Programming . 67 4.6 Types and program generators . 68 4.7 The Generic Programming zoo . 69 4.7.1 Varieties of instantiation . 70 4.7.2 Varieties of polymorphism . 71 4.8 Where does this work fall? . 79 5 Data Abstraction 80 5.1 Benefits of data abstraction . 81 5.2 Pitfalls of data abstraction . 81 5.3 Algebraic specification of data types . 83 5.4 The basic specification formalism, by example . 86 5.5 Partial specifications with conditional equations. 90 5.6 Constraints on parametricity, reloaded . 92 5.7 Concrete types are bigger . 94 5.8 Embodiments in functional languages . 95 5.8.1 ADTs in Haskell . 95 5.8.2 On constrained algebraic types . 97 5.8.3 The SML module system . 99 5.9 Classification of operators . 101 5.10 Classification of ADTs . 103 II Functional Polytypic Programming and Data Abstraction 106 6 Structural Polymorphism in Haskell 107 6.1 Generic Haskell . 107 6.1.1 Algebraic data types in Haskell . 108 6.1.2 From parametric to structural polymorphism . 112 6.1.3 Generic Haskell and System F! . 124 6.1.4 Nominal type equivalence and embedding-projection pairs . 126 6.1.5 The expressibility of polykinded type definitions . 130 6.1.6 Polytypic abstraction . 131 6.1.7 The expressibility of polytypic definitions . 132 6.1.8 Summary of instantiation process . 133 6.1.9 Polytypic functions are not first-class . 134 6.1.10 Type-class constraints and constrained algebraic types . 135 6.1.11 Polykinded types as context abstractions . 137 6.1.12 Parameterisation on base types . 148 6.1.13 Generic Haskell, categorially . 149 6.2 Scrap your Boilerplate . 152 6.2.1 Strategic Programming . 152 6.2.2 SyB tour . 155 6.3 Generic Haskell vs SyB . 164 6.4 Lightweight approaches . 167 7 Polytypism and Data Abstraction 168 7.1 Polytypism conflicts with data abstraction . 169 7.1.1 Foraging clutter . 171 7.1.2 Breaking the law . 175 7.1.3 On mapping over abstract types . 179 7.2 Don't abstract, export. 182 7.3 Buck the representations! . 184 8 Pattern Matching and Data Abstraction 186 8.1 Conclusions first . 187 8.2 An overview of pattern matching . 187 8.3 Proposals for reconciliation . 191 8.3.1 SML's abstract value constructors . 192 8.3.2 Miranda's lawful concrete types . 193 8.3.3 Wadler's views . 195 8.3.4 Palao's Active Patterns . 198 8.3.5 Other proposals . 204 9 F-views and Polytypic Extensional Programming 205 9.1 An examination of possible approaches . 205 9.2 Extensional Programming: design goals . 207 9.3 Preliminaries: F -algebras and linear ADTs . 208 9.4 Construction vs Observation . 213 9.4.1 Finding dual operators in lists . 217 9.4.2 Finding dual operators in linear ADTs . 218 9.5 Insertion and extraction for unbounded linear ADTs . 219 9.5.1 Choosing the concrete type and the operators . 219 9.5.2 Parameterising on signature morphisms . 221 9.6 Insertion and extraction for bounded linear ADTs . 224 9.7 Extensional equality . 226 9.8 Encoding generic functions on linear ADTs in Haskell . 226 9.9 Extensional Programming = EC[I] . 236 9.10 Polytypic extraction and insertion . 238 9.10.1 F -views . 238 9.10.2 Named signature morphisms . 239 9.10.3 Implementing F -views and named signature morphisms . 241 9.10.4 Polyaric types and instance generation . 242 9.10.5 Generation examples . 244 9.11 Defining polytypic functions . 246 9.12 Polytypic extension . 249 9.13 Exporting . 250 9.14 Forgetful extraction . 253 9.15 Passing and comparing payload between ADTs . 254 10 Future Work 255 III Appendix 259 A Details from Chapter 5 260 A.1 Our specification formalism, set-theoretically . ..
Load more

Recommended publications
  • 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]
  • Cross-Platform Language Design
    Cross-Platform Language Design THIS IS A TEMPORARY TITLE PAGE It will be replaced for the final print by a version provided by the service academique. Thèse n. 1234 2011 présentée le 11 Juin 2018 à la Faculté Informatique et Communications Laboratoire de Méthodes de Programmation 1 programme doctoral en Informatique et Communications École Polytechnique Fédérale de Lausanne pour l’obtention du grade de Docteur ès Sciences par Sébastien Doeraene acceptée sur proposition du jury: Prof James Larus, président du jury Prof Martin Odersky, directeur de thèse Prof Edouard Bugnion, rapporteur Dr Andreas Rossberg, rapporteur Prof Peter Van Roy, rapporteur Lausanne, EPFL, 2018 It is better to repent a sin than regret the loss of a pleasure. — Oscar Wilde Acknowledgments Although there is only one name written in a large font on the front page, there are many people without which this thesis would never have happened, or would not have been quite the same. Five years is a long time, during which I had the privilege to work, discuss, sing, learn and have fun with many people. I am afraid to make a list, for I am sure I will forget some. Nevertheless, I will try my best. First, I would like to thank my advisor, Martin Odersky, for giving me the opportunity to fulfill a dream, that of being part of the design and development team of my favorite programming language. Many thanks for letting me explore the design of Scala.js in my own way, while at the same time always being there when I needed him.
    [Show full text]
  • Behavioral Types in Programming Languages
    Behavioral Types in Programming Languages Behavioral Types in Programming Languages iv Davide Ancona, DIBRIS, Università di Genova, Italy Viviana Bono, Dipartimento di Informatica, Università di Torino, Italy Mario Bravetti, Università di Bologna, Italy / INRIA, France Joana Campos, LaSIGE, Faculdade de Ciências, Universidade de Lisboa, Portugal Giuseppe Castagna, CNRS, IRIF, Univ Paris Diderot, Sorbonne Paris Cité, Paris, France Pierre-Malo Deniélou, Royal Holloway, University of London, UK Simon J. Gay, School of Computing Science, University of Glasgow, UK Nils Gesbert, Université Grenoble Alpes, France Elena Giachino, Università di Bologna, Italy / INRIA, France Raymond Hu, Department of Computing, Imperial College London, UK Einar Broch Johnsen, Institutt for informatikk, Universitetet i Oslo, Norway Francisco Martins, LaSIGE, Faculdade de Ciências, Universidade de Lisboa, Portugal Viviana Mascardi, DIBRIS, Università di Genova, Italy Fabrizio Montesi, University of Southern Denmark Rumyana Neykova, Department of Computing, Imperial College London, UK Nicholas Ng, Department of Computing, Imperial College London, UK Luca Padovani, Dipartimento di Informatica, Università di Torino, Italy Vasco T. Vasconcelos, LaSIGE, Faculdade de Ciências, Universidade de Lisboa, Portugal Nobuko Yoshida, Department of Computing, Imperial College London, UK Boston — Delft Foundations and Trends R in Programming Languages Published, sold and distributed by: now Publishers Inc. PO Box 1024 Hanover, MA 02339 United States Tel. +1-781-985-4510 www.nowpublishers.com [email protected] Outside North America: now Publishers Inc. PO Box 179 2600 AD Delft The Netherlands Tel. +31-6-51115274 The preferred citation for this publication is D. Ancona et al.. Behavioral Types in Programming Languages. Foundations and Trends R in Programming Languages, vol. 3, no.
    [Show full text]
  • Structuring Languages As Object-Oriented Libraries
    Structuring Languages as Object-Oriented Libraries Structuring Languages as Object-Oriented Libraries ACADEMISCH PROEFSCHRIFT ter verkrijging van de graad van doctor aan de Universiteit van Amsterdam op gezag van de Rector Magnificus prof. dr. ir. K. I. J. Maex ten overstaan van een door het College voor Promoties ingestelde commissie, in het openbaar te verdedigen in de Agnietenkapel op donderdag november , te . uur door Pablo Antonio Inostroza Valdera geboren te Concepción, Chili Promotiecommissie Promotores: Prof. Dr. P. Klint Universiteit van Amsterdam Prof. Dr. T. van der Storm Rijksuniversiteit Groningen Overige leden: Prof. Dr. J.A. Bergstra Universiteit van Amsterdam Prof. Dr. B. Combemale University of Toulouse Dr. C. Grelck Universiteit van Amsterdam Prof. Dr. P.D. Mosses Swansea University Dr. B.C.d.S. Oliveira The University of Hong Kong Prof. Dr. M. de Rijke Universiteit van Amsterdam Faculteit der Natuurwetenschappen, Wiskunde en Informatica The work in this thesis has been carried out at Centrum Wiskunde & Informatica (CWI) under the auspices of the research school IPA (Institute for Programming research and Algorith- mics) and has been supported by NWO, in the context of Jacquard Project .. “Next Generation Auditing: Data-Assurance as a Service”. Contents Introduction .Language Libraries . .Object Algebras . .Language Libraries with Object Algebras . .Origins of the Chapters . .Software Artifacts . .Dissertation Structure . Recaf: Java Dialects as Libraries .Introduction . .Overview.................................... .Statement Virtualization . .Full Virtualization . .Implementation of Recaf . .Case Studies . .Discussion . .Related Work . .Conclusion . Tracing Program Transformations with String Origins .Introduction . .String Origins . .Applications of String Origins . .Implementation . .Related Work . .Conclusion . Modular Interpreters with Implicit Context Propagation .Introduction . .Background . v Contents .Implicit Context Propagation .
    [Show full text]
  • A Core Calculus of Metaclasses
    A Core Calculus of Metaclasses Sam Tobin-Hochstadt Eric Allen Northeastern University Sun Microsystems Laboratories [email protected] [email protected] Abstract see the problem, consider a system with a class Eagle and Metaclasses provide a useful mechanism for abstraction in an instance Harry. The static type system can ensure that object-oriented languages. But most languages that support any messages that Harry responds to are also understood by metaclasses impose severe restrictions on their use. Typi- any other instance of Eagle. cally, a metaclass is allowed to have only a single instance However, even in a language where classes can have static and all metaclasses are required to share a common super- methods, the desired relationships cannot be expressed. For class [6]. In addition, few languages that support metaclasses example, in such a language, we can write the expression include a static type system, and none include a type system Eagle.isEndangered() provided that Eagle has the ap- with nominal subtyping (i.e., subtyping as defined in lan- propriate static method. Such a method is appropriate for guages such as the JavaTM Programming Language or C#). any class that is a species. However, if Salmon is another To elucidate the structure of metaclasses and their rela- class in our system, our type system provides us no way of tionship with static types, we present a core calculus for a requiring that it also have an isEndangered method. This nominally typed object-oriented language with metaclasses is because we cannot classify both Salmon and Eagle, when and prove type soundness over this core.
    [Show full text]
  • Behavioral Types in Programming Languages
    Foundations and Trends R in Programming Languages Vol. 3, No. 2-3 (2016) 95–230 c 2016 D. Ancona et al. DOI: 10.1561/2500000031 Behavioral Types in Programming Languages Davide Ancona, DIBRIS, Università di Genova, Italy Viviana Bono, Dipartimento di Informatica, Università di Torino, Italy Mario Bravetti, Università di Bologna, Italy / INRIA, France Joana Campos, LaSIGE, Faculdade de Ciências, Univ de Lisboa, Portugal Giuseppe Castagna, CNRS, IRIF, Univ Paris Diderot, Sorbonne Paris Cité, France Pierre-Malo Deniélou, Royal Holloway, University of London, UK Simon J. Gay, School of Computing Science, University of Glasgow, UK Nils Gesbert, Université Grenoble Alpes, France Elena Giachino, Università di Bologna, Italy / INRIA, France Raymond Hu, Department of Computing, Imperial College London, UK Einar Broch Johnsen, Institutt for informatikk, Universitetet i Oslo, Norway Francisco Martins, LaSIGE, Faculdade de Ciências, Univ de Lisboa, Portugal Viviana Mascardi, DIBRIS, Università di Genova, Italy Fabrizio Montesi, University of Southern Denmark Rumyana Neykova, Department of Computing, Imperial College London, UK Nicholas Ng, Department of Computing, Imperial College London, UK Luca Padovani, Dipartimento di Informatica, Università di Torino, Italy Vasco T. Vasconcelos, LaSIGE, Faculdade de Ciências, Univ de Lisboa, Portugal Nobuko Yoshida, Department of Computing, Imperial College London, UK Contents 1 Introduction 96 2 Object-Oriented Languages 105 2.1 Session Types in Core Object-Oriented Languages . 106 2.2 Behavioral Types in Java-like Languages . 121 2.3 Typestate . 134 2.4 Related Work . 139 3 Functional Languages 140 3.1 Effects for Session Type Checking . 141 3.2 Sessions and Explicit Continuations . 143 3.3 Monadic Approaches to Session Type Checking .
    [Show full text]
  • Semantic Types for Class-Based Objects
    Imperial College London Department of Computing Semantic Types for Class-based Objects Reuben N. S. Rowe July 2012 Supervised by Dr. Steffen van Bakel Submitted in part fulfilment of the requirements for the degree of Doctor of Philosophy in Computing of Imperial College London and the Diploma of Imperial College London 1 Abstract We investigate semantics-based type assignment for class-based object-oriented programming. Our mo- tivation is developing a theoretical basis for practical, expressive, type-based analysis of the functional behaviour of object-oriented programs. We focus our research using Featherweight Java, studying two notions of type assignment:- one using intersection types, the other a ‘logical’ restriction of recursive types. We extend to the object-oriented setting some existing results for intersection type systems. In do- ing so, we contribute to the study of denotational semantics for object-oriented languages. We define a model for Featherweight Java based on approximation, which we relate to our intersection type system via an Approximation Result, proved using a notion of reduction on typing derivations that we show to be strongly normalising. We consider restrictions of our system for which type assignment is decid- able, observing that the implicit recursion present in the class mechanism is a limiting factor in making practical use of the expressive power of intersection types. To overcome this, we consider type assignment based on recursive types. Such types traditionally suffer from the inability to characterise convergence, a key element of our approach. To obtain a se- mantic system of recursive types for Featherweight Java we study Nakano’s systems, whose key feature is an approximation modality which leads to a ‘logical’ system expressing both functional behaviour and convergence.
    [Show full text]
  • Pluggable Type Systems
    Pluggable Type Systems Gilad Bracha Copyright Gilad Bracha 2002-2004 The Paradox of Type Systems • Type systems help reliability and security by mechanically proving program properties • Type systems hurt reliability and security by making things complex and brittle Copyright Gilad Bracha 2003-2004 Mandatory Typing Well known advantages: • Machine-checkable documentation • Types provide conceptual framework • Early error detection • Performance advantages Copyright Gilad Bracha 2002-2004 Mandatory Typing Disadvantages: • Brittleness/Rigidity • Lack of expressive power Copyright Gilad Bracha 2002-2004 Mandatory Typing Disadvantages: • Brittleness/Rigidity • Lack of expressive power Copyright Gilad Bracha 2002-2004 Brittleness of Mandatory Typing • Security/Robustness - as strong as the type system/the weakest link • Persistence/Serialization • Type systems for VM and language collide Copyright Gilad Bracha 2002-2004 Brittleness of Mandatory Typing • Security/Robustness - as strong as the type system/the weakest link • Persistence/Serialization • Type systems for VM and language collide Copyright Gilad Bracha 2002-2004 How Mandatory Typing Undermines Security • Once a mandatory type system is in place, people rely on it for: • Optimization • Security Guarantees • If type system fails, behavior is completely undefined Copyright Gilad Bracha 2002-2004 Example: Class Loaders Class loading becomes incredibly subtle (cf. Liang and Bracha, OOPSLA 98) • Class loaders define name spaces for types • JVM has nominal type system • Inconsistent namespaces mean inconsistent types • Failure to detect inconsistencies across class loaders leads to catastrophic failure (forgeable pointers, privacy violations etc.) Copyright Gilad Bracha 2002-2004 Example: Class Loaders class A { C getC() { return new B().getC();}} class B { C getC() { return new C();}} • A and B defined in different, but overlapping namespaces N1 and N2.
    [Show full text]
  • Internal and External Mechanisms for Extending Programming Languages
    Internal and External Mechanisms for Extending Programming Languages Keren Lenz Technion - Computer Science Department - Ph.D. Thesis PHD-2013-03 - 2013 Technion - Computer Science Department - Ph.D. Thesis PHD-2013-03 - 2013 Internal and External Mechanisms for Extending Programming Languages Research Thesis Submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy Keren Lenz Submitted to the Senate of the Technion — Israel Institute of Technology Kislev 5773 Haifa November 2012 Technion - Computer Science Department - Ph.D. Thesis PHD-2013-03 - 2013 Technion - Computer Science Department - Ph.D. Thesis PHD-2013-03 - 2013 The research thesis was done under the supervision of Prof. Joseph (Yossi) Gil in the Computer Science Department. First and foremost, I would like to express my gratitude to my advisor, Prof. Yossi Gil. He has patiently guided me in my journey as a new researcher, providing me with valuable insights and practical guidance, as well as encouragement. I would like to thank my parents, Hava and Avishay Golz, for years of dedica- tion and devotion and mainly for bestowing me with education as a key principle since early age. Special thanks go to my brother, Omer, for his incredible support and help in parts of this research. Finally, I am indebted to my beloved husband Oron, for standing beside me every step of the way; and to my Children, Amit, Roy and Ido, for making me happy. The generous financial support of the Technion, the Harbor fund, and IBM’s PhD Fellowship program is gratefully acknowledged. Technion - Computer Science Department - Ph.D. Thesis PHD-2013-03 - 2013 Technion - Computer Science Department - Ph.D.
    [Show full text]
  • Ecma TC39-TG1 Held In: Redmond (Microsoft) On: 21St – 23Rd March 2007
    Ecma/TC39-TG1/2007/013 Minutes of the: Ecma TC39-TG1 held in: Redmond (Microsoft) on: 21st – 23rd March 2007 Attendees • Jeff Dyer, Adobe Systems • Dan Smith, Adobe Systems • Brendan Eich, Mozilla Foundation • Graydon Hoare, Mozilla Foundation • Mike Shaver, Mozilla Foundation (Thursday) • Douglas Crockford, Yahoo! (Thursday and Friday) • Chris Pine, Opera Software • Lars Hansen, unaffiliated • Allen Wirfs-Brock, Microsoft • Pratap Lakshman, Microsoft • David Simmons, Microsoft (Friday) • Dave Herman, Northeastern University (Thursday and Friday) • Michael O’Brien, mbedthis (Thursday) • Chris Wilson, Microsoft (Thursday) • Scott Isaacs, Microsoft (Thursday) • Mike Cowlishaw, IBM (Thursday) (on the phone) • Brian Crowder, Mozilla (on the phone) • Cormac Flanagan, UC Santa Cruz (Thursday morning) (on the phone) Agenda items • proposals:documentation: we have two competing proposals and several loose ends • proposals:meta_objects: uses structural types for some data, not obvious that this is a good idea • Implementation of type checks • Tracking refimpl and spec completness • Tracking bugs Day 2 • Discussion on the proposal for incremental evolution of ES3 (forenoon). Day 3 • Spec issues o informative vs. normative ▪ can SML be pretty-printed as normative spec language? ▪ typographic and presentation separation ideas o generate HTML+CSS in addition to Word ▪ or first, then to Word? • Schedule/Venue Ecma International Rue du Rhône 114 CH-1204 Geneva T/F: +41 22 849 6000/01 www.ecma-international.org FC 2007_01_09_TC39_TG1.doc 12/09/2017 10:25:00
    [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]
  • Featherweight Java 12.1 Introduction 12.2 Nominal Vs. Structural Types
    Advanced Topics in Programming Languages Spring Semester, 2012 Lecture 12: Featherweight Java Lecturer: Mooly Sagiv Scribe: Adam Morrison 12.1 Introduction In this lecture we apply the ideas from previous lectures to directly define and reason about Featherweight Java (FJ), an object-oriented language based on Java. FJ is a subset of Java (every FJ program is a Java program) designed with the goal of making its type safety proof as short as possible, while still capturing the essence of Java's safety arguments. FJ therefore incorporates many of Java's interesting aspects, such as the \everything is an object" philosophy and dynamic casting, but drops any feature that would make the safety proof longer without making it significantly different. For example, one central feature that FJ omits is mutation (i.e., the assignment operator), as supporting it would require modeling the heap. The features of Java that FJ does model include mutually recursive class definitions, object creation, field access, method invocation, method override, subtyping and casting. As a compact language model, FJ is useful for modeling extensions of Java. Adapting a language extension to FJ focuses attention on essential aspects of the extension. The original FJ paper [1] demonstrated this by adding generic classes to FJ. 12.2 Nominal vs. structural types systems FJ's type system differs from what we saw in previous lectures. Until now we have been working with structural type systems, in which a type is determined by its structure. In a structural system the following types are equivalent: Euros = famount : Floatg Dollars = famount : Floatg The names Euros and Dollar are simply cosmetic abbreviations.
    [Show full text]