Lazy Functional Languages: Abstract Interpretation and Compilation

245 Pages·1991·9.87 MB·English

by  Geoffrey Burn

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