ebook img

Lazy Functional Languages: Abstract Interpretation and Compilation PDF

245 Pages·1991·9.87 MB·English
Save to my drive
Quick download
Download
Most books are stored in the elastic cloud where traffic is expensive. For this reason, we have a limit on daily download.

Preview Lazy Functional Languages: Abstract Interpretation and Compilation

LazyFunctional Languages: Abstract Interpretationand Compilation TITLES INTHISSERIES OptimizingSupercompilersfor Supercomputers, Michael Wolfe, 1989 ReconfigurableProcessor-Array: A Bit-SlicedParallel Computer, Andrew Rushton, 1989 PartitioningandScheduling ParallelProgramsfor Execution on Multiprocessors, Vivek Sarkar, 1989 FunctionalProgrammingfor Loosely-coupledMultiprocessors, Paul H. J. Kelly, 1989 AlgorithmicSkeletons: Structured ManagementofParallelComputation, MurrayI. Cole, 1989 Execution Models ofPrologfor Parallel Computers, PeterKacsuk, 1990 Languagesand Compilersfor ParallelComputing, David Gelernter, Alexandru Nicolauand David Padua (Editors), 1990 Massively ParallelComputing with the DAP, DennisParkinson and John Litt (Editors),1990 Implementation ofa General-Purpose Dataflow Multiprocessor, Gregory M. Papadopoulos, 1991 ImplementationofNon-StrictFunctionalProgramming Languages, Kenneth R. Traub, 1991 Advancesin LanguagesandCompilersfor ParallelProcessing, Alexandru Nicolau, David Gelernter, Thomas Grossand DavidPadua(Editors), 1991 ParallelProcessing for Computer Graphics,StuartGreen, 1991 Lazy FunctionalLanguages: AbstractInterpretation and Compilation, Geoffrey Burn, 1991 RESEARCH MONOGRAPHS IN PARALLEL AND DISTRIBUTED COMPUTING Geoffrey Burn ImperialCollege ofScience,Technology andMedicine Lazy Functional Languages: Abstract Interpretation and Compilation Pitman,London TheMITPress, Cambridge,Massachusetts PITMANPUBLISHING 128LongAcre,LondonWCZE9AN ©GeoffTeyBurn1991 First published1991 AvailableintheWesternHemisphereand Israel from TheMITPress Cambridge,Massachusetts(andLondon,England) ISSN0953-7767 BritishLlhraryCataloguingInPnblicationData Bum,Geoffrey Lazyfunctionallanguages:abstractinterpretationand compilation.-(Researchmonographsinparalleland distributedcomputing) 1.Computersystems. Functionalprogramming.Programming languages I.Title II.Series 005.13 ISBN0-273-08832-7 LibraryofCongressCataloging-In-PublicationData Bum,Geoffrey. Lazyfunetionallanguages:abstractinterpretationand compilationIGeoffreyBum. p. cm.--{Researchmonographsinparallelanddistributed computing) Includesbibliographicalreferencesand index. ISBN0-262-52160-1 1.Functionalprogramminglanguages. I.Title. II. Series. QA76.7.B87 1991 005.1-<1020 Allrightsreserved;nopartofthispublicationmaybereproduced, storedinaretrievalsystem,ortransmittedinanyfonnorbyany means,electronic,mechanical,photocopying,recordingorotherwise withoutthe priorwrittenpermissionofthepublishersoralicence permittingrestrictedcopyinginthe UnitedKingdomissuedbythe CopyrightLicensingAgencyLtd,90TottenhamCourtRoad,London WIP9HE.Thisbookmaynotbelent,resold,hiredoutorotherwise disposedofbywayoftradeinanyform ofbindingorcoverotherthan thatinwhich itispublished,withoutthepriorconsentofthe publishers. Reproducedandprintedbyphotolithography inGreatBritainbyBiddiesLtd,Guildford • lilT Pt••• ~~~~601 • "" Preface This book studies the analysis and implementation of lazy functional languages. By functional languages we mean those in the style of Standard ML' [HMTSS, MTH90, WikS7], Miranda' [TurS5, TurS6], LML [AugS7], Haskell [HWe90] and HOPE [FlISS, PerS7]. In particular, we willbe studying lazy functional languages. Popular mythology about implementations of lazy functional languages is that they are slow when compared with more traditional languages such as C and Pascal. Early implementations were slow, for two reasons: • they were largely interpretive; and • the semantics of such languages requires that arguments to functions are not eval uated until their values are needed, imposing time and memory overheads, and restricting any parallelism in an implementation. Compiler technology has advanced sufficiently so that lazy functional programs now run respectably fast when compared with those written in more traditional languages, solving the first problem. This book tackles the second problem. Specifically we: • describe a more efficient implementation model, the evaluation transformer model, that can be used when information is known about how functions use their argu ments; • develop a semantically sound analysis technique, abstract inierpretotion., which can determine this information; and • show how to use the information to compile more efficient code for sequential and parallel machines. In more detail, the story-line 01 the book is as follows. Lazy evaluation is restrictive evaluation mechanism in two ways. Firstly, it only ever knows the next step that must be performed in executing a program. Secondly, it only ever evaluates expressions to head normal form. The evaluation transformer model of reduction lifts both of these restrictions. It introduces the concept of an evaluator, which specifies the amount of evaluation to do to an expression. With each argumentto afunction, weassociate an evaluation transformer, which says how much evaluation of that argument expression can be done, given that a certain amountofevaluationisallowed ofthefunction application. Using this information, we may know that there are several expressions which must be evaluated, and that they need more evaluation than to head normal form. Functional languages can be studied from both operational and denotationol view points. The operational viewpoint tells us how they can be implemented, and the freedom IStandard ML has some non-functional features, but the hope is that programmers will use it in a mainly functional way. "Mirande isa trademark of Research Software Ltd. we have in the implementation, whilst the denotational viewpoint gives the meanings of programs in terms of mathematical structures called domains. There is an important relationship between the operational and denotational view points, which must be preserved in any implementation model. We ensure that theevaluation transformer model of reduction preserves this relation ship by developinga semantically sound analysis technique,called abstractinterpretation, to determine evaluation transformers. Finally, weshow how to use the evaluation transformer information to generate more efficient code for sequential and parallel machines. It is used in a sequential machine to know when arguments to functions can be evaluated immediately, rather than incurring the cost of building adatastructureto hold a representationoftheunevaluated argument. In a parallel machine it is used to generate code which will initiate parallel processes to evaluate parts of the program. Our theoretical development is done in terms of the typed lambdacalculus. All func tional programs written in the languages mentioned above can be translated into the typed lambdacalculus, and so it allows us to study the properties of functional languages without worrying about the concrete syntax of a particular language. An index of symbols can be found at the end of the book. Prerequisites It has been our intention to make this book essentially self-contained, with introductions to the necessary concepts from the typed lambda calculus, domain theory, denotational semantics, functional programmingand the implementationoffunctional languages being given in the body of the text. All five topics are rather large fields in themselves, and so a background in one or more of them would help make the book more accessible. A fair degree of mathematical maturity is needed to understand this book, and the book is probably most suited to postgraduates. Some texts containing background material on the typed lambda. calculus are [Bar84, Bar91b, Gor88], on domain theory is[GS90],on denotationalsemanticsare [1\10890, 5ch86, Sto77], on functional programming are [BW88, FH88, Rea89], and on the implementation of lazy functional languages are [FH88, Pey87, Rea89]. Acknowledgements This book brings together muchof the research Ihave been doing over the past six years. My first foray intothefieldwasthedevelopmentofa strictnessanalysisforhigher-order functions in conjunction with Chris Hankin and Samson Abrarnsky (Imperial College). In generalising this work to deal with abstract domains for structured data types, such as lists, I discovered evaluation transformers. Thus, evaluation transformers are an example of an implementation concept which arose from a study of the denotational semantics of functional programming languages. These two pieces of work formed the backbone of my PhD thesis from Imperial College, which was supervised by Chris Hankin. I am most grateful for all the time Chris spent with me when I was doing my PhD, and for his continuing support. Following the study of abstract interpretation, I worked on the implementation of functional languages on sequential and parallel machines. During that time I benefited greatly from discussions with David Bevan, Raju Karia, David Lester and John Robson (GEC Hirst Research Centre), Simon Peyton Jones (now at the University of Glasgow), Lennart Augustsson and Thomas Johnsson (Universityof Goteborg), Dick Kieburtz (Ore gon Graduate Center), Werner Damm (University of Oldenburg), and Pier Giorgio Bosco and Corrado Moiso (CSELT). All of the above work, including my PhD, was completed whilst working at the GEC Hirst Research Centre, Wembley, Middlesex, UK, and was partially funded by ESPRIT Project 415 - "Parallel Languages and Architectures: A VLSI-Directed Approach". I am grateful also for all of the things I learnt from the rest of my many colleagues on that project, and for the way discussions with them helped direct my work. Sincejoining Imperial College in October 1989,twoof the things I havedone are tight ening up the definition of evaluators and putting the theory of the evaluation transformer model on a sounder footing. Some of the contents of this book are the results of new re search that has not been published elsewhere. Discussions with Sebastian Hunt., Thomas Jensen and David Sands havebeen particularlyhelpful in this endeavour. Correspondence with Roger Hindley helped me prove that leftmost reduction was head normalising for the language of this book, and I thank Henk Barendregt for suggesting I should contact him. During this time, my research has received somefinancial support from theESPRIT Basic Research Action 3124 ("Semantiqlle"). I give my thanks to David Turner for sending me a complimentary copy of Miranda Version 2. Many thanks to those people whohavereadvarious drafts of this book and !11(1demany helpful suggestions. In alphabetical order they are: Guy Argo (University of Glasgow), Gebreselassie Baraki (University of Glasgow), Lennart Edblom (University of Umea), John Farrel (University of Queensland), Chris Hankin (Imperial College), John Launch bury (Universityof Glasgow), David Lester (Universityof Manchester), and David Wright (University of Tasmania). Alan Mycroft gave me many helpful suggestions on producing a book, using my thesis as a basis, for which I give my thanks. The camera-ready copy of this book was prepared using the 1\TEXdocument prepara tion system, and the diagrams on pages 12, 14, 24, 68 and 69 were produced using the diagrams macros designed and written by Paul Taylor of Imperial College. Finally I would like to thank my parents, whose support through my education, and in many ways afterwards is most appreciated, which in part provided the foundations enabling this work to be done, and Helen, with whom it is a privilege and ajoy to share married life. Geoffrey Burn September, 1990 Contents Preface iii List ofFigures x 1 Introduction 1 1.1 Functional Programming Languages and Lazy Evaluation. 1 1.1.1 Functional Programs and Reduction 1 1.1.2 Algebraic DataTypes and Lazy Evaluation 3 1.1.3 Polymorphic and Monomorphic Typing .. 5 1.2 The Evaluation Transformer Model of Reduction. 7 1.2.1 Evaluators.......... . 7 1.2.2 Evaluation Transformers . 8 1.2.3 The Evaluation Transformer Model . 8 1.3 An Introduction to Abstract Interpretation. 9 1.4 Outline of Book . 15 2 Operational and Denotational Semantics ofthe Typed LambdaCalculus 19 2.1 The Typed Lambda-Calculus 20 2.1.1 Syntax of a First Typed Lambda Calculus . . . . . . . . . . . . .. 20 2.1.2 Computation in the Typed Lambda Calculus. . . . . . . . . . . .. 22 2.1.3 The Church-RosserProperty,Normal Formsand Reduction Strategies 24 2.1.4 The Untyped LambdaCalculus . . . . . . . . . . 27 2.1.5 Adding Constants to the Typed Lambda-Calculus 27 2.1.6 The Language AT . . . . . . . . . . . . . . 30 2.1.7 Translating Functional Programs into AT . 37 2.2 Sets With Structure. . 39 2.2.1 Partial Orders. . . . . . 39 2.2.2 Lattices . . . . . . . . . 41 2.2.3 Complete Partial Orders 42 2.2.4 Domains......... 44 2.2.5 Constructions on Domains 44 2.2.6 Powerdomains....... 48 2.3 Interpretations 50 2.3.1 A General Interpretation of AT 51 2.3.2 The Standard Interpretation of AT 55 2.4 A Result Relating the Operational Semantics and Standard Interpretation of AT . . . . . . . . . 61 2.5 Drawing it Together 62 3 A Framework for the Abstract Interpretation of Functional Languages 63 3.1 The Abstract Interpretation of AT . . . . . . . . . . . . . . . . 65 3.2 Abstraction and Concretisation Maps . . . . . . . . . . . . . . 67 3.2.1 Definition of the Abstraction and Concretisation Maps 67 3.2.2 Alternative Definitions . . . . . . . . . . . . . . . . 70 3.2.3 Properties of Abstraction and Concretisation Maps . . 71 3.3 Correctness of the Framework . . . . . . . . . . . . . . . . . . 73 3.3.1 A Result Relating the Abstract and Standard Interpretations . 73 3.3.2 Correctness of the Framework 74 3.4 Drawing It Together . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 4 Some Example Abstract Interpretations 77 4.1 An Abstract Interpretation for Evaluation Transformers. . . . . . . . .. 78 4.1.1 The Abstract Interpretation of Booleans, Integers, Lists and Trees 78 4.1.2 The Abstract Interpretation of Functional Constants 82 4.1.3 Some ExamplesoftheAbstract InterpretationofUser-Defined Func- tions . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 4.2 On Defining Abstract Domains 9:2 4.2.1 An Abstract Domain For One-Level Head-Strictness. 92 4.2.2 Combining Abstract Domains . . . . . . . . . . . . . 95 4.2.3 Choosing Optimal Abstract Domains For Base Types 100 4.3 A Systematic Approach to Deriving Abstract Domains for Lists and Trees 100 4.4 Drawing It Together . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 102 5 Evaluation Transformers 105 5.1 Safe Changes to the Evaluation Strategy lOG 5.2 Definition of Evaluators 107 5.3 Determining Evaluation Transformers. . IDS 5.3.1 Annotating Applications With Evaluation Transformers. lOS 5.3.2 A Complication of Higher-Order Functions 111 5.4 Drawing it Together 115 6 Implementing Functional Languages on Sequential and Parallel Ma- chines 117 6.1 Graph Reduction . 119 6.2 The Spineless G-machine . 123 6.2.1 The State of the Spineless G-machine . 12:3 6.2.2 Expression Evaluation - The EVAL Instruction 124 6.2.3 Generating Code for Function Definitions - The :Fand R Compi lation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 6.2.4 Compiling Code to Build Graphs - The C Compilation Scheme. 129 6.2.5 Compiling Applications of + . . . . . . . . . . . . 131 6.2.6 Compilation and Optimisation. . . . . . . . . . . . . . . . . 132 6.2.7 Optimising Applications of Strict Functions - The E Compilation Scheme .. , 1:3:3 6.2.8 Comparing the Function Call Mechanisms of Lazy Functional and Imperative Languages 134 6.3 Relating the Graph Reduction Model to the Typed Lambda Calculus 136 604 Compiling Code for Evaluation Transformers. . 136 604.1 Compiling Code for Sequential Machines 137 604.2 Compiling Code for Parallel Machines 141 604.3 Run-Time Choice of Versions 143 6.5 Drawing It Together . . . . . . . . . . . . . . 147 7 Relationship to Other Work 151 7.1 Abstract Interpretation. . . . . . . . . 151 7.2 Polymorphism............. 153 7.3 Other Program Analysis Techniques. 153 7.4 Implementation of Lazy Functional Languages 1.5.] 8 Epilogue 157 A Proofs Omitted in Earlier Chapters 161 A.2 Proofs From Chapter 2 161 A.3 Proofs From Chapter 3 . . . . . . . 169 AA Proofs From Chapter 4 . . . . . . . lSI AA.1 Abstract Interpretation of Strict Functions lSI AA.2 Abstract Interpretation of head(list 1').....1' • 182 AA.3 Abstract Interpretation of cons,.....(list 1")-(lis! r) . 1S:3 AAA Abstract Interpretation of value(tw T)_T . . . lS4 AA.5 Abstract Interpretation of left(tree r)_(tree T) . . 185 AA.6 Abstract Interpretation of right(tTee r)_(tree -r] • 185 AA.7 Abstract Interpretation of tcase(tree r).....u.....((tree T)_r_(tree 1')_<:»_0 186 AA.S Abstract Interpretation of takeiu,x xa,_a, . lS6 A.4.9 Abstract Interpretation of takesiu10 lS7 0Uk_0'; AA.l0 Abstract Interpretation of outsiu,<!J <!Ju,_u, ISS AA.l1 Abstract Interpretation of iSSiO'lffi..(fJ(]j;-bool . 188 B The Spineless G-Machine 191 B.l Compilation Rules 191 B.1.1 SchemeF (Function Definition) 191 B.1.2 Scheme R (Return Value) . . 191 B.1.3 Scheme [(Evaluate) . . . . . 192 B.1.4 SchemeC (Construct Graph) 193 B.2 Initial G-machine state. . . . . . . . 193 B.3 An Interpreter for the Spineless G-Machine . 194 B.3.1 The State of the Spineless G-Machine . 194 B.3.2 The Execution Loop . . . . . . . . . . 196

See more

The list of books you might like

Most books are stored in the elastic cloud where traffic is expensive. For this reason, we have a limit on daily download.