DOCSLIB.ORG

Scala for Generic Programmers Comparing Haskell and Scala Support for Generic Programming

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Scala for Generic Programmers Comparing Haskell and Scala Support for Generic Programming Under consideration for publication in J. Functional Programming 1 Scala for Generic Programmers Comparing Haskell and Scala Support for Generic Programming BRUNO C. D. S. OLIVEIRA ROSAEC Center, Seoul National University, 599 Gwanak-ro, Gwanak-gu, Seoul 151-744, South Korea (e-mail: http://ropas.snu.ac.kr/ bruno/) JEREMY GIBBONS Oxford University Computing Laboratory, Wolfson Building, Parks Road, Oxford OX1 3QD, UK (e-mail: http://www.comlab.ox.ac.uk/jeremy.gibbons/) Abstract Datatype-generic programming involves parametrization of programs by the shape of data, in the form of type constructors such as ‘list of’. Most approaches to datatype-generic programming are developed in pure functional programming languages such as Haskell. We argue that the functional object-oriented language Scala is in many ways a better choice. Not only does Scala provide equiv- alents of all the necessary functional programming features (such as parametric polymorphism, higher-order functions, higher-kinded type operations, and type- and constructor-classes), but it also provides the most useful features of object-oriented languages (such as subtyping, overriding, traditional single inheritance, and multiple inheritance in the form of traits). Common Haskell tech- niques for datatype-generic programming can be conveniently replicated in Scala, whereas the extra expressivity provides some important additional benefits in terms of extensibility and reuse. We illustrate this by comparing two simple approaches in Haskell, pointing out their limitations and showing how equivalent approaches in Scala address some of these limitations. Finally, we present three case studies on how to implement in Scala real datatype-generic programming approaches from the literature: Hinze’s ‘Generics for the Masses’, L¨ammel and Peyton Jones’s ‘Scrap your Boilerplate with Class’, and Gibbons’s ‘Origami Programming’. 1 Introduction Datatype-generic programming (DGP) is about writing programs that are parametrized by a datatype, such as lists or trees. This is differentfrom parametric polymorphism,or ‘gener- ics’ as the term is used by most object-oriented programmers: parametric polymorphism abstracts from the ‘integers’ in ‘lists of integers’, whereas DGP abstracts from the ‘lists of’. There is a large and growing collection of techniques for writing datatype-generic pro- grams. Much of the early research on DGP relied on special-purpose languages or lan- guage extensions such as Charity (Cockett & Fukushima, 1992), PolyP (Jansson, 2000), and Generic Haskell (Hinze & Jeuring, 2002). With time, research has shifted towards more lightweight approaches, based on language extensions such as Scrap your Boiler- plate (L¨ammel & Peyton Jones, 2003) and Template Haskell (Sheard & Peyton Jones, 2002); more recently, DGP techniques have been encapsulated in libraries for existing general-purpose languages, such as Generics for the Masses (Hinze, 2006) for Haskell and 2 Bruno Oliveira and Jeremy Gibbons Adaptive Object-Oriented Programming (Lieberherr, 1996) for C++. One key advantage of the lightweight approaches is that DGP becomes more accessible to potential users, since no new tool or compileris requiredin orderto enjoy its benefits. Indeed, the use of libraries or simple language extensions rather than completely new languages has greatly promoted the adoption of DGP. Despite the rather wide variety of host languages involved in the techniques listed above, the casual observer might be forgiven for concluding, from the wealth of proposals for lightweight generic programmingin Haskell (Cheney & Hinze, 2002; Hinze, 2006; L¨ammel & Peyton Jones, 2005; Oliveira et al., 2006; Hinze et al., 2006; Weirich, 2006; Hinze & L¨oh, 2007; Mitchell & Runciman, 2007; Brown & Sampson, 2009), that ‘Haskell is the programming language of choice for discriminating datatype-generic programmers’. Our purpose in this paper is to argue to the contrary; we believe that although Haskell is ‘a fine tool for many datatype-generic applications’, it is not necessarily the best choice. In particular, we argue that the discriminating datatype-generic programmer ought seri- ously to consider using Scala, a relatively recent language providing a smooth integration of the functional and object-oriented paradigms. Scala offers equivalents for most famil- iar features cherished by datatype-generic Haskell programmers, such parametric poly- morphism, higher-order functions, higher-kinded types, and type- and constructor-classes. (Two significant missing features are lazy evaluation and higher-ranked types.) In addition, it offers some of the most useful features of object-oriented programming languages, such as subtyping, overriding, and both single and a form of multiple inheritance (via ‘traits’). We show not only that Haskell techniques for DGP can be conveniently replicated in Scala, but also that the extra expressivity provides important additional benefits in terms of extensibility and reuse. Specifically, intricate constructions are often needed to bend the implicit dictionaries in Haskell’s class system to DGP purposes—these convolutions could mostly be avoided if one had first-class dictionaries. Scala’s traits mechanism provides such a facility, including the ability to pass them implicitly where appropriate. We are not the first to consider DGP in Scala: Moors et al. (2006) presented a translation into Scala of a Haskell library of ‘origami operators’ (Gibbons, 2006); we discuss this translation in depth in Section 9. And of course, it is not really surprising that Scala should turn out effectively to subsume Haskell, since its design is substantially inspired by functional programming. We are interested in finding the limitations of the general-purpose mechanisms, in order to point out their weaknesses and to promote their improvement. The aim here is not to compare particular DGP libraries, as was done by Rodriguez et al. (2008), but rather to consider the basic mechanisms used to implement those libraries. We claim that the language mechanisms traditionally used for implementing DGP libraries, namely type classes (Hall et al., 1996) and generalized algebraic datatypes (GADTs) (Peyton Jones et al., 2006), each have their limitations, and that it might be better to exploit a different mechanism incorporatingthe advantages of both. This paper explores Scala’s object system as such an alternative mechanism. We feel that our main contribution is as a call to datatype-generic programmers to look beyond Haskell, and particularly to look at Scala. Not only can Scala be used to express current approaches to DGP; in some ways—in particular, with its open datatypes, inher- itance, and implicits mechanism—it improves upon Haskell. Some of those advantages Journal of Functional Programming 3 derive from Scala’s mixed-paradigm nature, and so do not translate back into Haskell; but others (such as case classes and anonymous case analyses, as we shall see) would fit perfectly well into Haskell. We emphasize that we are not arguing that Scala is universally superior to Haskell. Indeed, as we shall see, Scala too has some limitations. Instead, our purpose is to promote the migration of good ideas from Scala to Haskell and vice versa, so as to improve support for DGP in both languages. As a secondary contribution, we show that Scala is more of a functional programming language than is typically appreciated. Scala tends to be seen primarily as an object- oriented language that happens to have some functional features, and so potential users feel that they have to use it in an object-oriented way. For example, Moors et al. (2006) claimed to be ‘staying as close to the original work as possible’ in their translation of the origami operators, but as we show in Section 9 they still ended up less functional than they might have done. Scala is also a functional programming language that happens to have object-oriented features; indeed, it offers the best of both worlds, and this paper serves also as a tutorial in exploiting Scala as a multi-paradigm language. The rest of this paper is structured as follows. Section 2 sets the scene, by reviewing two straightforward approaches to DGP in Haskell—using representation datatypes and type classes respectively—and pointing out their limitations. Sections 3 and 4 introduce the basics of Scala, and those more advanced features of its type and class system on which we depend. Our contribution starts in Sections 5 and 6, which show how to implement in Scala the two approaches presented in Haskell in Section 2. After that, three case studies of the translation of existing DGP libraries into Scala are presented: Section 7 discusses an implementation of Hinze’s Generics for the Masses approach (Hinze, 2006); Section 8 shows a Scala implementation of Scrap your Boilerplate with Class (L¨ammel & Peyton Jones, 2005); and Section 9 presents a more functional alternative to Moors et al.’s encoding (2006) of the Origami Programming operators (Gibbons, 2003; Gibbons, 2006) in Scala. Finally, Section 10 compares Haskell and Scala support for DGP, and briefly discusses some of the key ideas of the paper, and Section 11 concludes. Scala code for the examples is available online (Oliveira, 2009b). 2 Some Limitations of Haskell for Datatype-Generic Programming To conduct our experiments, we consider two very simple and straightforward libraries for generic programming, using representation datatypes and type classes respectively. The purpose here is to discuss the limitations of the two mechanisms. While
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]
  • Metaobject Protocols: Why We Want Them and What Else They Can Do
    Metaobject protocols: Why we want them and what else they can do Gregor Kiczales, J.Michael Ashley, Luis Rodriguez, Amin Vahdat, and Daniel G. Bobrow Published in A. Paepcke, editor, Object-Oriented Programming: The CLOS Perspective, pages 101 ¾ 118. The MIT Press, Cambridge, MA, 1993. © Massachusetts Institute of Technology All rights reserved. No part of this book may be reproduced in any form by any electronic or mechanical means (including photocopying, recording, or information storage and retrieval) without permission in writing from the publisher. Metaob ject Proto cols WhyWeWant Them and What Else They Can Do App ears in Object OrientedProgramming: The CLOS Perspective c Copyright 1993 MIT Press Gregor Kiczales, J. Michael Ashley, Luis Ro driguez, Amin Vahdat and Daniel G. Bobrow Original ly conceivedasaneat idea that could help solve problems in the design and implementation of CLOS, the metaobject protocol framework now appears to have applicability to a wide range of problems that come up in high-level languages. This chapter sketches this wider potential, by drawing an analogy to ordinary language design, by presenting some early design principles, and by presenting an overview of three new metaobject protcols we have designed that, respectively, control the semantics of Scheme, the compilation of Scheme, and the static paral lelization of Scheme programs. Intro duction The CLOS Metaob ject Proto col MOP was motivated by the tension b etween, what at the time, seemed liketwo con icting desires. The rst was to have a relatively small but p owerful language for doing ob ject-oriented programming in Lisp. The second was to satisfy what seemed to b e a large numb er of user demands, including: compatibility with previous languages, p erformance compara- ble to or b etter than previous implementations and extensibility to allow further exp erimentation with ob ject-oriented concepts see Chapter 2 for examples of directions in which ob ject-oriented techniques might b e pushed.
    [Show full text]
  • A Polymorphic Type System for Extensible Records and Variants
    A Polymorphic Typ e System for Extensible Records and Variants Benedict R. Gaster and Mark P. Jones Technical rep ort NOTTCS-TR-96-3, November 1996 Department of Computer Science, University of Nottingham, University Park, Nottingham NG7 2RD, England. fbrg,[email protected] Abstract b oard, and another indicating a mouse click at a par- ticular p oint on the screen: Records and variants provide exible ways to construct Event = Char + Point : datatyp es, but the restrictions imp osed by practical typ e systems can prevent them from b eing used in ex- These de nitions are adequate, but they are not par- ible ways. These limitations are often the result of con- ticularly easy to work with in practice. For example, it cerns ab out eciency or typ e inference, or of the di- is easy to confuse datatyp e comp onents when they are culty in providing accurate typ es for key op erations. accessed by their p osition within a pro duct or sum, and This pap er describ es a new typ e system that reme- programs written in this way can b e hard to maintain. dies these problems: it supp orts extensible records and To avoid these problems, many programming lan- variants, with a full complement of p olymorphic op era- guages allow the comp onents of pro ducts, and the al- tions on each; and it o ers an e ective type inference al- ternatives of sums, to b e identi ed using names drawn gorithm and a simple compilation metho d.
    [Show full text]
  • ECSS-E-TM-40-07 Volume 2A 25 January 2011
    ECSS-E-TM-40-07 Volume 2A 25 January 2011 Space engineering Simulation modelling platform - Volume 2: Metamodel ECSS Secretariat ESA-ESTEC Requirements & Standards Division Noordwijk, The Netherlands ECSS‐E‐TM‐40‐07 Volume 2A 25 January 2011 Foreword This document is one of the series of ECSS Technical Memoranda. Its Technical Memorandum status indicates that it is a non‐normative document providing useful information to the space systems developers’ community on a specific subject. It is made available to record and present non‐normative data, which are not relevant for a Standard or a Handbook. Note that these data are non‐normative even if expressed in the language normally used for requirements. Therefore, a Technical Memorandum is not considered by ECSS as suitable for direct use in Invitation To Tender (ITT) or business agreements for space systems development. Disclaimer ECSS does not provide any warranty whatsoever, whether expressed, implied, or statutory, including, but not limited to, any warranty of merchantability or fitness for a particular purpose or any warranty that the contents of the item are error‐free. In no respect shall ECSS incur any liability for any damages, including, but not limited to, direct, indirect, special, or consequential damages arising out of, resulting from, or in any way connected to the use of this document, whether or not based upon warranty, business agreement, tort, or otherwise; whether or not injury was sustained by persons or property or otherwise; and whether or not loss was sustained from, or arose out of, the results of, the item, or any services that may be provided by ECSS.
    [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]
  • Towards Practical Runtime Type Instantiation
    Towards Practical Runtime Type Instantiation Karl Naden Carnegie Mellon University [email protected] Abstract 2. Dispatch Problem Statement Symmetric multiple dispatch, generic functions, and variant type In contrast with traditional dynamic dispatch, the runtime of a lan- parameters are powerful language features that have been shown guage with multiple dispatch cannot necessarily use any static in- to aid in modular and extensible library design. However, when formation about the call site provided by the typechecker. It must symmetric dispatch is applied to generic functions, type parameters check if there exists a more specific function declaration than the may have to be instantiated as a part of dispatch. Adding variant one statically chosen that has the same name and is applicable to generics increases the complexity of type instantiation, potentially the runtime types of the provided arguments. The process for deter- making it prohibitively expensive. We present a syntactic restriction mining when a function declaration is more specific than another is on generic functions and an algorithm designed and implemented for laid out in [4]. A fully instantiated function declaration is applicable the Fortress programming language that simplifies the computation if the runtime types of the arguments are subtypes of the declared required at runtime when these features are combined. parameter types. To show applicability for a generic function we need to find an instantiation that witnesses the applicability and the type safety of the function call so that it can be used by the code. Formally, given 1. Introduction 1. a function signature f X <: τX (y : τy): τr, J K Symmetric multiple dispatch brings with it several benefits for 2.
    [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]
  • Balancing the Eulisp Metaobject Protocol
    Balancing the EuLisp Metaob ject Proto col x y x z Harry Bretthauer and Harley Davis and Jurgen Kopp and Keith Playford x German National Research Center for Computer Science GMD PO Box W Sankt Augustin FRG y ILOG SA avenue Gallieni Gentilly France z Department of Mathematical Sciences University of Bath Bath BA AY UK techniques which can b e used to solve them Op en questions Abstract and unsolved problems are presented to direct future work The challenge for the metaob ject proto col designer is to bal One of the main problems is to nd a b etter balance ance the conicting demands of eciency simplicity and b etween expressiveness and ease of use on the one hand extensibili ty It is imp ossible to know all desired extensions and eciency on the other in advance some of them will require greater functionality Since the authors of this pap er and other memb ers while others require greater eciency In addition the pro of the EuLisp committee have b een engaged in the design to col itself must b e suciently simple that it can b e fully and implementation of an ob ject system with a metaob ject do cumented and understo o d by those who need to use it proto col for EuLisp Padget and Nuyens intended This pap er presents a metaob ject proto col for EuLisp to correct some of the p erceived aws in CLOS to sim which provides expressiveness by a multileveled proto col plify it without losing any of its p ower and to provide the and achieves eciency by static semantics for predened means to more easily implement it eciently The current metaob
    [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]
  • Generic Programming
    Generic Programming July 21, 1998 A Dagstuhl Seminar on the topic of Generic Programming was held April 27– May 1, 1998, with forty seven participants from ten countries. During the meeting there were thirty seven lectures, a panel session, and several problem sessions. The outcomes of the meeting include • A collection of abstracts of the lectures, made publicly available via this booklet and a web site at http://www-ca.informatik.uni-tuebingen.de/dagstuhl/gpdag.html. • Plans for a proceedings volume of papers submitted after the seminar that present (possibly extended) discussions of the topics covered in the lectures, problem sessions, and the panel session. • A list of generic programming projects and open problems, which will be maintained publicly on the World Wide Web at http://www-ca.informatik.uni-tuebingen.de/people/musser/gp/pop/index.html http://www.cs.rpi.edu/˜musser/gp/pop/index.html. 1 Contents 1 Motivation 3 2 Standards Panel 4 3 Lectures 4 3.1 Foundations and Methodology Comparisons ........ 4 Fundamentals of Generic Programming.................. 4 Jim Dehnert and Alex Stepanov Automatic Program Specialization by Partial Evaluation........ 4 Robert Gl¨uck Evaluating Generic Programming in Practice............... 6 Mehdi Jazayeri Polytypic Programming........................... 6 Johan Jeuring Recasting Algorithms As Objects: AnAlternativetoIterators . 7 Murali Sitaraman Using Genericity to Improve OO Designs................. 8 Karsten Weihe Inheritance, Genericity, and Class Hierarchies.............. 8 Wolf Zimmermann 3.2 Programming Methodology ................... 9 Hierarchical Iterators and Algorithms................... 9 Matt Austern Generic Programming in C++: Matrix Case Study........... 9 Krzysztof Czarnecki Generative Programming: Beyond Generic Programming........ 10 Ulrich Eisenecker Generic Programming Using Adaptive and Aspect-Oriented Programming .
    [Show full text]
  • Programming with Gadts
    Chapter 8 Programming with GADTs ML-style variants and records make it possible to define many different data types, including many of the types we encoded in System F휔 in Chapter 2.4.1: booleans, sums, lists, trees, and so on. However, types defined this way can lead to an error-prone programming style. For example, the OCaml standard library includes functions List .hd and List . tl for accessing the head and tail of a list: val hd : ’ a l i s t → ’ a val t l : ’ a l i s t → ’ a l i s t Since the types of hd and tl do not express the requirement that the argu- ment lists be non-empty, the functions can be called with invalid arguments, leading to run-time errors: # List.hd [];; Exception: Failure ”hd”. In this chapter we introduce generalized algebraic data types (GADTs), which support richer types for data and functions, avoiding many of the errors that arise with partial functions like hd. As we shall see, GADTs offer a num- ber of benefits over simple ML-style types, including the ability to describe the shape of data more precisely, more informative applications of the propositions- as-types correspondence, and opportunities for the compiler to generate more efficient code. 8.1 Generalising algebraic data types Towards the end of Chapter 2 we considered some different approaches to defin- ing binary branching tree types. Under the following definition a tree is either empty, or consists of an element of type ’a and a pair of trees: type ’ a t r e e = Empty : ’ a t r e e | Tree : ’a tree * ’a * ’a tree → ’ a t r e e 59 60 CHAPTER 8.
    [Show full text]