DOCSLIB.ORG

ICFP: G: Type Inference for Disjoint Intersection Types

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
ICFP: G: Type Inference for Disjoint Intersection Types ICFP: G: Type Inference for Disjoint Intersection Types Birthe van den Berg, KU Leuven, Belgium∗ [email protected] 1 Problem and Motivation be somewhat arbitrary and unexpected. Hence, a more ex- Intersection types [14, 34] were first introduced in the early plicit approach prevents incoherence by rejecting programs 1980s in a theoretical pursuit to characterize all strongly nor- with multiple meanings. This is the approach taken by dis- malizing λ-calculus terms. Yet, in recent years they have risen joint intersection types [30], which we build on in this work. to practical prominence as part of industrial programming They require the types A and B of the two terms in a merge languages like Scala and its DOT-calculus [2], Microsoft’s to be disjoint, denoted A ∗ B. If the disjointness requirement TypeScript, Facebook’s Flow and Red Hat’s Ceylon. is violated, as in the example above where Int ∗ Int does not The intersection of types A and B, denoted A&B, is the hold, the program is rejected, explicitly asking the program- type of all values that have at the same time type A and mer to manually resolve the issue. type B. They are a natural fit for languages that feature both Disjoint intersection types are also compatible with pow- subtyping and advanced forms of inheritance, like multiple erful BCD-style subtyping [4] and parametric polymorphism inheritance, traits or mixins. Consider the following Scala [1]. This makes them able to express advanced subtyping example where openAndShow invokes the open and show features—like nested composition [15, 19], which is a key as- methods on its parameter x: pect of family polymorphism [18] and scalable extensibility— as well as a concise solution to the expression problem. Un- def openAndShow(x: Openable & Showable) fortunately using disjoint intersection types for these and = { x.open() ; x.show() } other applications can be daunting as programmers have to The two invoked methods are defined in separate traits add ample type and disjointness annotations to their pro- trait Openable { def open(): Unit } grams in order to help the type checker. trait Showable { def show(): Unit } This work aims to unburden the programmer and make Hence, x should have both types Openable and Showable. disjoint intersection types more accessible by providing a These two type requirements are combined in the intersec- type inference algorithm that automatically derives the nec- tion type Openable & Showable. The class Door inherits essary type and disjointness information. Our algorithm both traits and implements both methods: should do for disjoint intersection types what the famous Algorithm W does for the Hindley-Milner type system [21, class Door extends Openable with Showable { 26, 27]. What makes our setting much more challenging def open() { println("door opens") } is the combination of intersection types, disjointness con- def show() { println("door shows") } straints, BCD subtyping and parametric polymorphism. As } far as we know, no prior work considers the combination This makes the call openAndShow(new Door) valid. of these features and can unlock type inference for modern The merge operator [17] x;;y provides a primitive nota- programming languages with advanced inheritance features. tion for introducing intersection types. For instance, (true;; 5) In short, the problem statement of this paper is: has type Bool & Int and can behave as a Bool value or an Intvalue to suit the context it is used in: How to do type inference for disjoint intersection types? (true ,, 5) OR false = true This work is based on my master’s thesis. (true ,, 5) + 3 = 8 If not treated carefully, the merge operator can merge terms 2 Background and Related Work + of overlapping types, making the semantics ambiguous, for 2.1 History of the Fi -calculus example: Figure1 shows an historical overview of how intersection + (1 ,, 5) + 3 = 6 types evolved into the Fi -calculus. (1 ,, 5) + 3 = 8 Coppo [14] and Pottinger [34] were the first to introduce The Scala and Typescript counterparts of the merge operator intersection types to characterize all strongly normalizing deal with this ambiguity by picking the first component of λ-terms. Intersection types increase the expressiveness of the intersection in case of overlap. This automatic choice can types but in many languages, such as Ceylon [28], intersec- tions of disjoint types are uninhabited. In order to also in- ∗Advisor: Tom Schrijvers crease the expressiveness of terms, Reynolds [36] introduced Conference’17, July 2017, Washington, DC, USA B. van den Berg Figure 1. Timeline of the evolution of calculi with intersection types. a restricted version of a merge operator for the Forsythe on which fields are shown or hidden. Therefore, whenever a language, which for instance forbids intersections of two value of a certain record type is expected, a record contain- function types. Castagna et al. [11] also studied a merge-like ing more information than necessary can be supplied [33]. operator for functions in their language λ&. Polymorphic records are supported by row polymorphism In 2014, Dunfield [17] introduced a calculus λ;; with unre- and by structural subtyping. The extra information of poly- stricted intersections, unions and merges. Oliveira et al. [30] morphic records, which is implicitly included in the records, transformed this calculus into a coherent equivalent λi by can take three forms: absent, present A, or row variable introducing disjoint intersection types. In 1983, Barendregt ρ, indicating that the field information is unknown. Row et al. introduced BCD subtyping [4] in their BCD type system variables cannot contain fields with a label that is already with distributivity of the intersection operator over function present in the record. Similarly, in type fl : Ag & B [1], type B types. Blaauwbroek [9] extended λ;; with BCD subtyping in can be considered a row variable. The disjointness constraint _ + his calculus λ^. In λi [7] these ideas were combined into a co- ensures that values of type B do not contain a record with herent calculus with disjoint and unrestricted intersections type fl : Ag. featuring BCD subtyping. Many features of row polymorphism can be simulated When combining subtyping with polymorphism, the most with disjoint polymorphism. Harper and Pierce have de- common procedure is to use bounded quantification, e.g. signed λ j j [20], which is essentially System F with row poly- 8(α <: Int):α ! α, of which F<: [10] in 1985 defines a morphism and a merge operator jj. It uses constrained quan- model. Pierce [32] claimed that bounded quantification can tification to avoid concatenating records with a common field be encoded in terms of intersection types and polymorphism label and allows merging records with statically unknown and proposed the F^ calculus, in which the above type is fields, for example: equivalent to 8α:(α ^ Int) ! (α ^ Int). mergeRcd = Λα #Empty:Λα #α :λx : α :λx : α :x jjx Disjoint intersection types deserve special attention when 1 2 1 1 1 2 2 1 2 used in combination with parametric polymorphism. This where the type variables lack type information, but the com- was apparent to Alpuim et al. [1] who extended λi with patibility (i.e. no common record labels) is guaranteed by the polymorphism to their calculus Fi , featuring disjoint poly- constraints in the quantification. This can easily be translated morphism. Disjoint quantification includes disjointness re- to a calculus with disjoint quantification: quirements at the term and type level in the introduction of mergeRcd’ = Λ(α ∗ >):Λ(α ∗ α ):λx : α :λx : α :x ;; x type variables, generalizing System F univeral quantification, 1 2 1 1 1 2 2 1 2 e.g. 8(α ∗ Int):α & Int. The empty constraint is denoted by The ideas of row polymorphism were later adopted into disjointness with >. type systems for extensible records [20, 24]. Type inference + + is supported for various row type systems such as those of Combining the ideas of λi and Fi led to the design of Fi [8], a calculus with disjoint and unrestricted intersections, Wand [39, 40], Leijen [24] or Rémy [35]. disjoint polymorphism and BCD subtyping; and SEDEL [6], + 2.3 Intersection Types and Type Inference a source language built on top of Fi . An intersection of types A and B can be understood from 2.2 Row polymorphism three perspectives [5]: Row types were first introduced by Wand [40] to model in- • Set-theory: containing all elements of A that are also heritance, presenting the concept of row variables to allow elements of B, an incremental construction of record types. Consider poly- • Type-theory: being a subtype of A as well as of B, morphic records: records that have many types, depending • Order-theory: greatest lower bound of A and B. ICFP: G: Type Inference for Disjoint Intersection Types Conference’17, July 2017, Washington, DC, USA In this sense, intersection types can also be considered an those of the form A & B <: C. option for type polymorphism. Every finite-rank25 [ ] restric- The merge operator allows to explicitly introduce values of tion of calculi with intersection types has principal typings types with different type constructors, e.g., (Int ! Int) & Bool. and decidable type inference [23]. Rank-N intersection types, Most calculi lack support for this operator because it is not for a fixed value of N, refer to types in which an intersection well-studied and complicates getting coherent semantics [17]. does not appear in the domain of N or more function types However, it enables a powerful type system with function [31]. For instance, ((Int&Bool) ! Int) ! Bool is a rank-3 overloading, e.g., ((λx ! x + 1);; (λx ! x > 0)) 3 which intersection type. Furthermore, parametric polymorphism has as result 4;; true of type Int & Bool. should be restricted to prenex predicative polymorphism Also distributivity is seldomly used in calculi with a merge in order to have decidable type inference.
Load more

Recommended publications
  • First Class Overloading Via Insersection Type Parameters⋆
    First Class Overloading via Insersection Type Parameters? Elton Cardoso2, Carlos Camar~ao1, and Lucilia Figueiredo2 1 Universidade Federal de Minas Gerais, [email protected] 2 Universidade Federal de Ouro Preto [email protected], [email protected] Abstract The Hindley-Milner type system imposes the restriction that function parameters must have monomorphic types. Lifting this restric- tion and providing system F “first class" polymorphism is clearly desir- able, but comes with the difficulty that inference of types for system F is undecidable. More practical type systems incorporating types of higher- rank have recently been proposed, that rely on system F but require type annotations for the definition of functions with polymorphic type parameters. However, these type annotations inevitably disallow some possible uses of higher-rank functions. To avoid this problem and to pro- mote code reuse, we explore using intersection types for specifying the types of function parameters that are used polymorphically inside the function body, allowing a flexible use of such functions, on applications to both polymorphic or overloaded arguments. 1 Introduction The Hindley-Milner type system [9] (HM) has been successfuly used as the basis for type systems of modern functional programming languages, such as Haskell [23] and ML [20]. This is due to its remarkable properties that a compiler can in- fer the principal type for any language expression, without any help from the programmer, and the type inference algorithm [5] is relatively simple. This is achieved, however, by imposing some restrictions, a major one being that func- tion parameters must have monomorphic types. For example, the following definition is not allowed in the HM type system: foo g = (g [True,False], g ['a','b','c']) Since parameter g is used with distinct types in the function's body (being applied to both a list of booleans and a list of characters), its type cannot be monomorphic, and this definition of foo cannot thus be typed in HM.
    [Show full text]
  • Disjoint Polymorphism
    Disjoint Polymorphism João Alpuim, Bruno C. d. S. Oliveira, and Zhiyuan Shi The University of Hong Kong {alpuim,bruno,zyshi}@cs.hku.hk Abstract. The combination of intersection types, a merge operator and parametric polymorphism enables important applications for program- ming. However, such combination makes it hard to achieve the desirable property of a coherent semantics: all valid reductions for the same expres- sion should have the same value. Recent work proposed disjoint inter- sections types as a means to ensure coherence in a simply typed setting. However, the addition of parametric polymorphism was not studied. This paper presents Fi: a calculus with disjoint intersection types, a vari- ant of parametric polymorphism and a merge operator. Fi is both type- safe and coherent. The key difficulty in adding polymorphism is that, when a type variable occurs in an intersection type, it is not statically known whether the instantiated type will be disjoint to other compo- nents of the intersection. To address this problem we propose disjoint polymorphism: a constrained form of parametric polymorphism, which allows disjointness constraints for type variables. With disjoint polymor- phism the calculus remains very flexible in terms of programs that can be written, while retaining coherence. 1 Introduction Intersection types [20,43] are a popular language feature for modern languages, such as Microsoft’s TypeScript [4], Redhat’s Ceylon [1], Facebook’s Flow [3] and Scala [37]. In those languages a typical use of intersection types, which has been known for a long time [19], is to model the subtyping aspects of OO-style multiple inheritance.
    [Show full text]
  • Polymorphic Intersection Type Assignment for Rewrite Systems with Abstraction and -Rule Extended Abstract
    Polymorphic Intersection Type Assignment for Rewrite Systems with Abstraction and -rule Extended Abstract Steffen van Bakel , Franco Barbanera , and Maribel Fernandez´ Department of Computing, Imperial College, 180 Queen’s Gate, London SW7 2BZ. [email protected] Dipartimento di Matematica, Universita` degli Studi di Catania, Viale A. Doria 6, 95125 Catania, Italia. [email protected] LIENS (CNRS URA 8548), Ecole Normale Superieure,´ 45, rue d’Ulm, 75005 Paris, France. [email protected] Abstract. We define two type assignment systems for first-order rewriting ex- tended with application, -abstraction, and -reduction (TRS ). The types used in these systems are a combination of ( -free) intersection and polymorphic types. The first system is the general one, for which we prove a subject reduction theorem and show that all typeable terms are strongly normalisable. The second is a decidable subsystem of the first, by restricting types to Rank 2. For this sys- tem we define, using an extended notion of unification, a notion of principal type, and show that type assignment is decidable. Introduction The combination of -calculus (LC) and term rewriting systems (TRS) has attracted attention not only from the area of programming language design, but also from the rapidly evolving field of theorem provers. It is well-known by now that type disciplines provide an environment in which rewrite rules and -reduction can be combined with- out loss of their useful properties. This is supported by a number of results for a broad range of type systems [11, 12, 20, 7, 8, 5]. In this paper we study the combination of LC and TRS as a basis for the design of a programming language.
    [Show full text]
  • Rank 2 Type Systems and Recursive De Nitions
    Rank 2 typ e systems and recursive de nitions Technical Memorandum MIT/LCS/TM{531 Trevor Jim Lab oratory for Computer Science Massachusetts Institute of Technology August 1995; revised Novemb er 1995 Abstract We demonstrate an equivalence b etween the rank 2 fragments of the p olymorphic lamb da calculus System F and the intersection typ e dis- cipline: exactly the same terms are typable in each system. An imme- diate consequence is that typability in the rank 2 intersection system is DEXPTIME-complete. Weintro duce a rank 2 system combining intersections and p olymorphism, and prove that it typ es exactly the same terms as the other rank 2 systems. The combined system sug- gests a new rule for typing recursive de nitions. The result is a rank 2 typ e system with decidable typ e inference that can typ e some inter- esting examples of p olymorphic recursion. Finally,we discuss some applications of the typ e system in data representation optimizations suchasunboxing and overloading. Keywords: Rank 2 typ es, intersection typ es, p olymorphic recursion, boxing/unboxing, overloading. 1 Intro duction In the past decade, Milner's typ e inference algorithm for ML has b ecome phenomenally successful. As the basis of p opular programming languages like Standard ML and Haskell, Milner's algorithm is the preferred metho d of typ e inference among language implementors. And in the theoretical 545 Technology Square, Cambridge, MA 02139, [email protected]. Supp orted by NSF grants CCR{9113196 and CCR{9417382, and ONR Contract N00014{92{J{1310.
    [Show full text]
  • A Facet-Oriented Modelling
    A Facet-oriented modelling JUAN DE LARA, Universidad Autónoma de Madrid (Spain) ESTHER GUERRA, Universidad Autónoma de Madrid (Spain) JÖRG KIENZLE, McGill University (Canada) Models are the central assets in model-driven engineering (MDE), as they are actively used in all phases of software development. Models are built using metamodel-based languages, and so, objects in models are typed by a metamodel class. This typing is static, established at creation time, and cannot be changed later. Therefore, objects in MDE are closed and fixed with respect to the class they conform to, the fields they have, and the wellformedness constraints they must comply with. This hampers many MDE activities, like the reuse of model-related artefacts such as transformations, the opportunistic or dynamic combination of metamodels, or the dynamic reconfiguration of models. To alleviate this rigidity, we propose making model objects open so that they can acquire or drop so-called facets. These contribute with a type, fields and constraints to the objects holding them. Facets are defined by regular metamodels, hence being a lightweight extension of standard metamodelling. Facet metamodels may declare usage interfaces, as well as laws that govern the assignment of facets to objects (or classes). This paper describes our proposal, reporting on a theory, analysis techniques and an implementation. The benefits of the approach are validated on the basis of five case studies dealing with annotation models, transformation reuse, multi-view modelling, multi-level modelling and language product lines. Categories and Subject Descriptors: [Software and its engineering]: Model-driven software engineering; Domain specific languages; Design languages; Software design engineering Additional Key Words and Phrases: Metamodelling, Flexible Modelling, Role-Based Modelling, METADEPTH ACM Reference Format: Juan de Lara, Esther Guerra, Jörg Kienzle.
    [Show full text]
  • Approximations, Fibrations and Intersection Type Systems
    Approximations, Fibrations and Intersection Type Systems Damiano Mazza*, Luc Pellissier† & Pierre Vial‡ June 16, 2017 Introduction The discovery of linear logic [7] has introduced the notionof linearity in computer science and proof theory. A remarkable fact of linear logic lies in its approximation theorem, stating that an arbitrary proof (not necessarily linear, that is, using its premisses any number of times) can be approximated arbitrarily well by a linear proof. This notion of approximation has then been explored in different directions [4, 10,14]. Approximations are known to be related to relational models, which in turn are related to intersection types [2, 12, 13]. In this work, we investigate approximations in the “type-systems as functors” perspective pioneered by [11]. After recasting fundamental properties of type systems, such as subject reduction and expansion in this framework, we give an intersection type system framework for linear logic, whose derivations are simply-typed approximations. Any calculus that translates meaningfully to linear logic is then endowed by a intersection type system, computed by pulling back one of these intersection type systems for linear logic, and which inherit its properties. All standard intersection type systems (idempotent, such as in [6, 1] or not, such as in [3]) for call-by-name and call-by-value λ-calculus, characterizing weak, strong, and head normalization, fit in this picture, thus justifying the equation: Simply-typed approximations = intersection types derivations. We moreover obtain new type systems, by considering other translations and reductions. 1 What is a type system? The starting point of this research is the work of [11].
    [Show full text]
  • Deconfined Intersection Types in Java
    Deconfined Intersection Types in Java Dedicated to Maurizio Gabbrielli on the Occasion of His 60th Birthday Mariangiola Dezani-Ciancaglini Computer Science Department, University of Torino, Italy [email protected] Paola Giannini Department of Advanced Science and Technology, University of Eastern Piedmont, Alessandria, Italy [email protected] Betti Venneri Department of Statistics, Computer Science, Applications, University of Firenze, Italy betti.venneri@unifi.it Abstract We show how Java intersection types can be freed from their confinement in type casts, in such a way that the proposed Java extension is safe and fully compatible with the current language. To this aim, we exploit two calculi which formalise the simple Java core and the extended language, respectively. Namely, the second calculus extends the first one by allowing an intersection type to be used anywhere in place of a nominal type. We define a translation algorithm, compiling programs of the extended language into programs of the former calculus. The key point is the interaction between λ-expressions and intersection types, that adds safe expressiveness while being the crucial matter in the translation. We prove that the translation preserves typing and semantics. Thus, typed programs in the proposed extension are translated to typed Java programs. Moreover, semantics of translated programs coincides with the one of the source programs. 2012 ACM Subject Classification Theory of computation → Type structures; Theory of computation → Semantics and reasoning Keywords and phrases Intersection Types, Featherweight Java, Lambda Expressions Digital Object Identifier 10.4230/OASIcs.Gabbrielli.2020.3 Acknowledgements We are very pleased to dedicate this work to Maurizio, whose notable contri- butions to the theory of programming languages are well known and appreciated by the scientific community.
    [Show full text]
  • Declared Type Vs Object Type
    Declared Type Vs Object Type andEnforceable patronising and Silvio keeperless fimbriate Sax her laths evangelizations so essentially apotheosise that Jameson matrimonially rebroadcasts or hischants skatings. filthily, Flaggy is Lyle irrigationCytherean? treble Homomorphic shudderingly. Judas delaminating apishly and contingently, she demagnetized her Interface type attributes to type declared vs object They are building blocks for declaring types. Multiple constructors can be defined in a class. This use of patterns encourages consistency and reduces complexity for servers and clients. Object classes facilitate rapid development because they lessen the semantic gap between the code and the users. None along with checking that it has the right type. This answer has been undeleted. Useful in special relativity. Generic methods are methods that introduce their own type parameters. The package is not complete and contains no explicit imports. In short, link to only your code and be specific about what you want feedback on. Embedded reports whether the variable is an embedded field. Type for the results of type inference. Functions belong to the object type. Examples of instances of this type. Press J to jump to the feed. These are usually field types and names that will be associated with state variables at program run time; these state variables either belong to the class or specific instances of the class. The rational is similar to the justification for allowing multiple superclasses, that the Internet is so dynamic and flexible that dynamic changes to the hierarchy are required to manage this volatility. What is the output of the following program? Error: You must enter a valid Integer without commas.
    [Show full text]
  • Typing the Numeric Tower
    Typing the Numeric Tower Vincent St-Amour1, Sam Tobin-Hochstadt1, Matthew Flatt2, and Matthias Felleisen1 1 Northeastern University {stamourv,samth,matthias}@ccs.neu.edu 2 University of Utah [email protected] Abstract. In the past, the creators of numerical programs had to choose between simple expression of mathematical formulas and static type checking. While the Lisp family and its dynamically typed relatives support the straightforward ex- pression via a rich numeric tower, existing statically typed languages force pro- grammers to pollute textbook formulas with explicit coercions or unwieldy nota- tion. In this paper, we demonstrate how the type system of Typed Racket accom- modates both a textbook programming style and expressive static checking. The type system provides a hierarchy of numeric types that can be freely mixed as well as precise specifications of sign, representation, and range information—all while supporting generic operations. In addition, the type system provides infor- mation to the compiler so that it can perform standard numeric optimizations. 1 Designing the Numeric Tower From the classic two-line factorial program to financial applications to scientific com- putation to graphics software, programs rely on numbers and numeric computations. Because of this spectrum of numeric applications, programmers wish to use a wide vari- ety of numbers: the inductively defined natural numbers, fixed-width integers, floating- point numbers, complex numbers, etc. Supporting this variety demands careful attention to the design of programming languages that manipulate numbers. Most languages have taken one of two approaches to numbers. Many untyped lan- guages, drawing on the tradition of Lisp and Smalltalk, provide a hierarchy of numbers whose various levels can be freely used together, known as the numeric tower.
    [Show full text]
  • Object-Oriented Dynamic GIS for Transportation Planning Reginald
    Object-Oriented Dynamic GIS for Transportation Planning Reginald G Gotledge Working Paper UCTC No 3 37 The University of Califorma Trans portatlon Center Umve~-slty of Cahforma Berkeley, CA94720 The University of California Transportation Center The Umverslty of Cahforma Center actaVltles Researchers TransportaUon Center (UCTC) at other umversmes w~thmthe as one of ten regional umts regmn also have opportunmes mandated by Congress and to collaborate wxth UCfaculty established m FaII 1988 to on selected studms support research, educatmn, and trramng m surface trans- UCTC’seducauonal and portatmn The UC Center research programs are focused serves federal RegmnIX and on strategm planning for ~s supported by matching improwng metropol~tan grants from the U S Depart- accessibility, wath emphas~s ment of Transportatmn the on the specml condmons in Calfforma Department of Region IX Partacular attentmn Transportation (Caltrans), and as directed to strategms for the Umversaty using transportatmn as an instrument of economic Based on the Berkeley development, whale also ac- Campus, UCTCdraws upon commodating to the regmn s existing capabdatms and persastent expansmn and resources of the Insututes of whale mmntammgand enhanc- Transportatmn Studies at ing the quahty of hfe there Berkeley, Davas, Irvme, and Los Angeles, the Insutute of The Center dxstnbutes reports Urban and Regional Develop- on ~ts research m working ment at Berkeley, and several papers, monographs, and in academac departments at the reprints of pubhshedarticles Berkeley, Davas,
    [Show full text]
  • Disjoint Intersection Types: Theory and Practice
    Disjoint Intersection Types: Theory and Practice by Xuan Bi (毕旋) A thesis submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy at The University of Hong Kong December 2018 Abstract of thesis entitled “Disjoint Intersection Types: Theory and Practice” Submitted by Xuan Bi for the degree of Doctor of Philosophy at The University of Hong Kong in December 2018 Programs are hard to write. It was so 50 years ago at the time of the so-called software crisis; it still remains so nowadays. Over the years, we have learned—the hard way—that software should be constructed in a modular way, i.e., as a network of smaller and loosely connected modules. To facilitate writing modular code, researchers and software practitioners have developed new methodologies; new programming paradigms; stronger type systems; as well as better tooling support. Still, this is not enough to cope with today’s needs. Several reasons have been raised for the lack of satisfactory solutions, but one that is constantly pointed out is the inadequacy of existing programming languages for the construction of modular software. This thesis investigates disjoint intersection types, a variant of intersection types. Disjoint intersections types have great potential to serve as a foundation for powerful, flexible and yet type-safe and easy to reason OO languages, suitable for writing modular software. On the theoretical side, this thesis shows how to significantly increase the expressiveness of disjoint intersection types by adding support for nested composition, along with parametric polymor- phism. Nested composition extends inheritance to work on a whole family of classes, en- abling high degrees of modularity and code reuse.
    [Show full text]
  • The Grace Programming Language Draft Specification Version 0.5. 2025" (2015)
    Portland State University PDXScholar Computer Science Faculty Publications and Presentations Computer Science 2015 The Grace Programming Language Draft Specification ersionV 0.5. 2025 Andrew P. Black Portland State University, [email protected] Kim B. Bruce James Noble Follow this and additional works at: https://pdxscholar.library.pdx.edu/compsci_fac Part of the Programming Languages and Compilers Commons Let us know how access to this document benefits ou.y Citation Details Black, Andrew P.; Bruce, Kim B.; and Noble, James, "The Grace Programming Language Draft Specification Version 0.5. 2025" (2015). Computer Science Faculty Publications and Presentations. 140. https://pdxscholar.library.pdx.edu/compsci_fac/140 This Working Paper is brought to you for free and open access. It has been accepted for inclusion in Computer Science Faculty Publications and Presentations by an authorized administrator of PDXScholar. Please contact us if we can make this document more accessible: [email protected]. The Grace Programming Language Draft Specification Version 0.5.2025 Andrew P. Black Kim B. Bruce James Noble April 2, 2015 1 Introduction This is a specification of the Grace Programming Language. This specifica- tion is notably incomplete, and everything is subject to change. In particular, this version does not address: • James IWE MUST COMMIT TO CLASS SYNTAX!J • the library, especially collections and collection literals • static type system (although we’ve made a start) • module system James Ishould write up from DYLA paperJ • dialects • the abstract top-level method, as a marker for abstract methods, • identifier resolution rule. • metadata (Java’s @annotations, C] attributes, final, abstract etc) James Ishould add this tooJ Kim INeed to add syntax, but not necessarily details of which attributes are in language (yet)J • immutable data and pure methods.
    [Show full text]