DOCSLIB.ORG

GOOL: a Generic Object-Oriented Language (Extended Version)

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
GOOL: a Generic Object-Oriented Language (Extended Version) GOOL: A Generic Object-Oriented Language (extended version) Jacques Carette Brooks MacLachlan W. Spencer Smith Department of Computing and Department of Computing and Department of Computing and Software Software Software McMaster University McMaster University McMaster University Hamilton, Ontario, Canada Hamilton, Ontario, Canada Hamilton, Ontario, Canada [email protected] [email protected] [email protected] Abstract it to the others. Of course, this can be made to work — one We present GOOL, a Generic Object-Oriented Language. It could engineer a multi-language compiler (such as gcc) to demonstrates that a language, with the right abstractions, de-compile its Intermediate Representation (IR) into most can capture the essence of object-oriented programs. We of its input languages. The end-results would however be show how GOOL programs can be used to generate human- wildly unidiomatic; roughly the equivalent of a novice in a readable, documented and idiomatic source code in multi- new (spoken) language “translating” word-by-word. ple languages. Moreover, in GOOL, it is possible to express What if, instead, there was a single meta-language de- common programming idioms and patterns, from simple signed to embody the common semantic concepts of a num- library-level functions, to simple tasks (command-line argu- ber of OO languages, encoded so that the necessary informa- ments, list processing, printing), to more complex patterns, tion for translation is present? This source language could such as methods with a mixture of input, output and in-out be agnostic about what eventual target language will be used parameters, and finally Design Patterns (such as Observer, – and free of the idiosyncratic details of any given language. State and Strategy). GOOL is an embedded DSL in Haskell This would be quite the boon for the translator. In fact, we that can generate code in Python, Java, C#, and C++. could go even further, and attempt to teach the translator about idiomatic patterns of each target language. Keywords Code Generation, Domain Specific Language, Trying to capture all the subtleties of each language is Haskell, Documentation hopeless — akin to capturing the rhythm, puns, metaphors, similes, and cultural allusions of a sublime poem in transla- 1 Introduction tion. But programming languages are most often used for Java or C#? At the language level, this is close to a non- much more prosaic tasks: writing programs for getting things question: the two languages are so similar that only issues done. This is closer to translating technical textbooks, mak- external to the programming language itself would be the ing sure that all of the meaningful material is preserved. deciding factor. Unlike say the question “C or Prolog?”, which Is this feasible? In some sense, this is already old hat: is almost non-sensical, as the kinds of applications where modern compilers have a single IR, used to target multiple each is well-suited are vastly different. But, given a single processors. Compilers can generate human-readable sym- paradigm, for example object-oriented (OO), would it be bolic assembly code for a large family of CPUs. But this is not possible to write a unique meta-language that captures the the same as generating human-readable, idiomatic high-level essence of writing OO programs? After all, they generally all code. contain (mutable) variables, statements, conditionals, loops, More precisely, we are interested in capturing the con- arXiv:1911.11824v1 [cs.PL] 26 Nov 2019 methods, classes, objects, and so on. ceptual meaning of OO programs, in such a way as to fully Of course, OO programs written in different languages automate the translation from the “conceptual” to human- appear, at least at the surface, to be quite different. But this readable, idiomatic code, in mainstream languages. is mostly because the syntax of different programming lan- At some level, this is not new. Domain-Specific Languages guages is different. Are they quite so different in the utter- (DSL), are high-level languages with syntax and semantics ances that one can say in them? In other words, are OO tailored to a specific domain [18]. A DSL abstracts over the de- programs akin to sentences in Romance languages (French, tails of “code”, providing notation to specify domain-specific Spanish, Portugese, etc) which, although different at a sur- knowledge in a natural manner. DSL implementations often face level, are structurally very similar? work via translation to a GPL for execution. Some generate This is what we set out to explore. One non-solution is to human-readable code [5, 12, 19, 25]. find an (existing) language and try to automatically translate This is what we do, for the domain of OO programs. We have a set of new requirements: PL’20, , 2020. 1. The generated code should be human-readable, 1 2. The generated code should be idiomatic, look at JVM bytecode, and few C++ programmers at assembly. 3. The generated code should be documented, But GOOL’s aim is different: to allow writing high-level OO 4. The generator expresses common OO patterns. code once, but have it be available in many GPLs. One use Here we demonstrate that all of these requirements can be case would be to generate libraries of utilities for a narrow met. While designing a generic OO language is a worthwhile domain. As needs evolve and language popularity changes, endeavour, we had a second motive: we needed a means to it is useful to have it immediately available in a number do exactly that as part of our Drasil project [23, 24]. The of languages. Another use, which is core to our own moti- idea of Drasil is to generate all the requirements documenta- vation as part of Drasil [23, 24], is to have extremely well tion and code from expert-provided domain knowledge. The documented code, indeed to a level that would be unrealistic generated code needs to be human readable so that experts to do by hand. But this documentation is crucial in domains can certify that it matches their requirements. We largely where certification is required. And readable is a proxy for rewrote SAGA [5] to create GOOL1. GOOL is implemented understandable, which is also quite helpful for debugging. as a DSL embedded in Haskell that can currently generate The same underlying reasons for readable also drive id- code in Python, Java, C#, and C++. Others could be added, iomatic and documented, as they contribute to the human- with the implementation effort being commensurate to the understandability of the generated code. idiomatic is impor- (semantic) distance to the languages already supported. tant as many human readers would find the code “foreign” First we expand on the high-level requirements for such an otherwise, and would not be keen on using it. Note that endeavour, in Section2. To be able to give concrete examples, documentation can span from informal comments meant for we show the syntax of GOOL in Section3. The details of the humans, to formal, structured comments useful for generat- implementations, namely the internal representation and the ing API documentation with tools like Doxygen, or with a family of pretty-printers, is in Section4. Common patterns variety of static analysis tools. Readability (and thus under- are illustrated in Section5. We close with a discussion of standability) are improved when code is pretty-printed [7]. related work in Section6, plans for future improvements in Thus taking care of layout, redundant parentheses, well- Section7, and conclusions in Section8. chosen variable names, using a common style with lines that Note that a short version of this paper [16] will be pub- are not too long, are just as valid for generated code as for lished at PEPM 2020. The text in both version differs many human-written code. GOOL does not prevent users from places (other than just in length), but do not differ in mean- writing undocumented or complex code, if they choose to ing. do so. It just makes it easy to have readable, idiomatic and documented code in multiple languages. 2 Requirements The patterns requirement is typical of DSLs: common programming idioms can be reified into a proper linguistic While we outlined some of our requirements above, here we form instead of being merely informal. Even some of the give a complete list, as well as some reasoning behind each. design patterns of [10] can become part of the language itself. mainstream Generate code in mainstream object-oriented While this does make writing some OO code even easier languages. in GOOL than in GPLs, it also helps keep GOOL language- readable The generated code should be human-readable, agnostic and facilitates generating idiomatic code. Examples idiomatic The generated code should be idiomatic, will be given in Section5. But we can indicate now how this documented The generated code should be documented, helps: Consider Python’s ability to return multiple values patterns The generator should allow one to express with a single return statement, which is uncommon in other common OO patterns. languages. Two choices might be to disallow this feature in expressivity The language should be rich enough to GOOL, or throw an error on use when generating code in lan- express a set of existing OO programs, which act as guages that do not support this feature. In the first case, this test cases for the language. would likely mean unidiomatic Python code, or increased common Language commonalities should be abstracted. complexity in the Python generator to infer that idiom. The Targetting OO languages (mainstream) is primarily be- second option is worse still: one might have to resort to writ- cause of their popularity, which implies the most potential ing language-specific GOOL, obviating the whole reason for users — in much the same way that the makers of Scala and the language! Multiple-value return statements are always Kotlin chose to target the JVM to leverage the Java ecosystem, used when a function returns multiple outputs; what we can and Typescript for Javascript.
Load more

Recommended publications
  • Lackwit: a Program Understanding Tool Based on Type Inference
    Lackwit: A Program Understanding Tool Based on Type Inference Robert O’Callahan Daniel Jackson School of Computer Science School of Computer Science Carnegie Mellon University Carnegie Mellon University 5000 Forbes Avenue 5000 Forbes Avenue Pittsburgh, PA 15213 USA Pittsburgh, PA 15213 USA +1 412 268 5728 +1 412 268 5143 [email protected] [email protected] same, there is an abstraction violation. Less obviously, the ABSTRACT value of a variable is never used if the program places no By determining, statically, where the structure of a constraints on its representation. Furthermore, program requires sets of variables to share a common communication induces representation constraints: a representation, we can identify abstract data types, detect necessary condition for a value defined at one site to be abstraction violations, find unused variables, functions, used at another is that the two values must have the same and fields of data structures, detect simple errors in representation1. operations on abstract datatypes, and locate sites of possible references to a value. We compute representation By extending the notion of representation we can encode sharing with type inference, using types to encode other kinds of useful information. We shall see, for representations. The method is efficient, fully automatic, example, how a refinement of the treatment of pointers and smoothly integrates pointer aliasing and higher-order allows reads and writes to be distinguished, and storage functions. We show how we used a prototype tool to leaks to be exposed. answer a user’s questions about a 17,000 line program We show how to generate and solve representation written in C.
    [Show full text]
  • Scala−−, a Type Inferred Language Project Report
    Scala−−, a type inferred language Project Report Da Liu [email protected] Contents 1 Background 2 2 Introduction 2 3 Type Inference 2 4 Language Prototype Features 3 5 Project Design 4 6 Implementation 4 6.1 Benchmarkingresults . 4 7 Discussion 9 7.1 About scalac ....................... 9 8 Lessons learned 10 9 Language Specifications 10 9.1 Introdution ......................... 10 9.2 Lexicalsyntax........................ 10 9.2.1 Identifiers ...................... 10 9.2.2 Keywords ...................... 10 9.2.3 Literals ....................... 11 9.2.4 Punctions ...................... 12 9.2.5 Commentsandwhitespace. 12 9.2.6 Operations ..................... 12 9.3 Syntax............................ 12 9.3.1 Programstructure . 12 9.3.2 Expressions ..................... 14 9.3.3 Statements ..................... 14 9.3.4 Blocksandcontrolflow . 14 9.4 Scopingrules ........................ 16 9.5 Standardlibraryandcollections. 16 9.5.1 println,mapandfilter . 16 9.5.2 Array ........................ 16 9.5.3 List ......................... 17 9.6 Codeexample........................ 17 9.6.1 HelloWorld..................... 17 9.6.2 QuickSort...................... 17 1 of 34 10 Reference 18 10.1Typeinference ....................... 18 10.2 Scalaprogramminglanguage . 18 10.3 Scala programming language development . 18 10.4 CompileScalatoLLVM . 18 10.5Benchmarking. .. .. .. .. .. .. .. .. .. .. 18 11 Source code listing 19 1 Background Scala is becoming drawing attentions in daily production among var- ious industries. Being as a general purpose programming language, it is influenced by many ancestors including, Erlang, Haskell, Java, Lisp, OCaml, Scheme, and Smalltalk. Scala has many attractive features, such as cross-platform taking advantage of JVM; as well as with higher level abstraction agnostic to the developer providing immutability with persistent data structures, pattern matching, type inference, higher or- der functions, lazy evaluation and many other functional programming features.
    [Show full text]
  • First Steps in Scala Typing Static Typing Dynamic and Static Typing
    CS206 First steps in Scala CS206 Typing Like Python, Scala has an interactive mode, where you can try What is the biggest difference between Python and Scala? out things or just compute something interactively. Python is dynamically typed, Scala is statically typed. Welcome to Scala version 2.8.1.final. In Python and in Scala, every piece of data is an object. Every scala> println("Hello World") object has a type. The type of an object determines what you Hello World can do with the object. Dynamic typing means that a variable can contain objects of scala> println("This is fun") different types: This is fun # This is Python The + means different things. To write a Scala script, create a file with name, say, test.scala, def test(a, b): and run it by saying scala test.scala. print a + b In the first homework you will see how to compile large test(3, 15) programs (so that they start faster). test("Hello", "World") CS206 Static typing CS206 Dynamic and static typing Static typing means that every variable has a known type. Dynamic typing: Flexible, concise (no need to write down types all the time), useful for quickly writing short programs. If you use the wrong type of object in an expression, the compiler will immediately tell you (so you get a compilation Static typing: Type errors found during compilation. More error instead of a runtime error). robust and trustworthy code. Compiler can generate more efficient code since the actual operation is known during scala> varm : Int = 17 compilation. m: Int = 17 Java, C, C++, and Scala are all statically typed languages.
    [Show full text]
  • Typescript-Handbook.Pdf
    This copy of the TypeScript handbook was created on Monday, September 27, 2021 against commit 519269 with TypeScript 4.4. Table of Contents The TypeScript Handbook Your first step to learn TypeScript The Basics Step one in learning TypeScript: The basic types. Everyday Types The language primitives. Understand how TypeScript uses JavaScript knowledge Narrowing to reduce the amount of type syntax in your projects. More on Functions Learn about how Functions work in TypeScript. How TypeScript describes the shapes of JavaScript Object Types objects. An overview of the ways in which you can create more Creating Types from Types types from existing types. Generics Types which take parameters Keyof Type Operator Using the keyof operator in type contexts. Typeof Type Operator Using the typeof operator in type contexts. Indexed Access Types Using Type['a'] syntax to access a subset of a type. Create types which act like if statements in the type Conditional Types system. Mapped Types Generating types by re-using an existing type. Generating mapping types which change properties via Template Literal Types template literal strings. Classes How classes work in TypeScript How JavaScript handles communicating across file Modules boundaries. The TypeScript Handbook About this Handbook Over 20 years after its introduction to the programming community, JavaScript is now one of the most widespread cross-platform languages ever created. Starting as a small scripting language for adding trivial interactivity to webpages, JavaScript has grown to be a language of choice for both frontend and backend applications of every size. While the size, scope, and complexity of programs written in JavaScript has grown exponentially, the ability of the JavaScript language to express the relationships between different units of code has not.
    [Show full text]
  • Certifying Ocaml Type Inference (And Other Type Systems)
    Certifying OCaml type inference (and other type systems) Jacques Garrigue Nagoya University http://www.math.nagoya-u.ac.jp/~garrigue/papers/ Jacques Garrigue | Certifying OCaml type inference 1 What's in OCaml's type system { Core ML with relaxed value restriction { Recursive types { Polymorphic objects and variants { Structural subtyping (with variance annotations) { Modules and applicative functors { Private types: private datatypes, rows and abbreviations { Recursive modules . Jacques Garrigue | Certifying OCaml type inference 2 The trouble and the solution(?) { While most features were proved on paper, there is no overall specification for the whole type system { For efficiency reasons the implementation is far from the the theory, making proving it very hard { Actually, until 2008 there were many bug reports A radical solution: a certified reference implementation { The current implementation is not a good basis for certification { One can check the expected behaviour with a (partial) reference implementation { Relate explicitly the implementation and the theory, by developing it in Coq Jacques Garrigue | Certifying OCaml type inference 3 What I have be proving in Coq 1 Over the last 2 =2 years (on and off) { Built a certified ML interpreter including structural polymorphism { Proved type soundness and adequacy of evaluation { Proved soundness and completeness (principality) of type inference { Can handle recursive polymorphic object and variant types { Both the type checker and interpreter can be extracted to OCaml and run { Type soundness was based on \Engineering formal metatheory" Jacques Garrigue | Certifying OCaml type inference 4 Related works About core ML, there are already several proofs { Type soundness was proved many times, and is included in "Engineering formal metatheory" [2008] { For type inference, both Dubois et al.
    [Show full text]
  • Bidirectional Typing
    Bidirectional Typing JANA DUNFIELD, Queen’s University, Canada NEEL KRISHNASWAMI, University of Cambridge, United Kingdom Bidirectional typing combines two modes of typing: type checking, which checks that a program satisfies a known type, and type synthesis, which determines a type from the program. Using checking enables bidirectional typing to support features for which inference is undecidable; using synthesis enables bidirectional typing to avoid the large annotation burden of explicitly typed languages. In addition, bidirectional typing improves error locality. We highlight the design principles that underlie bidirectional type systems, survey the development of bidirectional typing from the prehistoric period before Pierce and Turner’s local type inference to the present day, and provide guidance for future investigations. ACM Reference Format: Jana Dunfield and Neel Krishnaswami. 2020. Bidirectional Typing. 1, 1 (November 2020), 37 pages. https: //doi.org/10.1145/nnnnnnn.nnnnnnn 1 INTRODUCTION Type systems serve many purposes. They allow programming languages to reject nonsensical programs. They allow programmers to express their intent, and to use a type checker to verify that their programs are consistent with that intent. Type systems can also be used to automatically insert implicit operations, and even to guide program synthesis. Automated deduction and logic programming give us a useful lens through which to view type systems: modes [Warren 1977]. When we implement a typing judgment, say Γ ` 4 : 퐴, is each of the meta-variables (Γ, 4, 퐴) an input, or an output? If the typing context Γ, the term 4 and the type 퐴 are inputs, we are implementing type checking. If the type 퐴 is an output, we are implementing type inference.
    [Show full text]
  • 1 Polymorphism in Ocaml 2 Type Inference
    CS 4110 – Programming Languages and Logics Lecture #23: Type Inference 1 Polymorphism in OCaml In languages like OCaml, programmers don’t have to annotate their programs with 8X: τ or e »τ¼. Both are automatically inferred by the compiler, although the programmer can specify types explicitly if desired. For example, we can write let double f x = f (f x) and OCaml will figure out that the type is ('a ! 'a) ! 'a ! 'a which is roughly equivalent to the System F type 8A: ¹A ! Aº ! A ! A We can also write double (fun x ! x+1) 7 and OCaml will infer that the polymorphic function double is instantiated at the type int. The polymorphism in ML is not, however, exactly like the polymorphism in System F. ML restricts what types a type variable may be instantiated with. Specifically, type variables can not be instantiated with polymorphic types. Also, polymorphic types are not allowed to appear on the left-hand side of arrows—i.e., a polymorphic type cannot be the type of a function argument. This form of polymorphism is known as let-polymorphism (due to the special role played by let in ML), or prenex polymorphism. These restrictions ensure that type inference is decidable. An example of a term that is typable in System F but not typable in ML is the self-application expression λx: x x. Try typing fun x ! x x in the top-level loop of OCaml, and see what happens... 2 Type Inference In the simply-typed lambda calculus, we explicitly annotate the type of function arguments: λx : τ: e.
    [Show full text]
  • An Overview of the Scala Programming Language
    An Overview of the Scala Programming Language Second Edition Martin Odersky, Philippe Altherr, Vincent Cremet, Iulian Dragos Gilles Dubochet, Burak Emir, Sean McDirmid, Stéphane Micheloud, Nikolay Mihaylov, Michel Schinz, Erik Stenman, Lex Spoon, Matthias Zenger École Polytechnique Fédérale de Lausanne (EPFL) 1015 Lausanne, Switzerland Technical Report LAMP-REPORT-2006-001 Abstract guage for component software needs to be scalable in the sense that the same concepts can describe small as well as Scala fuses object-oriented and functional programming in large parts. Therefore, we concentrate on mechanisms for a statically typed programming language. It is aimed at the abstraction, composition, and decomposition rather than construction of components and component systems. This adding a large set of primitives which might be useful for paper gives an overview of the Scala language for readers components at some level of scale, but not at other lev- who are familar with programming methods and program- els. Second, we postulate that scalable support for compo- ming language design. nents can be provided by a programming language which unies and generalizes object-oriented and functional pro- gramming. For statically typed languages, of which Scala 1 Introduction is an instance, these two paradigms were up to now largely separate. True component systems have been an elusive goal of the To validate our hypotheses, Scala needs to be applied software industry. Ideally, software should be assembled in the design of components and component systems. Only from libraries of pre-written components, just as hardware is serious application by a user community can tell whether the assembled from pre-fabricated chips.
    [Show full text]
  • Computations in Algebraic Geometry with Macaulay 2
    Computations in algebraic geometry with Macaulay 2 Editors: D. Eisenbud, D. Grayson, M. Stillman, and B. Sturmfels Preface Systems of polynomial equations arise throughout mathematics, science, and engineering. Algebraic geometry provides powerful theoretical techniques for studying the qualitative and quantitative features of their solution sets. Re- cently developed algorithms have made theoretical aspects of the subject accessible to a broad range of mathematicians and scientists. The algorith- mic approach to the subject has two principal aims: developing new tools for research within mathematics, and providing new tools for modeling and solv- ing problems that arise in the sciences and engineering. A healthy synergy emerges, as new theorems yield new algorithms and emerging applications lead to new theoretical questions. This book presents algorithmic tools for algebraic geometry and experi- mental applications of them. It also introduces a software system in which the tools have been implemented and with which the experiments can be carried out. Macaulay 2 is a computer algebra system devoted to supporting research in algebraic geometry, commutative algebra, and their applications. The reader of this book will encounter Macaulay 2 in the context of concrete applications and practical computations in algebraic geometry. The expositions of the algorithmic tools presented here are designed to serve as a useful guide for those wishing to bring such tools to bear on their own problems. A wide range of mathematical scientists should find these expositions valuable. This includes both the users of other programs similar to Macaulay 2 (for example, Singular and CoCoA) and those who are not interested in explicit machine computations at all.
    [Show full text]
  • The Pretzel User Manual
    The PretzelBook second edition Felix G¨artner June 11, 1998 2 Contents 1 Introduction 5 1.1 Do Prettyprinting the Pretzel Way . 5 1.2 History . 6 1.3 Acknowledgements . 6 1.4 Changes to second Edition . 6 2 Using Pretzel 7 2.1 Getting Started . 7 2.1.1 A first Example . 7 2.1.2 Running Pretzel . 9 2.1.3 Using Pretzel Output . 9 2.2 Carrying On . 10 2.2.1 The Two Input Files . 10 2.2.2 Formatted Tokens . 10 2.2.3 Regular Expressions . 10 2.2.4 Formatted Grammar . 11 2.2.5 Prettyprinting with Format Instructions . 12 2.2.6 Formatting Instructions . 13 2.3 Writing Prettyprinting Grammars . 16 2.3.1 Modifying an existing grammar . 17 2.3.2 Writing a new Grammar from Scratch . 17 2.3.3 Context Free versus Context Sensitive . 18 2.3.4 Available Grammars . 19 2.3.5 Debugging Prettyprinting Grammars . 19 2.3.6 Experiences . 21 3 Pretzel Hacking 23 3.1 Adding C Code to the Rules . 23 3.1.1 Example for Tokens . 23 3.1.2 Example for Grammars . 24 3.1.3 Summary . 25 3.1.4 Tips and Tricks . 26 3.2 The Pretzel Interface . 26 3.2.1 The Prettyprinting Scanner . 27 3.2.2 The Prettyprinting Parser . 28 3.2.3 Example . 29 3.3 Building a Pretzel prettyprinter by Hand . 30 3.4 Obtaining a Pretzel Prettyprinting Module . 30 3.4.1 The Prettyprinting Scanner . 30 3.4.2 The Prettyprinting Parser . 31 3.5 Multiple Pretzel Modules in the same Program .
    [Show full text]
  • Class Notes on Type Inference 2018 Edition Chuck Liang Hofstra University Computer Science
    Class Notes on Type Inference 2018 edition Chuck Liang Hofstra University Computer Science Background and Introduction Many modern programming languages that are designed for applications programming im- pose typing disciplines on the construction of programs. In constrast to untyped languages such as Scheme/Perl/Python/JS, etc, and weakly typed languages such as C, a strongly typed language (C#/Java, Ada, F#, etc ...) place constraints on how programs can be written. A type system ensures that programs observe logical structure. The origins of type theory stretches back to the early twentieth century in the work of Bertrand Russell and Alfred N. Whitehead and their \Principia Mathematica." They observed that our language, if not restrained, can lead to unsolvable paradoxes. Specifically, let's say a mathematician defined S to be the set of all sets that do not contain themselves. That is: S = fall A : A 62 Ag Then it is valid to ask the question does S contain itself (S 2 S?). If the answer is yes, then by definition of S, S is one of the 'A's, and thus S 62 S. But if S 62 S, then S is one of those sets that do not contain themselves, and so it must be that S 2 S! This observation is known as Russell's Paradox. In order to avoid this paradox, the language of mathematics (or any language for that matter) must be constrained so that the set S cannot be defined. This is one of many discoveries that resulted from the careful study of language, logic and meaning that formed the foundation of twentieth century analytical philosophy and abstract mathematics, and also that of computer science.
    [Show full text]
  • Local Type Inference
    Local Type Inference BENJAMIN C. PIERCE University of Pennsylvania and DAVID N. TURNER An Teallach, Ltd. We study two partial type inference methods for a language combining subtyping and impredica- tive polymorphism. Both methods are local in the sense that missing annotations are recovered using only information from adjacent nodes in the syntax tree, without long-distance constraints such as unification variables. One method infers type arguments in polymorphic applications using a local constraint solver. The other infers annotations on bound variables in function abstractions by propagating type constraints downward from enclosing application nodes. We motivate our design choices by a statistical analysis of the uses of type inference in a sizable body of existing ML code. Categories and Subject Descriptors: D.3.1 [Programming Languages]: Formal Definitions and Theory General Terms: Languages, Theory Additional Key Words and Phrases: Polymorphism, subtyping, type inference 1. INTRODUCTION Most statically typed programming languages offer some form of type inference, allowing programmers to omit type annotations that can be recovered from context. Such a facility can eliminate a great deal of needless verbosity, making programs easier both to read and to write. Unfortunately, type inference technology has not kept pace with developments in type systems. In particular, the combination of subtyping and parametric polymorphism has been intensively studied for more than a decade in calculi such as System F≤ [Cardelli and Wegner 1985; Curien and Ghelli 1992; Cardelli et al. 1994], but these features have not yet been satisfactorily This is a revised and extended version of a paper presented at the 25th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL), 1998.
    [Show full text]