Semantic Types for Class-Based Objects

Total Page:16

File Type:pdf, Size:1020Kb

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. For Nakano’s system, we consider the open problem of type inference. We introduce insertion variables (similar to the expansion variables of Kfoury and Wells), which allow to infer when the approximation modality is required. We define a type inference procedure, and conjecture its sound- ness based on a technique of Cardone and Coppo. Finally, we consider how Nakano’s approach may be applied to Featherweight Java and discuss how intersection and logical recursive types may be brought together into a single system. 3 I dedicate this thesis to the memory of my grandfather, David W. Hyam, who I very much wish was here to see it. 5 Acknowledgements I would like to acknowledge the help, input and inspiration of a number of people who have all helped me, in their own larger and smaller ways, to bring this thesis into being. Firstly, my supervisor, Steffen, deserves my sincere thanks for all his guidance over the past five years. If it weren’t for him, I would never have embarked upon this line of research that I have found so absolutely fascinating. Also, if it weren’t for him I would probably have lost myself in many unnecessary details – his gift for being able to cut through to the heart of many a problem has been invaluable when I couldn’t see the wood for the trees. I would also like to thank my second supervisor, Sophia Drossopoulou, who has always been more than willing to offer many insightful suggestions and opinions, and above all a friendly ear. I owe a huge debt to my parents, Peter and Catherine, and all of my family who have been so sup- portive and encouraging of my efforts. They have always brought me up to believe that I can achieve everything that I put my mind to, and without them I would never have reached this point. I must thank, in particular, my late aunt Helen whose financial legacy, in part, made my higher education aspirations a reality. My wonderful girlfriend Carlotta has shared some of this journey with me, and this thesis is just as much hers as it is mine, having borne my distractions and preoccupations with grace. Her encouragement and faith in me has carried me through more than a few difficult days. I thank Jayshan Raghunandan, Ioana Boureanu, Juan Vaccari and Alex Summers for their friendship, interesting discussions, and for making the start of my PhD such an enjoyable experience. I especially thank Alex, who may be one of the most intelligent, friendly and modest people I have met. Finally, I would like to extend my appreciation to the SLURP group, and the staff and students of the Imperial College Department of Computing, who have all contributed to my wider academic environ- ment. 7 Contents 1. Introduction 11 I. Simple Intersection Types 17 2. The Intersection Type Discipline 19 2.1. LambdaCalculus ................................. ..... 19 2.2. ObjectCalculus ................................. ...... 23 3. Intersection Types for Featherweight Java 29 3.1. FeatherweightJava ..... ...... ..... ...... ...... .. ....... 29 3.2. Intersection Type Assignment . .......... 31 3.3. Subject Reduction & Expansion . ......... 33 4. Strong Normalisation of Derivation Reduction 37 5. The Approximation Result: Linking Types with Semantics 61 5.1. Approximation Semantics . ........ 61 5.2. The Approximation Result . ........ 66 5.3. Characterisation of Normalisation . ............. 69 6. Worked Examples 73 6.1. A Self-Returning Object . ........ 73 6.2. AnUnsolvableProgram. ....... 74 6.3. Lists.......................................... 76 6.4. Object-Oriented Arithmetic . ........... 78 6.5. A Type-Preserving Encoding of Combinatory Logic . ............... 80 6.6. Comparison with Nominal Typing . ......... 89 7. Type Inference 99 7.1. A Restricted Type Assignment System . ........... 99 7.2. Substitution and Unification . ..........102 7.3. PrincipalTypings ............................... .......106 9 II. Logical Recursive Types 121 8. Logical vs. Non-Logical Recursive Types 123 8.1. Non-Logical Recursive Types . ..........124 8.2. Nakano’s Logical Systems . ........126 8.2.1. TheTypeSystems ............................... 127 8.2.2. Convergence Properties . 130 8.2.3. A Type for Fixed-Point Operators . ........132 9. Type Inference for Nakano’s System 135 9.1. Types .......................................... 136 9.2. TypeAssignment ................................. 139 9.3. OperationsonTypes .............................. 141 9.4. A Decision Procedure for Subtyping . ...........144 9.5. Unification ..................................... 149 9.6. TypeInference .................................. 165 9.6.1. Typing Curry’s Fixed Point Operator Y ......................169 9.6.2. Incompleteness of the Algorithm . .........174 9.6.3. OnPrincipalTypings . 176 10. Extending Nakano Types to Featherweight Java 181 10.1.ClassesAsFunctions . ........181 10.2. Nakano Types for Featherweight Java . ............184 10.3.TypedExamples................................. 190 10.3.1. A Self-Returning Object . .......191 10.3.2. A Nonterminating Program . .......193 10.3.3. Mutually Recursive Class Definitions . ...........193 10.3.4. A Fixed-Point Operator Construction . ...........196 10.3.5.Lists....................................... 197 10.3.6. Object-Oriented Arithmetic . .........202 10.4. Extending The Type Inference Algorithm . .............204 10.5. Nakano Intersection Types . ..........208 11. Summary of Contributions & Future Work 219 Bibliography 223 A. Type-Based Analysis of Ackermann’s Function 233 A.1. The Ackermann Function in Featherweight Java . ..............233 A.2. Strong Normalisation of Ackfj ...............................235 A.3. Typing the Parameterized Ackermann Function . ..............239 A.3.1. Rank 0 Typeability of Ack[0]............................242 A.3.2. Rank 0 Typeability of Ack[1]............................243 A.3.3. Rank 4 Typeability of Ack[2]............................244 10 1. Introduction Type theory constitutes a form of abstract reasoning, or interpretation of programs. It provides a way of classifying programs according to the kinds of values they compute [88]. More generally, type systems specify schemes for associating syntactic entities (types) with programs, in such a way that they reflect abstract properties about the behaviour of those programs. Thus, typeability effectively guarantees well- behavedness, as famously stated by Milner when he said that “Well-typed programs can’t go wrong” [79], where ‘wrong’ is a semantic concept defined in that paper. In type theory, systems in the intersection type discipline (itd) stand out as being able to express both the functional behaviour of programs and their termination properties. Intersection types were first introduced in [40] as an extension to Curry’s basic functionality theory for the Lambda Calculus (λ-calculus or lc) [45]. Since then, the intersection type approach has been extended to many different models of computation including Term Rewriting Systems (trs) [14, 15], sequent calculi [101, 102], object calculi [18, 13], and concurrent calculi [37, 87] proving its versatility as an analytical technique for program verification. Furthermore, intersection types have been put to use in analysing not just termination properties but in dead code analysis [47], strictness analysis [70], and control-flow analysis [17]. It is obvious, then, that intersection types have a great potential as a basis for expressive, type-based analysis of programs. The expressive power of intersection types stems from their deep connection with the mathematical, or denotational, semantics of programming languages [96, 97]. It was first demonstrated in [20] that the set of intersection types assignable to any given term forms a filter, and that the set of such
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]
  • 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]
  • Type Systems for Programming Languages Contents
    Type Systems for Programming Languages Steffen van Bakel Department of Computing, Imperial College London, 180 Queen’s Gate, London SW7 2BZ, UK [email protected] Spring 2001 (revised Autumn 2016) These notes accompany the course Type Systems for Programming Languages, given to third and fourth year students in Computing and Joint Mathematics and Computing with some experience in reasoning and logic, and students in the Advanced Masters programme at the Department of Computing, Imperial College London. The course is intended for students interested in theoretical computer science, who pos- sess some knowledge of logic. No prior knowledge on type systems or proof techniques is assumed, other than being familiar with the principle of structural induction. Contents 1 Lambda Calculus 3 1.1 λ-terms........................................... 3 1.2 β-conversion........................................ 5 1.3Makingsubstitutionexplicit............................... 8 1.4 Example: a numeral system ............................... 9 2 The Curry type assignment system 11 2.1Currytypeassignment.................................. 11 2.2SubjectReduction..................................... 12 2.3Theprincipaltypeproperty............................... 14 3 Combinatory Logic 20 3.1 The relation between cl and the Lambda Calculus . ............... 20 3.2 Extending cl ........................................ 22 3.3 Type Assignment for cl ................................. 22 3.4Exercises.......................................... 23 4 Dealing with polymorphism
    [Show full text]