DOCSLIB.ORG

Decidable Subtyping for Path Dependent Types

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Decidable Subtyping for Path Dependent Types Decidable Subtyping for Path Dependent Types by Julian Mackay A thesis submitted to the Victoria University of Wellington in fulfilment of the requirements for the degree of Doctor of Philosophy in Computer Science. Victoria University of Wellington 2020 Abstract Path dependent types form a central component of the Scala programming language. Coupled with other expressive type forms, path dependent types provide for a diverse set of concepts and patterns, from nominality to F- bounded polymorphism. Recent years have seen much work aimed at for- malising the foundations of path dependent types, most notably a hard won proof of type safety. Unfortunately subtyping remains undecidable, present- ing problems for programmers who rely on the results of their tools. One such tool is Dotty, the basis for the upcoming Scala 3. Another is Wyvern, a new programming language that leverages path dependent types to sup- port both first class modules and parametric polymorphism. In this thesis I investigate the issues with deciding subtyping in Wyvern. I define three decidable variants that retain several key instances of expressiveness includ- ing the ability to encode nominality and parametric polymorphism. Wyvfix fixes types to the contexts they are defined in, thereby eliminating expansive environments. Wyvnon-µ removes recursive subtyping, thus removing the key source of expansive environments during subtyping. Wyvµ places a syntactic restriction on the usage of recursive types. I discuss the formal properties of these variants, and the implications each has for expressing the common programming patterns of path dependent types. I have also mechanized the proofs of decidability for both Wyvfix and Wyvµ in Coq Chapter 0 ii Acknowledgments I would most especially like to acknowledge the tremendous support given by my supervisors, Alex Potanin, Lindsay Groves and Jonathan Aldrich. My supervisors have guided and advised me, and are owed much of the credit for the work within this thesis. I would like to thank the input to this work from Ross Tate, who’s in- valuable insight and advice changed the entire trajectory of the research in this thesis. I would also like to thank the examiners for their work in evaluating this thesis. I am also grateful to the friendship I have received from the many office mates I have had over the years, in the many offices I have occupied. While I appreciate the support and friendship of many of my colleagues, I should in particular acknowledge Michael Homer, Tim Jones, Alex Sawcuk da Silva, Chen Wong and Erin Greenwood-Thessman. I would also like to thank the wider School of Engineering and Computer Science for providing me a community over the past few years. Finally, I would like to thank my family for their support, and perhaps most importantly I recognise that I owe my partner Fiona McNamara an immense amount of emotional support. iii Chapter 0 iv Contents 1 Introduction 1 2 Background 5 2.1 Type Systems ........................... 6 2.1.1 λ-Calculus ......................... 6 2.1.2 The Simply Typed λ-Calculus: λ ! .......... 8 2.1.3 Polymorphism: System F ................ 12 2.1.4 Bounded Quantification: System< F : .......... 14 2.1.5 Properties of Type Systems ............... 18 2.1.6 Calculus of Constructions ................ 25 2.2 Object Oriented Languages ................... 26 2.2.1 Dependent Object Types ................. 27 2.2.2 Structural vs Nominal Subtyping ............ 38 2.2.3 Java ............................ 40 2.2.4 Decidability of Subtyping in Java ............ 42 2.3 Wyvern .............................. 48 2.3.1 Modules for Wyvern ................... 49 3 Issues with Subtype Decidability 51 3.1 A Core Wyvern Type System .................. 52 3.1.1 Starting with a Basic Wyvern Type System ...... 52 3.1.2 Properties of Basic Wyvern ............... 56 3.1.3 Wyvcore .......................... 62 v Chapter 0 CONTENTS 3.2 Subtype Undecidability in Wyvcore ............... 68 3.2.1 Encoding System F<:: Dependent Function Types ... 69 3.2.2 Encoding System F<:: Recursive Types ......... 74 3.2.3 Encoding Java Generics ................. 78 4 Material/Shape Separated Wyvcore 87 4.1 Designing a Material/Shape Separation for Wyvcore ...... 87 4.1.1 Relaxing The Material/Shape Separation ........ 89 4.1.2 Nominality in Wyvcore vs Java .............. 90 4.2 Formalizing The Material/Shape Separation in Wyvcore .... 98 4.2.1 Type Graphs in Wyvcore ................. 98 4.2.2 An Extended Syntax for Material/Shape Separated Wyvcore .......................... 102 5 A General Decidability Argument 105 5.1 Wyvexpand: Recursive Expansion of Wyvcore Types ....... 106 5.2 A Subtyping Algorithm for Wyvexpand .............. 108 5.3 Shape Depth ........................... 112 5.4 Termination of Subtyping Algorithm .............. 114 5.5 Fixed Environments ....................... 116 5.5.1 Wyvfix ........................... 117 5.5.2 Subtype Decidability ................... 119 5.5.3 Transitivity in Wyvfix ................... 126 6 Non-Recursive Subtyping 129 6.1 Wyvnon-µ .............................. 129 6.2 Subtype Decidability ....................... 130 6.3 Type Safety ............................ 140 6.3.1 Term Typing and Reduction ............... 140 6.3.2 Encoding Wyvnon-µ in Wadlerfest DOT ......... 144 6.4 Expressiveness .......................... 152 vi Chapter 0 CONTENTS 7 Recursive Types 155 7.1 Examples of Expressiveness with Recursive Types ....... 155 7.2 Wyvµ ............................... 159 7.2.1 Preservation of the Material/Shape Separation .... 159 7.2.2 Wyvcore −! Wyvµ .................... 160 7.2.3 Subtype Decidability ................... 161 7.3 Expressiveness of Wyvµ ..................... 170 7.4 Type Safety ............................ 172 7.4.1 Term Typing and Operational Semantics ........ 174 7.4.2 Encoding Wyvcore in DOT 2016 ............. 176 8 Conclusion 187 8.1 Contributions of this Thesis ................... 187 8.1.1 Nominality in Wyvern .................. 187 8.1.2 Decidable Variants of Wyvcore .............. 188 8.2 Future Work ........................... 190 8.2.1 Type Safety for Wyvfix .................. 190 8.2.2 Transitivity ........................ 190 8.2.3 Intersection and Union Types .............. 192 vii Chapter 0 CONTENTS viii List of Figures 2.1 λ-Calculus Syntax ........................ 7 2.2 λ-Calculus Operational Semantics ................ 7 2.3 Types in the Simply Typed λ-Calculus ............. 9 2.4 Simply Typed λ-Calculus with Booleans ............ 10 2.5 Reduction of Boolean Conditionals ............... 10 2.6 Simply Typed λ-Calculus Type Rules .............. 11 2.7 System F with Booleans ..................... 13 2.8 System F Type Rule Extension ................. 14 2.9 System F Evaluation Rule Extension .............. 14 2.10 Subtyping for System F ..................... 15 2.11 System F<: Syntax extension over System F .......... 17 2.12 System F<: Typing Rules ..................... 17 2.13 System F<: Subtyping Rules ................... 17 2.14 Non-termination of subtyping in System F<: .......... 22 2.15 Kernel F<: Subtyping Rules ................... 23 2.16 Kernel F<: Depth Measure .................... 23 > 2.17 F<: Subtyping for Universally Quantified Types ........ 24 2.18 System F<: with Objects ..................... 26 2.19 Isomorphism on Iso-Recursive Types [70] ............ 30 2.20 Wadlerfest DOT Syntax ..................... 35 2.21 Mutual Dependency between Properties of µDOT ....... 36 2.22 Structural Subtyping ....................... 38 2.23 Type Usage Graph of List .................... 44 ix Chapter 0 LIST OF FIGURES 2.24 Featherweight Wyvern Syntax of Nistor et al. ......... 49 3.1 Basic Wyvern Syntax ....................... 54 3.2 Basic Wyvern Typing ....................... 54 3.3 Basic Wyvern Subtyping ..................... 54 3.4 Syntax Directed modification to System< F : .......... 57 3.5 Syntax Directed modification to Basic Wyvern Subtyping ... 58 3.6 Syntax Directed modification to Basic Wyvern Typing .... 59 3.7 Replacing Recursive and Structure types with Recursive Type Refinement ............................ 60 3.8 Double Bounded Type Declarations with Single Bounded Type Declarations ............................ 61 3.9 Wyvcore Syntax .......................... 63 3.10 Wyvcore Typing .......................... 63 3.11 Wyvcore Type Extension ..................... 63 3.12 Wyvcore Type Extendability ................... 63 3.13 Refinement Flattening ...................... 63 3.14 Wyvcore Subtyping ........................ 64 3.15 Encoding System F<: in Wyvcore ................. 70 N 3.16 F<: Subtyping ........................... 71 N ) 3.17 F<: NAll Wyvcore S-All .................. 72 3.18 Encoding System F<: in Wyvcore without functions ...... 74 3.19 Fragment of Java Subtyping (Grigore 2017) .......... 79 3.20 Encoding Java (Grigore 2017) in Wyvcore ............ 81 3.21 Alternative form of Java Subtyping (Grigore 2017) with Ex- plicit Substitutions ........................ 82 4.1 Material/Shape Separated Wyvcore Type Extension ...... 95 4.2 Concrete Nominal Type Definitions ............... 97 4.3 Syntax for Wyvcore Type Definition Graphs ........... 99 4.4 Type Graph (Definition) of List in Wyvcore .......... 101 4.5 Separation on Material/Shape Type Names .......... 103 x Chapter 0 LIST OF FIGURES 4.6 Material/Shape Separated Wyvcore Syntax ........... 103 5.1 Type Syntax for Wyvexpand .................... 107 5.2 Unfolding Types in Wyvcore to Types in Wyvexpand ....... 108 5.3 Shape Depth Measure on Type Graphs ............
Load more

Recommended publications
  • Types Are Internal Infinity-Groupoids Antoine Allioux, Eric Finster, Matthieu Sozeau
    Types are internal infinity-groupoids Antoine Allioux, Eric Finster, Matthieu Sozeau To cite this version: Antoine Allioux, Eric Finster, Matthieu Sozeau. Types are internal infinity-groupoids. 2021. hal- 03133144 HAL Id: hal-03133144 https://hal.inria.fr/hal-03133144 Preprint submitted on 5 Feb 2021 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Types are Internal 1-groupoids Antoine Allioux∗, Eric Finstery, Matthieu Sozeauz ∗Inria & University of Paris, France [email protected] yUniversity of Birmingham, United Kingdom ericfi[email protected] zInria, France [email protected] Abstract—By extending type theory with a universe of defini- attempts to import these ideas into plain homotopy type theory tionally associative and unital polynomial monads, we show how have, so far, failed. This appears to be a result of a kind of to arrive at a definition of opetopic type which is able to encode circularity: all of the known classical techniques at some point a number of fully coherent algebraic structures. In particular, our approach leads to a definition of 1-groupoid internal to rely on set-level algebraic structures themselves (presheaves, type theory and we prove that the type of such 1-groupoids is operads, or something similar) as a means of presenting or equivalent to the universe of types.
    [Show full text]
  • Sequent Calculus and Equational Programming (Work in Progress)
    Sequent Calculus and Equational Programming (work in progress) Nicolas Guenot and Daniel Gustafsson IT University of Copenhagen {ngue,dagu}@itu.dk Proof assistants and programming languages based on type theories usually come in two flavours: one is based on the standard natural deduction presentation of type theory and involves eliminators, while the other provides a syntax in equational style. We show here that the equational approach corresponds to the use of a focused presentation of a type theory expressed as a sequent calculus. A typed functional language is presented, based on a sequent calculus, that we relate to the syntax and internal language of Agda. In particular, we discuss the use of patterns and case splittings, as well as rules implementing inductive reasoning and dependent products and sums. 1 Programming with Equations Functional programming has proved extremely useful in making the task of writing correct software more abstract and thus less tied to the specific, and complex, architecture of modern computers. This, is in a large part, due to its extensive use of types as an abstraction mechanism, specifying in a crisp way the intended behaviour of a program, but it also relies on its declarative style, as a mathematical approach to functions and data structures. However, the vast gain in expressivity obtained through the development of dependent types makes the programming task more challenging, as it amounts to the question of proving complex theorems — as illustrated by the double nature of proof assistants such as Coq [11] and Agda [18]. Keeping this task as simple as possible is then of the highest importance, and it requires the use of a clear declarative style.
    [Show full text]
  • On Modeling Homotopy Type Theory in Higher Toposes
    Review: model categories for type theory Left exact localizations Injective fibrations On modeling homotopy type theory in higher toposes Mike Shulman1 1(University of San Diego) Midwest homotopy type theory seminar Indiana University Bloomington March 9, 2019 Review: model categories for type theory Left exact localizations Injective fibrations Here we go Theorem Every Grothendieck (1; 1)-topos can be presented by a model category that interprets \Book" Homotopy Type Theory with: • Σ-types, a unit type, Π-types with function extensionality, and identity types. • Strict universes, closed under all the above type formers, and satisfying univalence and the propositional resizing axiom. Review: model categories for type theory Left exact localizations Injective fibrations Here we go Theorem Every Grothendieck (1; 1)-topos can be presented by a model category that interprets \Book" Homotopy Type Theory with: • Σ-types, a unit type, Π-types with function extensionality, and identity types. • Strict universes, closed under all the above type formers, and satisfying univalence and the propositional resizing axiom. Review: model categories for type theory Left exact localizations Injective fibrations Some caveats 1 Classical metatheory: ZFC with inaccessible cardinals. 2 Classical homotopy theory: simplicial sets. (It's not clear which cubical sets can even model the (1; 1)-topos of 1-groupoids.) 3 Will not mention \elementary (1; 1)-toposes" (though we can deduce partial results about them by Yoneda embedding). 4 Not the full \internal language hypothesis" that some \homotopy theory of type theories" is equivalent to the homotopy theory of some kind of (1; 1)-category. Only a unidirectional interpretation | in the useful direction! 5 We assume the initiality hypothesis: a \model of type theory" means a CwF.
    [Show full text]
  • Lecture 2: Variables and Primitive Data Types
    Lecture 2: Variables and Primitive Data Types MIT-AITI Kenya 2005 1 In this lecture, you will learn… • What a variable is – Types of variables – Naming of variables – Variable assignment • What a primitive data type is • Other data types (ex. String) MIT-Africa Internet Technology Initiative 2 ©2005 What is a Variable? • In basic algebra, variables are symbols that can represent values in formulas. • For example the variable x in the formula f(x)=x2+2 can represent any number value. • Similarly, variables in computer program are symbols for arbitrary data. MIT-Africa Internet Technology Initiative 3 ©2005 A Variable Analogy • Think of variables as an empty box that you can put values in. • We can label the box with a name like “Box X” and re-use it many times. • Can perform tasks on the box without caring about what’s inside: – “Move Box X to Shelf A” – “Put item Z in box” – “Open Box X” – “Remove contents from Box X” MIT-Africa Internet Technology Initiative 4 ©2005 Variables Types in Java • Variables in Java have a type. • The type defines what kinds of values a variable is allowed to store. • Think of a variable’s type as the size or shape of the empty box. • The variable x in f(x)=x2+2 is implicitly a number. • If x is a symbol representing the word “Fish”, the formula doesn’t make sense. MIT-Africa Internet Technology Initiative 5 ©2005 Java Types • Integer Types: – int: Most numbers you’ll deal with. – long: Big integers; science, finance, computing. – short: Small integers.
    [Show full text]
  • Dotty Phantom Types (Technical Report)
    Dotty Phantom Types (Technical Report) Nicolas Stucki Aggelos Biboudis Martin Odersky École Polytechnique Fédérale de Lausanne Switzerland Abstract 2006] and even a lightweight form of dependent types [Kise- Phantom types are a well-known type-level, design pattern lyov and Shan 2007]. which is commonly used to express constraints encoded in There are two ways of using phantoms as a design pattern: types. We observe that in modern, multi-paradigm program- a) relying solely on type unication and b) relying on term- ming languages, these encodings are too restrictive or do level evidences. According to the rst way, phantoms are not provide the guarantees that phantom types try to en- encoded with type parameters which must be satised at the force. Furthermore, in some cases they introduce unwanted use-site. The declaration of turnOn expresses the following runtime overhead. constraint: if the state of the machine, S, is Off then T can be We propose a new design for phantom types as a language instantiated, otherwise the bounds of T are not satisable. feature that: (a) solves the aforementioned issues and (b) makes the rst step towards new programming paradigms type State; type On <: State; type Off <: State class Machine[S <: State] { such as proof-carrying code and static capabilities. This pa- def turnOn[T >: S <: Off] = new Machine[On] per presents the design of phantom types for Scala, as im- } new Machine[Off].turnOn plemented in the Dotty compiler. An alternative way to encode the same constraint is by 1 Introduction using an implicit evidence term of type =:=, which is globally Parametric polymorphism has been one of the most popu- available.
    [Show full text]
  • Source Code Auditing: Day 2
    Source Code Auditing: Day 2 Penetration Testing & Vulnerability Analysis Brandon Edwards [email protected] Data Types Continued Data Type Signedness Remember, by default all data types are signed unless specifically declared otherwise But many functions which accept size arguments take unsigned values What is the difference of the types below? char y; unsigned char x; x = 255; y = -1; 3 Data Type Signedness These types are the same size (8-bits) char y; unsigned char x; 4 Data Type Signedness A large value in the unsigned type (highest bit set) is a negative value in the signed type char y; unsigned char x; 5 Data Type Bugs Same concept applies to 16 and 32 bit data types What are the implications of mixing signed & unsigned types ? #define MAXSOCKBUF 4096 int readNetworkData(int sock) { char buf[MAXSOCKBUF]; int length; read(sock, (char *)&length, 4); if (length < MAXSOCKBUF) { read(sock, buf, length); } } 6 Data Type Signedness The check is between two signed values… #define MAXSOCKBUF 4096 if (length < MAXSOCKBUF) So if length is negative (highest bit / signed bit set), it will evaluate as less than MAXSOCKBUF But the read() function takes only unsigned values for it’s size Remember, the highest bit (or signed bit is set), and the compiler implicitly converts the length to unsigned for read() 7 Data Type Signedness So what if length is -1 (or 0xFFFFFFFF in hex)? #define MAXSOCKBUF 4096 if (length < MAXSOCKBUF) { read(sock, buf, length); } When the length check is performed, it is asking if -1 is less than 4096 When the length is passed to read, it is converted to unsigned and becomes the unsigned equivalent of -1, which for 32bits is 4294967295 8 Data Type Bugs Variation in data type sizes can also introduce bugs Remember the primitive data type sizes? (x86): An integer type is 32bits A short type is 16bits A char type is 8 bits Sometimes code is written without considering differences between these.
    [Show full text]
  • UML Profile for Communicating Systems a New UML Profile for the Specification and Description of Internet Communication and Signaling Protocols
    UML Profile for Communicating Systems A New UML Profile for the Specification and Description of Internet Communication and Signaling Protocols Dissertation zur Erlangung des Doktorgrades der Mathematisch-Naturwissenschaftlichen Fakultäten der Georg-August-Universität zu Göttingen vorgelegt von Constantin Werner aus Salzgitter-Bad Göttingen 2006 D7 Referent: Prof. Dr. Dieter Hogrefe Korreferent: Prof. Dr. Jens Grabowski Tag der mündlichen Prüfung: 30.10.2006 ii Abstract This thesis presents a new Unified Modeling Language 2 (UML) profile for communicating systems. It is developed for the unambiguous, executable specification and description of communication and signaling protocols for the Internet. This profile allows to analyze, simulate and validate a communication protocol specification in the UML before its implementation. This profile is driven by the experience and intelligibility of the Specification and Description Language (SDL) for telecommunication protocol engineering. However, as shown in this thesis, SDL is not optimally suited for specifying communication protocols for the Internet due to their diverse nature. Therefore, this profile features new high-level language concepts rendering the specification and description of Internet protocols more intuitively while abstracting from concrete implementation issues. Due to its support of several concrete notations, this profile is designed to work with a number of UML compliant modeling tools. In contrast to other proposals, this profile binds the informal UML semantics with many semantic variation points by defining formal constraints for the profile definition and providing a mapping specification to SDL by the Object Constraint Language. In addition, the profile incorporates extension points to enable mappings to many formal description languages including SDL. To demonstrate the usability of the profile, a case study of a concrete Internet signaling protocol is presented.
    [Show full text]
  • G22.2110-003 Programming Languages - Fall 2012 Week 14 - Part 1
    G22.2110-003 Programming Languages - Fall 2012 Week 14 - Part 1 Thomas Wies New York University Review Last lecture I Exceptions Outline Today: I Generic Programming Sources for today's lecture: I PLP, ch. 8.4 I Programming in Scala, ch. 19, 20.6 Generic programming Subroutines provide a way to abstract over values. Generic programming lets us abstract over types. Examples: I A sorting algorithm has the same structure, regardless of the types being sorted I Stack primitives have the same semantics, regardless of the objects stored on the stack. One common use: I algorithms on containers: updating, iteration, search Language models: I C: macros (textual substitution) or unsafe casts I Ada: generic units and instantiations I C++, Java, C#, Scala: generics (also called templates) I ML: parametric polymorphism, functors Parameterizing software components Construct Parameter(s): array bounds, element type subprogram values (arguments) Ada generic package values, types, packages Ada generic subprogram values, types C++ class template values, types C++ function template values, types Java generic classes Scala generic types (and implicit values) ML function values (including other functions) ML type constructor types ML functor values, types, structures Templates in C++ template <typename T> class Array { public : explicit Array (size_t); // constructor T& operator[] (size_t); // subscript operator ... // other operations private : ... // a size and a pointer to an array }; Array<int> V1(100); // instantiation Array<int> V2; // use default constructor
    [Show full text]
  • Proof-Assistants Using Dependent Type Systems
    CHAPTER 18 Proof-Assistants Using Dependent Type Systems Henk Barendregt Herman Geuvers Contents I Proof checking 1151 2 Type-theoretic notions for proof checking 1153 2.1 Proof checking mathematical statements 1153 2.2 Propositions as types 1156 2.3 Examples of proofs as terms 1157 2.4 Intermezzo: Logical frameworks. 1160 2.5 Functions: algorithms versus graphs 1164 2.6 Subject Reduction . 1166 2.7 Conversion and Computation 1166 2.8 Equality . 1168 2.9 Connection between logic and type theory 1175 3 Type systems for proof checking 1180 3. l Higher order predicate logic . 1181 3.2 Higher order typed A-calculus . 1185 3.3 Pure Type Systems 1196 3.4 Properties of P ure Type Systems . 1199 3.5 Extensions of Pure Type Systems 1202 3.6 Products and Sums 1202 3.7 E-typcs 1204 3.8 Inductive Types 1206 4 Proof-development in type systems 1211 4.1 Tactics 1212 4.2 Examples of Proof Development 1214 4.3 Autarkic Computations 1220 5 P roof assistants 1223 5.1 Comparing proof-assistants . 1224 5.2 Applications of proof-assistants 1228 Bibliography 1230 Index 1235 Name index 1238 HANDBOOK OF AUTOMAT8D REASONING Edited by Alan Robinson and Andrei Voronkov © 2001 Elsevier Science Publishers 8.V. All rights reserved PROOF-ASSISTANTS USING DEPENDENT TYPE SYSTEMS 1151 I. Proof checking Proof checking consists of the automated verification of mathematical theories by first fully formalizing the underlying primitive notions, the definitions, the axioms and the proofs. Then the definitions are checked for their well-formedness and the proofs for their correctness, all this within a given logic.
    [Show full text]
  • Advanced-Java.Pdf
    Advanced java i Advanced java Advanced java ii Contents 1 How to create and destroy objects 1 1.1 Introduction......................................................1 1.2 Instance Construction.................................................1 1.2.1 Implicit (Generated) Constructor.......................................1 1.2.2 Constructors without Arguments.......................................1 1.2.3 Constructors with Arguments........................................2 1.2.4 Initialization Blocks.............................................2 1.2.5 Construction guarantee............................................3 1.2.6 Visibility...................................................4 1.2.7 Garbage collection..............................................4 1.2.8 Finalizers...................................................5 1.3 Static initialization..................................................5 1.4 Construction Patterns.................................................5 1.4.1 Singleton...................................................6 1.4.2 Utility/Helper Class.............................................7 1.4.3 Factory....................................................7 1.4.4 Dependency Injection............................................8 1.5 Download the Source Code..............................................9 1.6 What’s next......................................................9 2 Using methods common to all objects 10 2.1 Introduction...................................................... 10 2.2 Methods equals and hashCode...........................................
    [Show full text]
  • Java Generics Adoption: How New Features Are Introduced, Championed, Or Ignored
    Java Generics Adoption: How New Features are Introduced, Championed, or Ignored Chris Parnin Christian Bird Emerson Murphy-Hill College of Computing Microsoft Research Dept. of Computer Science Georgia Institute of Redmond, Washington North Carolina State Technology [email protected] University Atlanta, Georgia Raleigh, North Carolina [email protected] [email protected] Far too often, greatly heralded claims and visions of new language features fail to hold or persist in practice. Discus- ABSTRACT sions of the costs and benefits of language features can easily devolve into a religious war with both sides armed with little Support for generic programming was added to the Java more than anecdotes [13]. Empirical evidence about the language in 2004, representing perhaps the most significant adoption and use of past language features should inform change to one of the most widely used programming lan- and encourage a more rational discussion when designing guages today. Researchers and language designers antici- language features and considering how they should be de- pated this addition would relieve many long-standing prob- ployed. Collecting this evidence is not just sensible but a lems plaguing developers, but surprisingly, no one has yet responsibility of our community. measured whether generics actually provide such relief. In In this paper, we examine the adoption and use of generics, this paper, we report on the first empirical investigation into which were introduced into the Java language in 2004. When how Java generics have been integrated into open source Sun introduced generics, they claimed that the language software by automatically mining the history of 20 popular feature was \a long-awaited enhancement to the type system" open source Java programs, traversing more than 500 million that \eliminates the drudgery of casting." Sun recommended lines of code in the process.
    [Show full text]
  • Webassembly Specification
    WebAssembly Specification Release 1.1 WebAssembly Community Group Andreas Rossberg (editor) Mar 11, 2021 Contents 1 Introduction 1 1.1 Introduction.............................................1 1.2 Overview...............................................3 2 Structure 5 2.1 Conventions.............................................5 2.2 Values................................................7 2.3 Types.................................................8 2.4 Instructions.............................................. 11 2.5 Modules............................................... 15 3 Validation 21 3.1 Conventions............................................. 21 3.2 Types................................................. 24 3.3 Instructions.............................................. 27 3.4 Modules............................................... 39 4 Execution 47 4.1 Conventions............................................. 47 4.2 Runtime Structure.......................................... 49 4.3 Numerics............................................... 56 4.4 Instructions.............................................. 76 4.5 Modules............................................... 98 5 Binary Format 109 5.1 Conventions............................................. 109 5.2 Values................................................ 111 5.3 Types................................................. 112 5.4 Instructions.............................................. 114 5.5 Modules............................................... 120 6 Text Format 127 6.1 Conventions............................................
    [Show full text]