From Functional Programming to Program Proof Or: the Continuation of ML by Other Means

From functional programming to program proof or: The continuation of ML by other means Xavier Leroy INRIA Paris-Rocquencourt Journ´eesd'Informatique Fondamentale de Paris Diderot, 2013-04-26 Part I The legacy of ML In the beginning. JOURNAL OF COMPUTER AND SYSTEM SCIENCES 17, 348-375 (1978) A Theory of Type Polymorphism in Programming ROBIN MILNER Computer Science Department, Vm+ersity of Edinburgh, Edinburgh, Scotland Received October 10, 1977; revised April 19, 1978 Principal type-schemes for functional programs The aim of this work is largely a practical one. A widely employed style of programming, Luis Darnas* and Robin Milne~ particularly in structure-processing languages which impose no discipline of types, Edinburgh University entails defining procedures which work well on objects of a wide variety. We present a formal type discipline for such polymorphic procedures in the context of a simple programming language, and a compile time type-checking algorithm w which enforces the discipline. A Semantic Soundness Theorem (based on a formal semantics for the language) 1. Introduction of successful use of the language, both in LCF and states that well-type programs cannot “go wrong” and a Syntactic Soundness Theorem states that if fl accepts a program then it is well typed. We also discuss extending these This paper is concerned with the polymorphic other research and in teaching to undergraduates, results to richer languages; a type-checking algorithm based on w is in fact already type discipline of NL, which is a general purpose it has become important to answer these questions - implemented and working, for the metalanguage ML in the Edinburgh LCF system, functional programming language, although it was particularly because the combination of flexibility first introduced as a metalanguage (whence its (due to polymorphism) , robustness (due to semantic name) for conducting proofs in the LCF proof system soundness) and detection of errors at compile time 1. INTRODUCTION [GMW] . The type discipline was studied in [Mil] , has proved to be one of the strongest aspects of ML. aim where it was shown to be semantically sound, in a The of this work is largely a practical one. A widely employed style of programming, The discipline can be well illustrated by a particularly in structure-processing languages which impose no discipline of types sense made precise below, but where one important small example. Let us define in ML the function (LISP is a perfect example), entails defining procedures which work well on objects of question was left open: does the type-checking “map”, which maps a given function over a given list a wide variety (e.g., on lists of atoms, integers, or lists). Such flexibility is almost essential algorithm - or more precisely, the type assignment in this style of programming; unfortunately one often pays a price for it in the time taken - that is, algorithm (since types are assigned by the compiler, to find rather inscrutable bugs-anyone who mistakenly applies CDR to an atom in map f [xl;. ..;xn] = [f(xl); . .. f(xn)] LISP, and finds himself absurdly adding a property list to an integer, will know the and need not be mentioned by the programmer) - find The required declaration is symptoms. On the other hand a type discipline such as that of ALGOL 68 [22] which the most general type possible for every expression s then nil letrec map f s = —if null precludes the flexibility mentioned above, also precludes the programming (POPLstyle which 1982) and declaration? Here we answer the question in else cons(f (hd s)) (map f (tl s)) we are talking about. ALGOL 60 was more flexible-in that it required procedure the affirmative, for the purely applicative part parameters to be specified only as “procedure” (rather than say “integer to realprocedure”) The type-checker will deduce a type-scheme for “map” of ML. It follows immediately that it is decid- -but the flexibility was not uniform, and not sufficient. from existing type-schemes for “null”, “nil”, “cons”, able whether a program is well-typed, in contrast An early discussion of such flexibility can be found in Strachey [19], who was probably “hd” and “tl”; the term “type-scheme” is appropriate the first to call it polymorphism. In fact he qualified it as “parametric” polymorphism, with the elegant and slightly more permissive type since all these objects are polymorphic. In fact, in contrast to what he called “adhoc” polymorphism. An example of the latter is the use discipline of Coppo [Cop] . After several years from of “+” to denote both integer and real addition (in fact it may be further extended to * The work of this author is supported by the denote complex addition, vector addition, etc.); this use of an identifier at several distinct Portuguese Instituto National de Investigacao null : Va(a list+ bool) Cientifica. types is often now called “overloading,” and we are not doncerned with it in this paper. nil : Va(a list) Permksion to copy without fee all or part of this material k granted In this paper then, we present and justify one method of gaining type flexibility, but cons : Va(a + (a list + u list)) provided that the copies are not made ordktributed fordkect also retaining a discipline which ensures robust programs. We have evidence that this commercial advantage, the ACM copyright notice and the title of the hd : Va(u list + a) publication and ha date appear, and notice k given that copying is by 348 permission of the Association for Computing Machinery. To copy tl : VU([ list + a list) 0022-0000/78/0173-0348$02.00/0 otherwise, or to republish, requires a fee and/or specific permission. Copyright 8 1978 by Academic Press, Inc. will be deduced All rights of reproduction in any form reserved. @ 1982 ACM O-89791-065-6/82/OOl/0207 $00.75 maP : V’WV(3 (u + !3) + (a list+5 list) . 207 Core ML Hindley-Milner polymorphic types Damas-Milner type inference First-class Datatypes and functions pattern-matching Things we learned from Core ML Strong static typing is the programmer's friend. Types need not be verbose. Explicit types as documentation (datatypes, interfaces). Types are compatible with code reuse. Opportunities for reuse can be discovered rather than planned. Not just type safety, but also exhaustiveness checks. A rich lineage Agda SASL Miranda Haskell Haskell98 LazyML Hope Alice LCF ML SML90 SML97 Lisp MoscowML CAML Caml Light OCaml F# 1980{2000: a ﬂurry of type systems Type more features; type them more precisely. Type other programming paradigms (OO, distributed). Typed intermediate & assembly languages. http://upload.wikimedia.org/wikipedia/commons/c/c5/Potenti... (Core ML as the bottom of a potential well.) 1 of 1 13/4/12 15:36 Principal types or not? Beauty can also arise from formal constraints. Novel approaches driven by principality Exhibit A: Haskell's type classes. How to make ad-hoc polymorphism less ad hoc Philip Wadler and Stephen Blott University of Glasgow* Abstract ML [HMM86, Mi187], Mirandal[Tur85], and other languages. On the other hand, there is no widely This paper presents type classes, a new approach accepted approach to ad-hoc polymorphism, and so to ad-hoc polymorphism. Type classes permit over- its name is doubly appropriate. loading of arithmetic operators such as multiplica- This paper presents type classes, which extend the tion, and generalise the “eqtype variables” of Stan- Hindley/Milner type system to include certain kinds dard ML. Type classes extend the Hindley/Milner of overloading, and thus bring together the two sorts polymorphic type system, and provide a new ap- of polymorphism that Strachey separated. proach to issues that arise in object-oriented pro- The type system presented here is a generalisa- gramming, bounded type quantification, and ab- tion of the Hindley/Milner type system. As in that stract data types. This paper provides an informal system, type declarations can be inferred, so explicit introduction to type classes, and defines them for- type declarations for functions are not required. Dur- mally by means of type inference rules. ing the inference process, it is possible to translate a program using type classes to an equivalent program that does not use overloading. The translated pro- 1 Introduction grams are typable in the (ungeneralised) Hindley/ Milner type system. Strachey chose the adjectives ad-hoc and panzmelric The body of this paper gives an informal introduc- to distinguish two varieties of polymorphism [Str67]. tion to type classes and the translation rules, while Ad-hoc polymorphism occurs when a function is an appendix gives formal rules for typing and trans- defined over several diflerent types, acting in a dif- lation, in the form of inference rules (as in [DM82]). ferent way for each type. A typical example is The translation rules provide a semantics for type overloaded multiplication: the same symbol may be classes. They also provide one possible implementa- used to denote multiplication of integers (as in 3*3) tion technique: if desired, the new system could be and multiplication of floating point values (as in added to an existing language with Hindley/Milner 3.14*3.14). types simply by writing a pre-processor. Parametric polymorphism occurs when a function Two places where the issues of ad-hoc polymor- is defined over a range of types, acting in the same phism arise are the definition of operators for arith- way for each type. A typical example is the length metic and equality. Below we examine the ap- function, which acts in the same way on a list of proaches to these three problems adopted by Stan- integers and a list of floating point numbers. dard ML and Miranda; not only do the approaches One widely accepted approach to parametric differ between the two languages, they also differ polymorphism is the Hindley/Milner type system within a single language.

Load more