[project @ 1996-01-08 20:28:12 by partain]
[ghc-hetmet.git] / ghc / docs / abstracts / before90.tex
1 \documentstyle[11pt,slpj]{article}
2
3 \newcommand{\reference}[4]{     % authors, title, details, abstract
4 \large
5 #1, {\em #2}, #3.
6 \normalsize
7 \begin{quotation}
8 #4
9 \end{quotation}
10 \vspace{0.2in}
11 }
12
13 \newcommand{\Haskell}[1]{{\sc Haskell}}
14
15 \begin{document}
16
17 \title{Abstracts of GRIP/GRASP-related papers and reports before 1990\\
18 Dept of Computing Science \\
19 University of Glasgow G12 8QQ}
20
21 \author{
22 Cordelia Hall (cvh@cs.glasgow.ac.uk) \and
23 Kevin Hammond (kh@cs.glasgow.ac.uk) \and
24 Will Partain (partain@cs.glasgow.ac.uk) \and
25 Simon L Peyton Jones (simonpj@cs.glasgow.ac.uk) \and
26 Phil Wadler (wadler@cs.glasgow.ac.uk) 
27 }
28
29 \maketitle
30
31 \begin{abstract}
32 We present a list of papers and reports related to the GRIP 
33 and GRASP projects,
34 covering {\em the design, compilation technology,
35 and parallel implementations of functional programming languages, especially
36 \Haskell{}}.
37
38 Most of them can be obtained by writing to 
39 Teresa Currie, Dept of Computing Science,
40 University of Glasgow G12 8QQ, UK.   Her electronic mail address is
41 teresa@uk.ac.glasgow.cs.
42
43 Those marked ($\spadesuit$) can be obtained from the School of Information
44 Systems, University of East Anglia, Norwich, UK.
45 \end{abstract}
46
47 \section{Published papers}
48 %Nov
49 \reference{Cordelia Hall and David Wise}
50 {Generating Function Versions with Rational Strictness Patterns}
51 {Science of Computer Programming 12 (1989)}
52 {Expression evaluation in lazy applicative languages is usually implemented
53 by an expensive mechanism requiring time and space which may be wasted
54 if the expression eventually needs the values anyway. Strictness analysis,
55 which has been successfully applied to flat domains and higher order functions,
56 is used here to annotate programs in a first order language containing
57 lazy list constructors so that they retain their original behavior, but
58 run more efficiently. In practice, the strictness in fields within these
59 constructors often follows regular patterns that can be finitely
60 represented, especially in programs that manipulate such useful structures
61 as finite or infinite trees. The approach presented here typically generates
62 efficient, mutually recursive function versions for these programs.
63 Weak and strong safety are defined and discussed, and the compiler
64 is shown to be weakly safe. Termination is guaranteed by several factors,
65 including a finite resource which controls the increase in code size,
66 and a regularity constraint placed upon the strictness patterns
67 propagated during compilation.}
68
69 \reference{Kevin Hammond}
70 {Exception Handling in a Parallel Functional Language: PSML}
71 {Proc TENCON '89, Bombay, India, Nov 1989}
72 {
73 Handling exception occurrences during computation is a problem  in  most
74 functional programming languages, even when the computation is eager and
75 sequential.  This paper presents a version of  the  error  value  method
76 which  allows lazy computation with deterministic semantics for parallel
77 evaluation even in the presence of  errors.   The  realisation  of  this
78 technique   is   illustrated  by  reference  to  PSML,  a  referentially
79 transparent variant of Standard ML designed for parallel evaluation.
80 }
81
82 \reference
83 {Phil Trinder and Philip Wadler}
84 {Improving list comprehension database queries}
85 {{\em TENCON '89\/} (IEEE Region 10 Conference),
86 Bombay, India, November 1989.}
87 {
88 The task of increasing the efficiency of database queries has recieved
89 considerable attention. In this paper we describe the improvement of
90 queries expressed as list comprehensions in a lazy functional
91 language. The database literature identifies four algebraic and two
92 implementation-based improvement strategies. For each strategy we show
93 an equivalent improvement for queries expressed as list
94 comprehensions.  This means that well-developed database algorithms
95 that improve queries using several of these strategies can be emulated
96 to improve comprehension queries.  We are also able to improve queries
97 which require greater power than that provided by the relational
98 algebra.  Most of the improvements entail transforming a simple,
99 inefficient query into a more complex, but more efficient form. We
100 illustrate each improvement using examples drawn from the database
101 literature.
102 }
103
104 %Sept
105
106
107 \reference{Simon L Peyton Jones and Jon Salkild}
108 {The Spineless Tagless G-machine}
109 {Proc IFIP Symposium on Functional Programming Languages and Computer
110 Architecture, London, Sept 1989}
111 {
112 The Spineless Tagless G-machine is an abstract machine based on graph
113 reduction, designed as a target for compilers for non-strict functional
114 languages.
115 As its name implies, it is a development of earlier work, especially
116 the G-machine and Tim.
117
118 It has a number of unusual features: the abstract machine code is
119 rather higher-level than is common, allowing better code generation;
120 the representation of the graph eliminates most interpretive overheads;
121 vectored returns from data structures give fast case-analysis;
122 and the machine is readily extended for a parallel implementation.
123
124 The resulting implementation runs at least 75\% faster 
125 than the Chalmers G-machine.
126 }
127
128 \reference
129 {Philip Wadler}
130 {Theorems for free!}
131 {{\em 4'th International Conference on Functional Programming
132 Languages and Computer Architecture}, London, September 1989.}
133 {
134 From the type of a polymorphic function we can derive a theorem
135 that it satisfies.  Every function of the same type satisfies the same
136 theorem.  This provides a free source of useful theorems,
137 courtesy of Reynolds' abstraction theorem for the polymorphic lambda
138 calculus.
139 }
140
141 %Aug
142
143 \reference{Kevin Hammond}
144 {Implementing Type Classes for Haskell}
145 {Proc Glasgow  Workshop  on  Functional  Programming,  Fraserburgh, Aug 1989}
146 {
147 This  paper describes the implementation of the type class mechanism for
148 the functional language Haskell, which has been  undertaken  at  Glasgow
149 University.  A simple introduction to type classes discusses the methods
150 used to  select  operators  and  dictionaries  in  the  Glasgow  Haskell
151 compiler.    A   solution   to  the  problem  of  selecting  super-class
152 dictionaries, not considered by the original paper  on  type  class,  is
153 also  presented.   The  modifications which must be made to the standard
154 Hindley/Milner type-checking algorithm  to  permit  the  translation  of
155 operators  are  described,  and  a  revised definition of algorithm W is
156 provided. Finally, a set of performance figures  compares  the  run-time
157 efficiency of Haskell and LML programs, indicating the overhead inherent
158 in the original, naive method of operator selection, and the improvement
159 which may be obtained through simple optimisations.
160 }
161
162 \reference{Simon L Peyton Jones}
163 {FLIC - a functional language intermediate code}
164 {SIGPLAN Notices 23(8) 1988, revised 1989}
165 {
166 FLIC is a Functional Language Intermediate Code, intended to
167 provide a common intermediate language between diverse
168 implementations of functional languages, including parallel
169 ones.
170 This paper gives a formal definition of FLIC's syntax and
171 semantics, in the hope that its existence may encourage greater
172 exchange of programs and benchmarks between research groups.
173 }
174
175 %July
176 \reference{Simon L Peyton Jones, Chris Clack and Jon Salkild}
177 {High-performance parallel graph reduction}
178 {Proc Parallel Architectures and Languages Europe (PARLE), LNCS 365, pp193-207, 
179 July 1989}
180 {
181 Parallel graph reduction is an attractive implementation for functional 
182 programming languages because of its simplicity and inherently distributed
183 nature.
184 This paper outlines some of the issues raised by parallel compiled
185 graph reduction, and presents the solutions we have adopted to produce an
186 efficient implementation.
187
188 We concentrate on two particular issues:
189 the efficient control of parallelism, resulting in an ability to alter
190 the granularity of parallelism 
191 {\em dynamically};
192 and the efficient use of the memory hierachy to improve locality.
193 }
194 %April
195
196 \reference{Simon L Peyton Jones}
197 {Parallel implementations of functional programming languages}
198 {Computer Journal 32(2), pp175-186, April 1989}
199 {
200 It is now very nearly as easy to build a parallel computer
201 as to build a sequential one, and there are strong incentives to do so:
202 parallelism seems to offer the opportunity to improve both the 
203 absolute performance level and the cost/performance ratio of our machines.
204
205 One of the most attractive features of functional programming languages
206 is their suitability for programming such parallel computers.
207 This paper is devoted to a discussion of this claim.
208
209 First of all, we discuss parallel functional programming
210 from the programmer's point of view.
211 Most parallel functional language implementations are based on graph reduction,
212 we proceed to a discussion of some implementation issues raised by parallel 
213 graph reduction.
214 The paper concludes with a case study of a particular parallel graph reduction
215 machine, GRIP, and a brief survey of other similar machines.
216 }
217 %Jan
218 \reference
219 {Philip Wadler and Stephen Blott}
220 {How to make {\em ad-hoc\/} polymorphism less {\em ad hoc}}
221 {{\em 16'th ACM Symposium on Principles of Programming Languages},
222 Austin, Texas, January 1989.}
223 {
224 This paper presents {\em type classes}, a new approach to {\em
225 ad-hoc\/} polymorphism.  Type classes permit overloading of arithmetic
226 operators such as multiplication, and generalise the ``eqtype variables''
227 of Standard ML.
228 Type classes extend the Hindley\X Milner polymorphic type system, and
229 provide a new approach to issues that arise in object-oriented
230 programming, bounded type quantification, and abstract data types.
231 This paper provides an informal introduction to type classes, and
232 defines them formally by means of type inference rules.
233 }
234 %88
235
236 \reference{Chris Hankin, Geoffrey Burn, and Simon L Peyton Jones}
237 {A safe approach to parallel combinator reduction}
238 {Theoretical Computer Science 56, pp17-36, North Holland, 1988}
239 {
240 In this paper we present the results of two pieces of work which, when
241 combined, allow us to take a program text of a functional langauge and
242 produce a parallel implementation of that program.
243 We present the techniques for discovering sources of parallelism in 
244 a program at compile time, and then show how this parallelism is
245 naturally mapped onto a parallel combinator set that we will define.
246
247 To discover sources of parallelism in a program, we use 
248 {\em abstract interpretation} a compile-time technique which is used
249 to gain information about a program which may then be used to optimise
250 the program's execution.
251 A particular use of abstract interpretation is in 
252 {\em strictness analysis}
253 of functional program.
254 In a language that has lazy semantics, the main potential for parallelism
255 arises in the evaluation of arguments of strict operators.
256
257 Having identified the sources of parallelism at compile time, it is 
258 necessary to communicate these to the run-time system.
259 In the second part of the paper we introduce an extended set of combinators,
260 including some parallel combinators, to achieve this purpose.
261 }
262
263
264 \reference{John T. O'Donnell and Cordelia Hall}
265 {Debugging in Applicative Languages}
266 {Lisp and Symbolic Computation, 1988}
267 {Applicative programming languages have several properties that appear
268 to make debugging difficult. First, the absence of assignment
269 statements complicates the notion of changing a program while
270 debugging. Second, the absence of imperative input and output
271 makes it harder to obtain information about what the program is doing.
272 Third, the presence of lazy evaluation prevents the user from
273 knowing much about the order in which events occur. Some solutions to
274 these problems involve nonapplicative extensions to the language.
275 Fortunately, the same features of applicative languages that cause
276 problems for traditional debugging also support an idiomatic 
277 applicative style of programming, and effective debugging techniques
278 can be implemented using that style. This paper shows how to implement
279 tracing and interactive debugging tools in a purely applicative
280 style. This approach is more flexible, extensive and portable
281 than debugging tools that require modification to the language
282 implementation.}
283
284 \reference{Simon L Peyton Jones, Chris Clack, Jon Salkild, Mark Hardie}
285 {Functional programming on the GRIP multiprocessor}
286 {Proc IEE Seminar on Digital Parallel Processors, Lisbon, Portugal, 1988}
287 {
288 Most MIMD computer architectures can be classified as 
289 tightly-coupled or loosely-coupled,
290 depending on the relative latencies seen by a processor accessing different
291 parts of its address space.
292
293 By adding microprogrammable functionality to the memory units, we have
294 developed a MIMD computer architecture which explores the middle region
295 of this spectrum.
296 This has resulted in an unusual and flexible bus-based multiprocessor,
297 which we are using as a base for our research in parallel functional programming
298 languages.
299
300 In this paper we introduce parallel functional programming, and describe
301 the architecture of the GRIP multiprocessor.
302 }
303
304 \reference{Geoffrey Burn, Simon L Peyton Jones, and John Robson}
305 {The spineless G-machine}
306 {Proc ACM Conference on Lisp and Functional Programming, Snowbird, pp244-258,
307 August 1988}
308 {
309 Recent developments in functional language implementations have
310 resulted in the G-machine, a programmed graph-reduction machine.
311 Taking this as a basis, we introduce an optimised method of
312 performing graph reduction, which does not need to build the
313 spine of the expression being reduced.
314 This Spineless G-machine only updates shared expressions, and
315 then only when they have been reduced to weak head normal form.
316 It is thus more efficient than the standard method of performing
317 graph reduction.
318
319 We begin by outlining the philosophy and key features of the
320 Spineless G-machine, and comparing it with the standard
321 G-machine.
322 Simulation results for the two machines are then presented and
323 discussed.
324
325 The Spineless G-machine is also compared with Tim, giving a
326 series of transformations by which they can be interconverted.
327 These open up a wide design space for abstract graph reduction
328 machines, which was previously unknown.
329
330 A full specification of the machine is given in the appendix,
331 together with compilation rules for a simple functional language.
332 }
333 %87
334
335 \reference{Simon L Peyton Jones and Chris Clack}
336 {Finding fixpoints in abstract interpretation} 
337 {in Abstract Interpretation of Declarative Languages,
338 ed Hankin \& Abramsky, Ellis Horwood, pp246-265, 1987.}
339 {
340 Abstract interpretation is normally used as the basis for
341 a static, compile-time analysis of a program.
342 For example, strictness analysis attempts to establish which
343 functions in the program are strict (we will use strictness
344 analysis as a running example).
345
346 Using abstract interpretation in this way requires the
347 compile-time evaluation of expressions in the abstract domain.
348 It is obviously desirable that this evaluation should
349 always terminate, since otherwise the compiler would risk
350 non-termination.
351 In the case of non-recursive functions there is no problem, and
352 termination is guaranteed.
353 Recursive functions, however, present more of a problem, and it
354 is the purpose of this paper to explain the problem and to
355 offer some practical solutions.
356 }
357
358 \reference{Simon L Peyton Jones}
359 {GRIP - a parallel processor for functional languages}
360 {Electronics and Power, pp633-636, Oct 1987;
361 also in ICL Technical Journal 5(3), May 1987}
362 {
363 A brief 4-page article about the GRIP architecture.
364 }
365
366 \reference{Simon L Peyton Jones, Chris Clack, Jon Salkild, and Mark Hardie}
367 {GRIP - a high-performance architecture for parallel graph reduction}
368 {Proc IFIP conference on Functional Programming Languages and 
369 Computer Architecture, Portland,
370 ed Kahn, Springer Verlag LNCS 274, pp98-112, Sept 1987}
371 {
372 GRIP is a high-performance parallel machine designed to execute
373 functional programs using supercombinator graph reduction.
374 It uses a high-bandwidth bus to provide access to a
375 large, distributed shared memory, using intelligent memory units and
376 packet-switching protocols to increase the number of processors
377 which the bus can support.
378 GRIP is also being programmed to support parallel Prolog and
379 DACTL.
380
381 We outline GRIP's architecture and firmware, discuss the major design
382 issues, and describe the current state of the project and
383 our plans for the future.
384 }
385 %86
386 \reference{Chris Clack and Simon L Peyton Jones}
387 {The four-stroke reduction engine}
388 {Proc ACM Conference on Lisp and Functional Programming,
389 Boston, pp220-232, Aug 1986}
390 {
391 Functional languages are widely claimed to be amenable to concurrent
392 execution by multiple processors.  This paper presents an algorithm for
393 the parallel graph reduction of a functional program.
394 The algorithm supports transparent management of parallel 
395 tasks with no explicit
396 communication between processors.
397 }
398
399 \reference{Simon L Peyton Jones}
400 {Functional programming languages as a software engineering tool}
401 {in Software Engineering - the critical decade D Ince,
402 Peter Peregrinus, pp124-151, 1986}
403 {
404 It is the purpose of this paper to suggest that functional
405 languages are an appropriate tool for supporting the activity
406 of programming in the large, and to present a justification of
407 this claim.
408 }
409
410 \reference{Simon L Peyton Jones}
411 {Using Futurebus in a fifth generation computer architecture}
412 {Microprocessors and Microsystems 10(2), March 1986}
413 {
414 Despite the bandwidth limitations of a bus, we present a design
415 for a parallel computer (GRIP) based on Futurebus, which limits bus
416 bandwidth requirements by using intelligent memories.
417
418 Such a machine offers higher performance than a uniprocessor
419 and lower cost than a more extensible multiprocessor, as well
420 as serving as a vehicle for research in parallel architectures.
421 }
422
423 \section{Internal reports}
424
425
426 \reference{Kevin Hammond}
427 {A Proposal for an Implementation of Full Dactl on a Meiko Transputer Rack}
428 {SYS-C89-02, University of East Anglia, 1989}
429 {
430 The  design  of  an  abstract  machine  instruction  set  for  Dactl  is
431 described.   The  instruction set is sufficient to encapsulate all Dactl
432 constructs; it will also permit  parallel  execution  where  applicable.
433 The  paper  considers the difficulties involved in the implementation of
434 this abstract instruction set on the  UEA  Meiko  M40  transputer  rack,
435 using  a  ZAPP-style  kernel.  Part of the code for a simulation of this
436 instruction set is included as an appendix to the report.
437 }
438
439
440 \reference{Kevin Hammond and John Glauert}
441 {Implementing Pattern-Matching Functional Languages using Dactl}
442 {University of Glasgow, 1989}
443 {
444 This paper describes the implementation of a family of  pattern-matching
445 functional  languages  in  the  parallel graph-rewriting language Dactl.
446 Attention  is   focussed   on   the   direct   implementation   of   the
447 pattern-matching   constructs   in  the  context  of  various  reduction
448 strategies: eager, lazy, and lazy with  strictness  analysis.   Two  new
449 reduction  strategies  combining  lazy  evaluation  with a technique for
450 compiling non-overlapping patterns are  also  illustrated.   The  latter
451 strategies   provide   improved  termination  properties  compared  with
452 conventional functional  language  implementations  for  non-overlapping
453 patterns.  The implementations described here cover all pattern-matching
454 constructs found in Standard  ML,  including  named  patterns  and  deep
455 patterns.   The  use  of  Dactl  renders  explicit  the  complexities of
456 pattern-matching which are obscured by implementation in a  conventional
457 intermediate language or abstract machine.
458 }
459
460 \reference{Simon L Peyton Jones}
461 {A practical technique for designing asynchronous finite-state machines}
462 {Proc Glasgow Workshop on Functional Programming, Fraserburgh,Aug 1989}
463 {
464 The literature on asynchronous logic design is mostly of a fairly theoretical
465 nature.   We present a practical technique for generating asynchronous finite-state
466 machines from a description of their states and transitions.  The technique
467 has been used successfully to design a number of state machines in
468 the GRIP mulitprocessor.
469 }
470
471 \end{document}