Functional Programming, Glasgow 1990: Proceedings of the 1990 Glasgow Workshop on Functional Programming 13–15 August 1990, Ullapool, Scotland

294 Pages·1991·9.945 MB·English

by  Guy Argo (auth.), Simon L. Peyton Jones, Graham Hutton, Carsten Kehler Holst (eds.)

WORKSHOPS IN COMPUTING
Series edited by C. J. van Rijsbergen
Also in this series
AI and Cognitive Science '89, Dublin City University, Eire,
14-15 September 1989
A. F. Smeaton and G. McDermott (Eds.)
Specification and Verification of Concurrent Systems, University of
Stirling, Scotland, 6-8 July 1988
C. Rattray (Ed.)
Semantics for Concurrency, Proceedings of the International
BCS-FACS Workshop, Sponsored by Logic for IT (S.E.R.C.), University
of Leicester, UK, 23-25 July 1990
M. Z. Kwiatkowska, M. W. Shields and R. M. Thomas (Eds.)
Functional Programming, Proceedings of the 1989 Glasgow
Workshop, Fraserburgh, Scotland, 21-23 August 1989
K. Davis and J. Hughes (Eds.)
Persistent Object Systems, Proceedings of the Third Intemational
Workshop, Newcastle, Australia, 10-13 January 1989
J. Rosenberg and D. Koch (Eds.)
Z User Workshop, Proceedings of the Fourth Annual Z User Meeting,
Oxford, 15 December 1989
J. E. Nicholls (Ed.)
Formal Methods for Trustworthy Computer Systems (FM89), Halifax,
Canada, 23-27 July 1989
Dan Craigen (Editor) and Karen Summerskill (Assistant Editor)
Security and Persistence, Proceedings of the International Workshop
on Computer Architectures to Support Security and Persistence of
Information, Bremen, West Germany, 8-11 May 1990
John Rosenberg and J. Leslie Keedy (Eds.)
Women into Computing: Selected Papers 1988-1990
Gillian Lovegrove and Barbara Segal (Eds.)
3rd Refinement Workshop (organised by BCS-FACS, and sponsored
by IBM UK Laboratories, Hursley Park and the Programming Research
Group, University of Oxford) 9-11 January 1990, Hursley Park
Carroll Morgan and J. C. P. Woodcock (Eds.)
Designing Correct Circuits, Workshop jointly organised by the Univer
sities of Oxford and Glasgow, 26-28 September 1990, Oxford
Geraint Jones and Mary Sheeran (Eds.) -
Simon L. Peyton Jones, Graham Hutton and
Carsten Kehler Holst (Eds.)
Functional Programming,
Glasgow 1990
Proceedings of the 1990 Glasgow
Workshop on Functional Programming
13-15 August 1990, Ullapool, Scotland
Springer-Verlag Berlin Heidelberg GmbH
ISBN 978-3-540-19667-9
British Ubrary Cataloguing in Publication Data
Glasgow Workshop on Functional Programming (1990: Ullapool, Scotland)
Functional Programming, Glasgow 1990: Proceedings of the 1990 Glasgow
Workshop on Functional Programming, 13-15 August 1990, Ullapool,
Scotland. - (Workshops in computing).
1.Functional programming
I. Peyton Jones, Simon L. 1958- II. Hutton, Graham 1968- III. Holst,
Carsten Kehler 1962- IV. British Computer Society V. Series
005.1
ISBN 978-3-540-19667-9
Ubrary of Congress Cataloging-in-Publication Data
Glasgow Workshop on Functional Programming (1990: Ullapool, Scotland)
Functional Programming, Glasgow 1990: Proceedings of the 1990 Glasgow
Workshop on Functional Programming 1 Simon L. Peyton Jones,
Graham Hutton, and Carsten Kehler Holst, eds.
p. cm. Includes index.
ISBN 978-3-540-19667-9 ISBN 978-1-4471-3810-5 (eBook)
DOI 10.1007/978-1-4471-3810-5
1 . Functional programming (Computer science) I. Peyton Jones, Simon L.,
1958- . II. Hutton, Graham, 1968- III. Holst, Carsten Kehler,
1962- . IV. Title.
QA76.62.G581990 91-8692
oo5.1'1-dc20 CIP
Apart from any fair dealing for the purposes of research or private study, or
criticism or review, as permitted under the Copyright, Designs and Patents
Act 1988, this publication may only be reproduced, stored or transmitted, in
any form or by any means, with the prior permission in writing of the
publishers, or in the case of reprographic reproduction in accordance with
the terms of licences issued by the Copyright Ucensing Agency. Enquiries
conceming reproduction outside those terms should be sent to the
publishers.
© Springer-Verlag Berlin Heidelberg 1991
Originally published by Springer-Verlag Berlin Heidelberg New York in 1991
The use of registered names, trademarks etc. in this publication does not
imply, even in the absence of a specific statement, that such names are
exempt from the relevant laws and regulations and therefore free for general
use.
34/3830-54321 0 Printed on acid-free paper
Preface
The Third Glasgow Workshop on Functional Programming was held in
Ullapool, Scotland, 13-15th August 1990. Members of the functional
programming groups at Glasgow and Stirling University attended the
workshop together with a small number of invited participants from
other universities and industry.
The workshop was organised by Kei Davis, Jak Deschner, Kevin
Hammond, Carsten Kehler Holst, John Hughes, Graham Hutton, and
John Launchbury, all from Glasgow University.
We are very grateful for the support of our industrial sponsors: British
Telecom, Hewlett Packard, ICL and Software AG. Their financial help
made the workshop possible.
Thanks to Samson Abramsky, Tony Field, and Paul Kelly, all from
Imperial College, for their help in refereeing many of the papers.
Glasgow University The Programme Committee:
December 1990
Simon Peyton Jones (chairman)
Chris Hankin
Carsten Kehler Holst
John Hughes
Graham Hutton
Philip Wadler
Contents
Lifetime Analysis
Guy Argo .................................................................................... .
Compiling Laziness by Partial Evaluation
Anders Bondorf ........................................................................... 9
Strictness Analysis in 4D
Kei Davis and Philip Wadler ......................................................... 23
An Algorithmic and Semantic Approach to Debugging
Cordelia Hall, Kevin Hammond and John O'Donnell .................... 44
Abstract Interpretation of Term Graph Rewriting Systems
Chris Hankin ................................................................................ 54
Compile-Time Garbage Collection by Necessity Analysis
Geoff W Hamilton and Simon B. Jones....................................... 66
Improving Full Laziness
Carsten Kehler Holst .................................................................... 71
Towards Binding-Time Improvement for Free
Carsen Kehler Holst and John Hughes ........................................ 83
Towards Relating Forwards and Backwards Analyses
John Hughes and John Launchbury ............................................ 101
PERs Generalise Projections for Strictness Analysis
Sebastian Hunt ............................................................................ 114
Functional Programming with Relations
Graham Hutton ............................................................................ 126
Abstract Interpretation vs. Type Inference: A Topological
Perspective
Thomas Jensen ........................................................................... 141
Analysing Heap Contents in a Graph Reduction Intermediate
Language
Thomas Johnsson ....................................................................... 146
viii Contents
Is Compile Time Garbage Collection Worth the Effort?
Simon B. Jones and Michael White ............................................. 172
Generating a Pattern Matching Compiler by Partial Evaluation
Jesper J0rgensen ........................................................................ 177
An Experiment using Term Rewriting Techniques for
Concurrency
Carron Kirkwood .......................................................................... 196
Type Refinement in Ruby
David Murphy .............................................................................. 201
Normal-Order Reduction Using Scan Primitives
William D. Partain ......................................................................... 218
Calculating Lenient Programs' Performance
Paul Roe ...................................................................................... 227
Problems and Proposals for Time and Space Profiling of
Functional Programs
Colin Runciman and David Wakeling ............................................ 237
Solid Modelling in HASKELL
Duncan C. Sinclair ....................................................................... 246
Differentiating Strictness
Satnam Singh .............................................................................. 264
Generalising Diverging Sequences of Rewrite Rules by
Synthesising New Sorts
Muffy Thomas and Phil Watson ................................................... 268
Concurrent Data Manipulation in a Pure Functional Language
Phil Trinder ................................................................................... 274
Lifetime analysis
Guy Argo
Computing Science Department, The University, Glasgow G12 8QQ,
United Kingdom.
Jll.6stract
JII. mIljor o6stDde in eM efficient impkmentation of ftuy Junctional faTllJUOBes is
tne fr.igfr. aemantis p{acea on neap-a!focatea storage_ 'lTiis stems from
imp{ementors' conservative assumption tfr.at af( environments must 6e neap
affocatea to avoUf eM 6foct rttention pro6km. 'l1i.e 6foct rttention pro6km is
tfr.at varia6ks wfr.icfr. migfr.t 6e rtfertnua outsuu eM 6foct in wfr.icfr. tney Wert
crtatetf force tfr.eir 6foct to 6e storetf on a gar6age-coffectetf Iieap to avoUf tfanou11fJ
rtfertnces_ In tfr.is paper we eiUJlTline an anafysis tecfr.nique Cll!ka {ifetime analysis
wfr.icfr. cfassijUs varia6ks into two cfasses: persistent, wfr.icfr. 1tIIl!J 6e rtfertncetf
outsuu eM 6foct in wfridi. th.ey Wt.rt creatuli ant! transient, wfr.icfr. art gutzranteetf
never to 6e rtfertnua outsuu eM 6foct in wIiidi eMy Wt.rt matuf. 'Usi11fJ tfr.is
information affows tne transient ant! persistent parts to 6e storta in separate
6fo~ tfr.us retfuci11fJ eM space consumea 6y tne rttainea 6foc~. 'l1~ prtvious
simifar analyses, ours is for a ftuy faTIIJUOBe 6ut is wfr.o(Jy tfuoupka from tfr.e
refatetf pro6fem of strictness analysis. 'l1i.is maqs our antzfgsi.s simpkr ant! mort
motfular. 'We th.en tfemonstrate fr.ow tfr.ese tecfr.nitJues can 6e incorporatea into an
environment-6asetf a6stract macfr.ine uKl eM '11!M.
1. Introduction
Besides the overheads of implementing lazy evaluation, the major reason functional
languages are slow is their high rate of heap-allocated storage consumption. So why is
heap allocation necessary?
Stacks allocate space in a last-in-first-out (LIFO) manner. In order to use a LIFO allocation
scheme we must be certain that no reference to an object persists after it has been popped
off the stack. Thus to be able to use a stack for function environments, we must guarantee
that no references to the environment persist beyond the context which created it.
Languages like Pascal can guarantee this because they are strict and frrst-order, and thus the
result of a function can never be a closure (representing either a lazy suspension or a
function). As closures are the only run-time objects which reference environments, this is
sufficient to guarantee that it is safe to use stack-allocated environments. Conversely, it is
the inability to guarantee this condition that forces implementors of lazy higher-order
languages to use the more conservative heap-allocated environments. However if an
analysis were able to determine that a function would not export references to its
environment then it's block could be safely allocated on the stack. Consequently we wish
2
to classify variables into two categories: persistent, which may be referenced outside the
block in which they were created; and transient, which are guaranteed never to be
referenced outside the block in which they were created.
For the rest of the paper we will assume the following syntax for programs:
expr ::= id
constant
let id = expr [; id = expr ]* in expr
A. icr- . expr
( expr+ )
op expr expr
if expr then expr else expr
expr'id
expr!
Let definitions may be recursive. The default evaluation order is call-by-name. To effect
call-by-need we use the share annotation, e'v where e is a shared expression whose result
will be saved in the variable vi. To effect call-by-value we use the force annotation, e!
where if e is part of an application being evaluated to Weak Head Normal Form (WHNF)
then e will also be evaluated to WHNF. Thus a conservative method to achieve lazy
evaluation would be to coat every application with a share annotation. For instance:
let fact = An. if (= n 0)
then 1
else (* n (fact (- n 1»)
in fact 20
would be annotated thus:
let fact = An. if (= n! 0)
then 1
else let $1 = (- n! 1)'$1 in
let $2 = (fact $1) '$2 in
(* n! $2!)
in fact 20
This is clearly inefficient. If strictness information is available then this can be rephrased as:
let fact = An. if (= n 0)
then 1
else (* n (fact (- n 1)!)!)
in fact 20
These annotations are provided by the strictness analyser in a previous pass of the
compiler.
1I t eases the task of implementation to make the variable updated after a shared expression explicit.
3
By perfonning the strictness analysis in an earlier pass, we decouple lifetime analysis from
strictness analysis. This allows us to use better strictness analysers when they become
available without affecting the lifetime analysis (except perhaps by improving the accuracy
of its results). The accuracy of the lifetime analysis' results depends on the quality of
strictness annotations. For instance, if a function is strict in an argument x then any
variables referenced in the expression passed as x's actual parameter are guaranteed not to
persist as the actual parameter is evaluated before the call. However if a function is non
strict in an argument x then the closure representing the expression passed as x' s actual
parameter may be returned as part of the function's result and thus we must be pessimistic
and assume any variable referenced in the closure will persist
2. The analysis
We will describe our analysis by explaining only a few important cases -once these are
understood the rest can be worked out
The analyser takes three arguments besides the expression it is analysing.
The first argument is the context which indicates whether the current expression is used in a
strict or lazy fashion. Note that the outennost expression in a function body is evaluated in
a strict context but for a nested expression to be evaluated in a strict context all the
enclosing expressions must be annotated by an exclamation (!).
The second argument is an environment, pset_enveval, which maps variables to their
pseteval" The pseteva1 is the set of variables that may be referenced from the evaluated
fonn of the given variable. Consider:
let from = An.
let from$l = (+ n! l)'from$l in
let from$2 = (from from$1)'from$2 in
(Cons n from$2) in
(from 1)
Here the pseteva1 of from's body is en, from$2, from$l} as n and from$2 are stored in
the cons cell and from$l must be retained to compute from$2.
Likewise, the third argument is another environment, pset_envunevalt which maps
variables to their psetuneval' The psetuneval is the set of variables that may be referenced
from the unevaluated form of the given variable. For instance, in the code fragment:
let from$l = (n! + l)'from$l in (from from$l)