
Polytypic Functional Programming and Data Abstraction by Pablo Nogueira Iglesias, MSc Thesis submitted to the University of Nottingham for the degree of Doctor of Philosophy. September 2005 abstract Structural polymorphism is a generic programming technique known within the func- tional programming community under the names of polytypic or datatype-generic pro- gramming. In this thesis we show that such a technique conflicts with the principle of data abstraction and propose a solution for reconciliation. More concretely, we show that popular polytypic extensions of the functional programming language Haskell, namely, Generic Haskell and Scrap your Boilerplate have their genericity limited by data abstraction. We propose an extension to the Generic Haskell language where the `structure' in `structural polymorphism' is defined around the concept of interface and not the representation of a type. More precisely, polytypic functions capture families of polymorphic functions in one single template definition. Instances of a polytypic function for specific algebraic types can be generated automatically by a compiler following the definitional structure of the types. However, the definitional structure of an abstract type is, for maintainability reasons, logically hidden and, sometimes, even physically unavailable (e.g., precompiled libraries). Even if the representation is known, the semantic gap between an abstract type and its representation type makes automatic generation difficult, if not impossible. Furthermore, if it were possible it would nevertheless be impractical: the code generated from the definitional structure of the internal representation is rendered obsolete when the representation changes. The purpose of an abstract type is to minimise the impact of representation changes on client code. Data abstraction is upheld by client code, whether polytypic or not, when it works with abstract types through their public interfaces. Fortunately, interfaces can provide enough description of `structure' to guide the automatic construction of two polytypic functions that extract and insert data from abstract types to concrete types and vice versa. Polytypic functions can be defined in this setting in terms of polytypic inser- tion, polytypic extraction, and ordinary polytypic functions on concrete types. We propose the extension of the Generic Haskell language with mechanisms that enable programmers to supply the necessary information. The scheme relies on another pro- posed extension to support polytypic programming with type-class constrained types, which we show are not supported by Generic Haskell. Contents 1 Introduction 1 1.1 General theme and contribution . 1 1.2 Notes to the reader . 1 1.3 The problem in a nutshell . 5 1.4 Contributions . 8 1.5 Structure and organisation . 9 I Prerequisites 15 2 Language Games 16 2.1 Object versus meta . 16 2.2 Definitions and equality . 16 2.3 Grammatical conventions . 17 2.4 Quantification . 17 2.5 The importance of types . 17 2.6 Denoting functions . 22 2.7 Lambda Calculi . 22 2.7.1 Pure Simply Typed Lambda Calculus . 23 2.7.2 Adding primitive types and values. 27 2.7.3 Adding parametric polymorphism: System F . 28 2.7.4 Adding type operators: System F! . 30 2.7.5 Adding general recursion . 34 3 Bits of Category Theory 38 3.1 Categories and abstraction . 38 3.2 Direction of arrows . 39 3.3 Definition of category . 41 3.4 Example categories . 42 3.5 Duality . 43 3.6 Initial and final objects . 43 3 3.7 Isomorphisms . 44 3.8 Functors . 44 3.9 (Co)Limits . 46 3.9.1 (Co)Products . 47 3.9.2 (Co)Products and abstraction . 49 3.10 Arrow functor . 51 3.11 Algebra of functors . 52 3.12 Natural transformations . 55 4 Generic Programming 59 4.1 Genericity and the two uses of abstraction . 59 4.2 Data abstraction . 62 4.3 Generic Programming and Software Engineering . 63 4.4 Generic Programming and Generative Programming . 66 4.5 Types and Generic Programming . 67 4.6 Types and program generators . 68 4.7 The Generic Programming zoo . 69 4.7.1 Varieties of instantiation . 70 4.7.2 Varieties of polymorphism . 71 4.8 Where does this work fall? . 79 5 Data Abstraction 80 5.1 Benefits of data abstraction . 81 5.2 Pitfalls of data abstraction . 81 5.3 Algebraic specification of data types . 83 5.4 The basic specification formalism, by example . 86 5.5 Partial specifications with conditional equations. 90 5.6 Constraints on parametricity, reloaded . 92 5.7 Concrete types are bigger . 94 5.8 Embodiments in functional languages . 95 5.8.1 ADTs in Haskell . 95 5.8.2 On constrained algebraic types . 97 5.8.3 The SML module system . 99 5.9 Classification of operators . 101 5.10 Classification of ADTs . 103 II Functional Polytypic Programming and Data Abstraction 106 6 Structural Polymorphism in Haskell 107 6.1 Generic Haskell . 107 6.1.1 Algebraic data types in Haskell . 108 6.1.2 From parametric to structural polymorphism . 112 6.1.3 Generic Haskell and System F! . 124 6.1.4 Nominal type equivalence and embedding-projection pairs . 126 6.1.5 The expressibility of polykinded type definitions . 130 6.1.6 Polytypic abstraction . 131 6.1.7 The expressibility of polytypic definitions . 132 6.1.8 Summary of instantiation process . 133 6.1.9 Polytypic functions are not first-class . 134 6.1.10 Type-class constraints and constrained algebraic types . 135 6.1.11 Polykinded types as context abstractions . 137 6.1.12 Parameterisation on base types . 148 6.1.13 Generic Haskell, categorially . 149 6.2 Scrap your Boilerplate . 152 6.2.1 Strategic Programming . 152 6.2.2 SyB tour . 155 6.3 Generic Haskell vs SyB . 164 6.4 Lightweight approaches . 167 7 Polytypism and Data Abstraction 168 7.1 Polytypism conflicts with data abstraction . 169 7.1.1 Foraging clutter . 171 7.1.2 Breaking the law . 175 7.1.3 On mapping over abstract types . 179 7.2 Don't abstract, export. 182 7.3 Buck the representations! . 184 8 Pattern Matching and Data Abstraction 186 8.1 Conclusions first . 187 8.2 An overview of pattern matching . 187 8.3 Proposals for reconciliation . 191 8.3.1 SML's abstract value constructors . 192 8.3.2 Miranda's lawful concrete types . 193 8.3.3 Wadler's views . 195 8.3.4 Palao's Active Patterns . 198 8.3.5 Other proposals . 204 9 F-views and Polytypic Extensional Programming 205 9.1 An examination of possible approaches . 205 9.2 Extensional Programming: design goals . 207 9.3 Preliminaries: F -algebras and linear ADTs . 208 9.4 Construction vs Observation . 213 9.4.1 Finding dual operators in lists . 217 9.4.2 Finding dual operators in linear ADTs . 218 9.5 Insertion and extraction for unbounded linear ADTs . 219 9.5.1 Choosing the concrete type and the operators . 219 9.5.2 Parameterising on signature morphisms . 221 9.6 Insertion and extraction for bounded linear ADTs . 224 9.7 Extensional equality . 226 9.8 Encoding generic functions on linear ADTs in Haskell . 226 9.9 Extensional Programming = EC[I] . 236 9.10 Polytypic extraction and insertion . 238 9.10.1 F -views . 238 9.10.2 Named signature morphisms . 239 9.10.3 Implementing F -views and named signature morphisms . 241 9.10.4 Polyaric types and instance generation . 242 9.10.5 Generation examples . 244 9.11 Defining polytypic functions . 246 9.12 Polytypic extension . 249 9.13 Exporting . 250 9.14 Forgetful extraction . 253 9.15 Passing and comparing payload between ADTs . 254 10 Future Work 255 III Appendix 259 A Details from Chapter 5 260 A.1 Our specification formalism, set-theoretically . ..
Details
-
File Typepdf
-
Upload Time-
-
Content LanguagesEnglish
-
Upload UserAnonymous/Not logged-in
-
File Pages324 Page
-
File Size-