DOCSLIB.ORG

A Module System for Mechanized Mathematics Systems Mei - a Module System for Mechanized Mathematics Systems

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A Module System for Mechanized Mathematics Systems Mei - a Module System for Mechanized Mathematics Systems MEI - A MODULE SYSTEM FOR MECHANIZED MATHEMATICS SYSTEMS MEI - A MODULE SYSTEM FOR MECHANIZED MATHEMATICS SYSTEMS By JIAN Xu, M.Sc. A Thesis Submitted to the School of Graduate Studies in partial fulfilment of the requirements for the degree of Ph.D. ©Copyright by Jian Xu, January 2008 ii Jian Xu - Ph.D. Thesis - Department of CAS, McMaster University PH.D. (2008) McMaster University (Computer Science) Hamilton, Ontario TITLE: Mei - A Module System for Mechanized Mathematics Systems AUTHOR: Jian Xu, M.Sc. (McMaster University, Canada) SUPERVISOR: Dr. William M. Farmer NUMBER OF PAGES: viii, 194 Abstract This thesis presents several module systems, in particular Mei and DMei, designed for mechanized mathematics systems. Mei is a ..\-calculus style module system that supports higher-order functors in a natural way. The semantics of functor application is based on substitution. A novel coercion mechanism integrates a parameter passing mechanism based on theory interpretations with simple ..\-calculus style higher-order functors. DMei extends Mei by supporting dependent functor types. Mei is the first module system that successfully supports both higher-order functors and a parameter passing mechanism based on theory interpretations. Ill Acknowledgments I would first like to express my sincere thanks and appreciation to my supervisor, Dr. William M. Farmer, for his insight, thoughtful guidance and constant encourage­ ment throughout my study. Thanks to the members of my Supervisor Committee: Dr. Jacques Carette, Dr. Tom Maibaum, and Dr. Jeffery I. Zucker, for many valuable discussions and com­ ments. Thanks to all my other professors for their help in these four years. Thanks to friends in ITC 206 for the time we shared together. Thanks to my brother, Qin, for his encouraging words "You might not be born to be creative, however you can work hard to be creative.". Thanks to my sister, Yanping, and my brother, Jianping for pushing me forward constantly. Last but not least, many thanks to my parents for their support, my daughters, Katie and Kasidy, for the happiness they brought to me, and my wife, Yan Li, for her love and encouragement. I am grateful to have been partially supported by postgraduate scholarships from the Natural Sciences and Engineering Research Council of Canada (NSERC) and Ontario Graduate Scholarships in Science and Technology (OGSST). IV Contents Abstract iii Acknowledgements iv 1 Introduction 1 1.1 Background study ........... 2 1.1.1 ML-family module systems .. 3 1.1.2 Algebraic specification systems 7 1. 2 Design goals . 10 1.3 Overview . 13 1.4 Major contributions . 15 2 A simple module system - Mei Basic 17 2.1 Informal presentation . 17 2 .1.1 Theories . 17 2.1.2 Theory extension, renaming, and union 20 2.1.3 Parameterized theories 24 2.2 Syntax ........ 29 2.3 Rules ............. 31 2.3.1 Rules for types . 31 2.3.2 Rules for typing module expressions . 31 2.4 Semantics . 33 2.4.1 Substitution of module expression . 33 2.4.2 Operational semantics ...... 34 2.4.3 Denotational semantics ...... 42 2.5 Issues about conservative extensions of theories 47 v vi Jian Xu - Ph.D. Thesis - Department of CAS, McMaster University 3 A module system with subtyping and coercion - Mei 49 3.1 Subtyping . 49 3.1.1 Naive subtyping rules .... 51 3.1.2 Algorithmic subtyping rules 51 3.1.3 New typing rule ..... 53 3.1.4 Instantiation of functors 54 3.2 Syntax of Mei Core . 54 3.3 Semantics of Mei Core . 57 3.4 Coercion . 62 3.4.1 Theory interpretation . 64 3.4.2 Views and coercions . 65 3.4.3 Extended module expressions 74 3.4.4 Coercion functor for general theory views . 74 3.4.5 Functor instantiation 75 3.5 Syntax of Mei . 77 3.6 Semantics of Mei 80 3.7 Casting ..... 81 4 A module system with bounded universal types - DMei 84 4.1 Motivation . 84 4.1.1 Type variables and new typing rules 85 4.1.2 Subtyping rules . 88 4.2 Syntax of DMei Core ... 96 4.3 Semantics of DMei Core . 104 4.4 Integration with coercion . 110 4.5 Tradeoff between Mei and DMei 116 4.6 A simplified module system with dependent functor types - SDMei 116 4.6.1 Motivation. 116 4.6.2 Intuition ......... 117 4.6.3 SDMei Core ....... 118 4.6.4 Integration with coercion . 119 5 Comparison of Mei with other module systems 120 5.1 ML-family module systems .... 120 5.2 Algebraic specification languages 121 5.2.1 Maude . 121 5.2.2 Specware 126 CONTENTS vii 5.2.3 CASL ....................... 128 5.2.4 An algebraic framework for higher-order modules. 130 5.3 Theorem provers 133 5.3.1 IMPS 133 5.3.2 PVS .. 135 5.3.3 Isabelle 137 5.3.4 Coq .. 139 5.3.5 Automath 139 5.4 Computer algebra systems 141 5.4.1 Maple .... 141 5.4.2 Mathematica 143 5.4.3 Axiom 144 5.4.4 Aldor 147 5.4.5 Focal . 149 5.4.6 Magma 151 5.5 An expressive language of signatures 152 6 Possible extensions of Mei 154 6.1 Theory definition . 154 6.2 Hiding and revealing 155 6.3 Local theories . 157 6.4 Functor composition 158 6.5 View lifting, view union, and view composition . 159 7 A structural implementation of Mei 161 7.1 Structure of the implementation . 161 7.2 Identifiers .......... 163 7.3 Abstract syntax for MMS .. 164 7.4 Abstract syntax for Mei Core 166 7.5 Environment and context ... 168 7.6 Type checking and evaluation of Mei Core 169 7. 7 Theory translation . 173 7.8 Abstract syntax for Mei ......... 174 7. 9 An application over a system of first-order logic 176 8 A module system for multi-logic MMSs 179 viii Jian Xu - Ph.D. Thesis - Department of CAS, McMaster University 9 Conclusion and future work 183 Chapter 1 Introduction A mechanized mathematics system (MMS) is a computer system that supports and improves mathematical processing, by which we mean building mathematical models of the real world, and formulating and reasoning about properties of the real world within the context of the mathematical models. Examples of MMSs are theorem provers and computer algebra systems. Although it is important for an MMS to have an expressive and practical logic, an efficient proof engine, and a friendly user interface, it is barely useful without a powerful library. A powerful library for an MMS should (1) contain sufficient mathematical knowledge to support mathematical activities, and (2) be well organized so that new knowledge can be easily developed from existing knowledge. Currently, more and more mathematical knowledge is being formalized in different systems, which largely achieves the first goal. Thus, a good module system is necessary for MMSs in order to organize this mathematical knowl­ edge. A good modularity mechanism aids the expressivity of MMSs. It helps to build up contexts and allows the user to reuse the theorems developed within one context in other contexts with similar structure. However, the development of the module sys­ tems for MMSs significantly lags behind the development of underlying logics, proof strategies, computational power, algorithms etc. Very few MMSs have a sophisti­ cated module system that supports the development of large pieces of mathematical knowledge. In this thesis, we will present several related module systems designed for MMSs. In this chapter, we will investigate some existing module systems, present our design goals, give an overview of our systems, and state our major contribution. 1 2 Jian Xu - Ph.D. Thesis - Department of CAS, McMaster University 1.1 Background study Most programming languages and specification languages have module systems for organizing large software developments and specifications. In this section we will review two families of module systems, namely, the ML-family module systems and the algebraic specification module systems. Modular programming is a way to structure a large software system consisting of a collection of small pieces of codes. Though modular programming can be done in any programming language with sufficient discipline from programmers [75], many modern languages provide facilities for expressing and automatically checking their modular structures. The module systems of programming languages emphasize the decomposition of a large software development into smaller components. Code reuse and parallel software development are important for them. On the one hand, it is desirable to decompose programs into modules that are as independent as possible. On the other hand, these modules have to interact within some program, which requires an interface to express the essential information for communication. Among many modular mechanisms, the ML-family module systems are of particular interest because it treats parameterized modules as functors, i.e. functions from modules to modules. The module system itself is a small typed functional language, where structures and functors are objects and signatures are types. Hence researchers in this area enjoy a type-theoretic formalism approach to their module system [47, 57]. There are efforts to extend proof assistant systems with an ML-family module system, e.g. in Coq [18]. Algebraic specification languages are another area enjoying modularity. The mod­ ule systems of specification languages stress a refinable way of specification develop­ ments. Theories and axioms are important for them; however, logical reasoning is not one of their concerns. A module of a specification language is an algebraic speci­ fication consisting of a signature and a set of axioms, roughly equal to our definition of a theory. The researchers in this area favour a category-theoretic approach where specification morphism (or simply morphism) plays a central role. A morphism is a homomorphic map from the sorts and operators of one specification to the sorts and operators of another such that axioms of the source specification are translated to axioms (or more generally, theorems) of the target specification.
Load more

Recommended publications
  • Design and Implementation of Generics for the .NET Common Language Runtime
    Design and Implementation of Generics for the .NET Common Language Runtime Andrew Kennedy Don Syme Microsoft Research, Cambridge, U.K. fakeÒÒ¸d×ÝÑeg@ÑicÖÓ×ÓfغcÓÑ Abstract cally through an interface definition language, or IDL) that is nec- essary for language interoperation. The Microsoft .NET Common Language Runtime provides a This paper describes the design and implementation of support shared type system, intermediate language and dynamic execution for parametric polymorphism in the CLR. In its initial release, the environment for the implementation and inter-operation of multiple CLR has no support for polymorphism, an omission shared by the source languages. In this paper we extend it with direct support for JVM. Of course, it is always possible to “compile away” polymor- parametric polymorphism (also known as generics), describing the phism by translation, as has been demonstrated in a number of ex- design through examples written in an extended version of the C# tensions to Java [14, 4, 6, 13, 2, 16] that require no change to the programming language, and explaining aspects of implementation JVM, and in compilers for polymorphic languages that target the by reference to a prototype extension to the runtime. JVM or CLR (MLj [3], Haskell, Eiffel, Mercury). However, such Our design is very expressive, supporting parameterized types, systems inevitably suffer drawbacks of some kind, whether through polymorphic static, instance and virtual methods, “F-bounded” source language restrictions (disallowing primitive type instanti- type parameters, instantiation at pointer and value types, polymor- ations to enable a simple erasure-based translation, as in GJ and phic recursion, and exact run-time types.
    [Show full text]
  • Orthogonal to the Java Imperative?
    Orthogonal to the Java Imperative? Suad Alagi´c, Jose Solorzano, and David Gitchell Department of Computer Science, Wichita State University Wichita, KS 67260-0083, USA [email protected] Abstract. Three nontrivial limitations of the existing JavaTM technol- ogy are considered from the viewpoint of object-oriented database tech- nology. The limitations are: lack of support for orthogonal persistence, lack of parametric (and in fact bounded and F-bounded) polymorphism and lack of an assertion (constraint) language. These limitations are over- come by leaving Java as it is, and developing a declarative (query in par- ticular) component of the Java technology. This declarative language is implemented on top of the Java Virtual Machine, extended with orthog- onal and transitive persistence. The model of persistence also features complex name space management. Keywords: Declarative languages, orthogonal persistence, F-bounded polymorphism, Java Virtual Machine. 1 Introduction In spite of the fact that JavaTM [17] is a product of good language design, it exhibits several serious limitations with respect to object-oriented database management. A perfectly valid justification is that it was probably never con- ceived as a database programming language. Yet, some of these database-critical features are important for object-oriented programming in general. The first such limitation is, of course, the lack of support for persistence. Persistence is a key feature of object-oriented database technology [10]. The second limitation is the absence of parametric polymorphism. This lim- itation is particularly critical in database management because most database technologies rely heavily on collections. Static typing of collections in Java is impossible, and so is static typing of queries.
    [Show full text]
  • Bounded Quantification for Gradual Typing
    Bounded Quantification for Gradual Typing Harley Eades III and Michael Townsend Computer and Information Sciences Augusta University Augusta, USA [email protected] Abstract. In an earlier paper we introduce a new categorical model based on retracts that combines static and dynamic typing. We then showed that our model gave rise to a new and simple type system which combines static and dynamic typing. In this paper, we extend this type system with bounded quantification and lists, and then develop a grad- ually typed surface language that uses our new type system as a core casting calculus. Finally, we prove the gradual guarantee as put forth by Siek et al. 1 Introduction In a previous paper the authors [?] show that static and dynamic typing can be combined in a very simple and intuitive way by combining the work of Scott [13] and Lambek [9] on categorical models of the untyped and typed λ-calculus, respectively. First, add a new type ? read \the type of untyped programs" { also sometimes called the unknown type { and then add four new programs split :? ! (? ! ?), squash : (? ! ?) ! ?, boxC : C ! ?, and unboxC :? ! C , such that, squash; split = id?!? and boxC ; unboxC = idC . Categorically, split and squash, and box and unbox form two retracts. Then extending the simply typed λ-calculus with these two retracts results in a new core casting calculus, called Simply Typed Grady, for Siek and Taha's gradual functional type system [16]. Furthermore, the authors show that Siek and Taha's system can be given a categorical model in cartesian closed categories with the two retracts.
    [Show full text]
  • Aggregate Programming in Scala: a Core Library and Actor-Based Platform for Distributed Computational Fields
    Alma Mater Studiorum Universita` di Bologna Campus di· Cesena Scuola di Ingegneria e Architettura Corso di Laurea Magistrale in Ingegneria e Scienze Informatiche Aggregate Programming in Scala: a Core Library and Actor-Based Platform for Distributed Computational Fields Tesi in Ingegneria dei Sistemi Software Adattativi Complessi Relatore: Presentata da: Prof. MIRKO VIROLI ROBERTO CASADEI Anno Accademico 2014-2015 Sessione III Contents Abstract (italiano) i Abstract iii Introduction v I Background: Scala for Library Development 1 1 Advanced Scala Features 3 1.1 The Scala programming language...................3 1.2 On object-oriented programming and traits..............4 1.2.1 OOP in Scala: a quick tour of the basics...........4 1.2.2 Traits..............................7 1.2.3 Class construction and linearisation..............9 1.2.4 Traits: member overriding and super resolution....... 10 1.2.5 Trait instantiation, refinement, early definitions....... 11 1.3 The Scala type system......................... 12 1.3.1 Some preparatory definitions.................. 12 1.3.2 Advanced types......................... 13 1.4 Generic programming in Scala..................... 16 1.4.1 Type parameters........................ 17 1.4.2 Type bounds (bounded quantification)............ 17 1.4.3 Type variance.......................... 18 1.4.4 Abstract types vs. type parameters.............. 20 1.5 Implicits................................. 21 1.5.1 Implicit scope.......................... 22 CONTENTS 1.5.2 Implicit classes......................... 24 1.5.3 More on implicits........................ 25 2 Advanced Scala Techniques 29 2.1 \Pimp my library" pattern....................... 29 2.2 Type classes............................... 31 2.3 Component modelling and implementation.............. 32 2.4 Cake Pattern.............................. 35 2.5 Family polymorphism.......................... 38 2.6 Internal DSL development......................
    [Show full text]
  • Using Kinds to Type Partially-Polymorphic Methods
    Electronic Notes in Theoretical Computer Science 75 (2003) URL: http://www.elsevier.nl/locate/entcs/volume75.html 20 pages Using kinds to type partially-polymorphic methods Daniel Bonniot 1 INRIA Rocquencourt France Abstract We extends type constraints with kind constraints to increase the expressiveness of constraint-based nominal type systems. In the context of object-oriented program- ming languages, they offer an alternative to the use of F-bounded polymorphism to type homogeneous binary methods. We also introduce the notion of partially poly- morphic methods to describe a common situation in object oriented hierarchies, and show how these can be typed in a modular fashion with kind constraints. 1 Introduction Static typing provides early detection and prevention of errors, resulting in increased software quality and lower production costs. Since the set of error- free programs is undecidable for Turing complete programming languages, type systems can only define an approximation of error-free programs —that is, a subset of them, to remain safe. However, one may also be less ambitious, and let some kind of anomalies, such as downward casts, exhaustiveness of pattern matching or exceptions handlers, be only detected dynamically. Each of these anomalies can then be tackled separately, either by some other form of static analysis or by a specific extension to the type system. Functional style and object-oriented style are two of the most popular programming paradigms at the moment. However, their type systems have been developed in rather different directions. While functional languages, as incarnated by ML, are based on the polymorphic, unconstrained Hindley- Milner type system, type systems for object-oriented languages such as Java or C# often lack polymorphism and higher-order functions but include sub- typing.
    [Show full text]
  • Inheritance, Generics and Binary Methods in Java Herencia, Genéricos Y Métodos Binarios En Java
    Computación y Sistemas. Vol. 7 No. 2 pp. 113 - 122 © 2003, CIC-IPN, ISSN 1405-5546 Impreso en México Inheritance, Generics and Binary Methods in Java Herencia, Genéricos y Métodos Binarios en Java María Lucía Barrón-Estrada (1) and Ryan Stansifer (2) (1) Departamento de Sistemas y Computación Instituto Tecnológico de Culiacán Culiacán, Sin. CP 80220 México (2) Computer Science Department Florida Institute of Technology University Blvd.. Melbourne, FL 32901 [email protected], [email protected] Abstract Java has adopted a mechanism to support parameterized types that will be available in the next major release. A draft specification to add generics to the JavaTM Programming Language was published two years ago [1] and a new version of it in June 23, 2003 [2]. An extension of the type system based on F-bounded quantification is proposed. A binary method is a method that has one or more parameters of the same type as the object that receives the message. F-Bounded polymorphism and binary methods can’t be combined smoothly in object-oriented languages with nominal subtyping and single dispatch [3]. In this paper, we address some problems that can arise when binary methods are needed in parameterized classes and interfaces in the implementation of a Java program. Keywords: Binary methods, Inheritance, Java, Parameterized types. Resumen El lenguaje de programación Java ha adoptado un mecanismo para definir tipos parametrizados, el cual estará disponible para los usuarios en la próxima versión de su compilador. La primera especificación formal para incluir genéricos en Java fue publicada hace dos años y una nueva versión el pasado mes de Junio del 2003.
    [Show full text]
  • Row and Bounded Polymorphism Via Disjoint Polymorphism Ningning Xie the University of Hong Kong, Hong Kong, China [email protected] Bruno C
    Row and Bounded Polymorphism via Disjoint Polymorphism Ningning Xie The University of Hong Kong, Hong Kong, China [email protected] Bruno C. d. S. Oliveira The University of Hong Kong, Hong Kong, China [email protected] Xuan Bi The University of Hong Kong, Hong Kong, China [email protected] Tom Schrijvers KU Leuven, Belgium [email protected] Abstract Polymorphism and subtyping are important features in mainstream OO languages. The most common way to integrate the two is via F<: style bounded quantification. A closely related mechanism is row polymorphism, which provides an alternative to subtyping, while still enabling many of the same applications. Yet another approach is to have type systems with intersection types and polymorphism. A recent addition to this design space are calculi with disjoint intersection types and disjoint polymorphism. With all these alternatives it is natural to wonder how they are related. This paper provides an answer to this question. We show that disjoint polymorphism can recover forms of both row polymorphism and bounded polymorphism, while retaining key desirable properties, such as type-safety and decidability. Furthermore, we identify the extra power of disjoint polymorphism which enables additional features that cannot be easily encoded in calculi with row polymorphism or bounded quantification alone. Ultimately we expect that our work is useful to inform language designers about the expressive power of those common features, and to simplify implementations and metatheory of feature-rich languages with
    [Show full text]
  • CSCE 314 Programming Languages Java Generics I
    CSCE 314 Programming Languages ! Java Generics I Dr. Hyunyoung Lee ! !1 Lee CSCE 314 TAMU Java Generics: History Pizza: 1996-97, extended Java with generics, function pointers, class cases and pattern matching. GJ: 1998 derivative of Pizza; Generics the only extension. Java 1.5: 2004. Modeled after GJ. PolyJ: 1997, would have required changes to JVM. NextGen: 1998, avoids oddities of type erasure, still compatible with JVM and existing binaries. Extension of GJ. !2 Lee CSCE 314 TAMU Java Generics: Motivation Typesafe polymorphic containers what happens Without generics: without type cast? List l = new LinkedList(); l.add(new Integer(0)); Integer x = (Integer) l.iterator().next(); // need type cast String s = (String) l.iterator().next(); // bad cast exception With generics: List<Integer> l = new LinkedList<Integer>(); l.add(new Integer(0)); Integer x = l.iterator().next(); // no need for type cast String x = l.iterator().next(); // compile−time error !3 Lee CSCE 314 TAMU Parameterized Classes public class Pair<T, U> { //T, U: type variables, also formal type parameters private T a; private U b; public Pair(T t, U u) { a = t; b = u; } public T getFirst() { return a; } public U getSecond() { return b; } } Pair<Integer, String> p = new Pair<Integer, String>(0, ""); // Pair<Integer, String> is an invocation/instance of the generic type // declaration with actual type arguments. Compare to Haskell: data Pair a b = Pair a b “Parametric polymorphism” getFirst :: Pair a b -> a Generics in object oriented getFirst (Pair x y) = x programming :
    [Show full text]
  • F-Bounded Polymorphism for Object-Oriented Programming
    F-Bounded Polymorphism for Object-Oriented Programming Peter Canning, William Cook, Walter Hill, Walter Oltho® Hewlett-Packard Laboratories P.O. Box 10490, Palo Alto, CA 94303-0971 John C. Mitchell Department of Computer Science Stanford University, Stanford, CA 94309 Abstract ing was identi¯ed as an important form of polymor- phism in object-oriented programs. This lead to the Bounded quanti¯cation was introduced by Cardelli and development of \bounded quanti¯cation" in [7]. If we Wegner as a means of typing functions that operate uni- view objects as elements of non-recursive record types, formly over all subtypes of a given type. They de¯ned then bounded quanti¯cation provides a useful form of a simple \object" model and used bounded quanti¯ca- polymorphism over objects. However, a more sophis- tion to type-check functions that make sense on all ob- ticated presentation of object-oriented constructs (as jects having a speci¯ed set of \attributes." A more re- in [5, 11, 10]) would allow objects that are elements alistic presentation of object-oriented languages would of recursively-de¯ned types. With recursive types, the allow objects that are elements of recursively-de¯ned Cardelli-Wegner form of bounded quanti¯cation is not types. In this context, bounded quanti¯cation no longer su±ciently expressive to meet its original goal. serves its intended purpose. It is easy to ¯nd func- F-bounded quanti¯cation is a natural extension of tions that makes sense on all objects having a speci- bounded quanti¯cation that seems particularly useful ¯ed set of methods, but which cannot be typed in the in connection with recursive types.
    [Show full text]
  • Programming Language Evolution
    UCAM-CL-TR-902 Technical Report ISSN 1476-2986 Number 902 Computer Laboratory Programming language evolution Raoul-Gabriel Urma February 2017 15 JJ Thomson Avenue Cambridge CB3 0FD United Kingdom phone +44 1223 763500 http://www.cl.cam.ac.uk/ c 2017 Raoul-Gabriel Urma This technical report is based on a dissertation submitted September 2015 by the author for the degree of Doctor of Philosophy to the University of Cambridge, Hughes Hall. Technical reports published by the University of Cambridge Computer Laboratory are freely available via the Internet: http://www.cl.cam.ac.uk/techreports/ ISSN 1476-2986 Abstract Programming languages are the way developers communicate with computers|just like natural languages let us communicate with one another. In both cases multiple languages have evolved. However, the programming language ecosystem changes at a much higher rate compared to natural languages. In fact, programming languages need to constantly evolve in response to user needs, hardware advances and research developments or they are otherwise displaced by newcomers. As a result, existing code written by developers may stop working with a newer language version. Consequently, developers need to search (analyse) and replace (refactor) code in their code bases to support new language versions. Traditionally, tools have focused on the replace aspect (refactoring) to support de- velopers evolving their code bases. This dissertation argues that developers also need machine support focused on the search aspect. This dissertation starts by characterising factors driving programming language evolu- tion based on external versus internal forces. Next, it introduces a classification of changes introduced by language designers that affect developers.
    [Show full text]
  • A Path to DOT: Formalizing Fully Path-Dependent Types
    A Path To DOT: Formalizing Fully Path-Dependent Types MARIANNA RAPOPORT, University of Waterloo, Canada ONDŘEJ LHOTÁK, University of Waterloo, Canada The Dependent Object Types (DOT) calculus aims to formalize the Scala programming language with a focus on path-dependent types — types such as x:a1 ::: an :T that depend on the runtime value of a path x:a1 ::: an to an object. Unfortunately, existing formulations of DOT can model only types of the form x:A which depend on variables rather than general paths. This restriction makes it impossible to model nested module dependencies. Nesting small components inside larger ones is a necessary ingredient of a modular, scalable language. DOT’s variable restriction thus undermines its ability to fully formalize a variety of programming-language features including Scala’s module system, family polymorphism, and covariant specialization. This paper presents the pDOT calculus, which generalizes DOT to support types that depend on paths of arbitrary length, as well as singleton types to track path equality. We show that naive approaches to add paths to DOT make it inherently unsound, and present necessary conditions for such a calculus to be sound. We discuss the key changes necessary to adapt the techniques of the DOT soundness proofs so that they can be applied to pDOT. Our paper comes with a Coq-mechanized type-safety proof of pDOT. With support for paths of arbitrary length, pDOT can realize DOT’s full potential for formalizing Scala-like calculi. Additional Key Words and Phrases: DOT, Scala, dependent types, paths 1 INTRODUCTION Path-dependent types embody two universal principles of modular programming: abstraction and composition.
    [Show full text]
  • Row and Bounded Polymorphism Via Disjoint Polymorphism Ningning Xie the University of Hong Kong, Hong Kong, China [email protected] Bruno C
    Row and Bounded Polymorphism via Disjoint Polymorphism Ningning Xie The University of Hong Kong, Hong Kong, China [email protected] Bruno C. d. S. Oliveira The University of Hong Kong, Hong Kong, China [email protected] Xuan Bi The University of Hong Kong, Hong Kong, China [email protected] Tom Schrijvers KU Leuven, Belgium [email protected] Abstract Polymorphism and subtyping are important features in mainstream OO languages. The most common way to integrate the two is via F<: style bounded quantification. A closely related mechanism is row polymorphism, which provides an alternative to subtyping, while still enabling many of the same applications. Yet another approach is to have type systems with intersection types and polymorphism. A recent addition to this design space are calculi with disjoint intersection types and disjoint polymorphism. With all these alternatives it is natural to wonder how they are related. This paper provides an answer to this question. We show that disjoint polymorphism can recover forms of both row polymorphism and bounded polymorphism, while retaining key desirable properties, such as type-safety and decidability. Furthermore, we identify the extra power of disjoint polymorphism which enables additional features that cannot be easily encoded in calculi with row polymorphism or bounded quantification alone. Ultimately we expect that our work is useful to inform language designers about the expressive power of those common features, and to simplify implementations and metatheory of feature-rich languages with
    [Show full text]