Research Directions in Parallel Functional Programming

1. Front Matter

   Pages I-XXVI

   PDF

2. Fundamentals

   1. Front Matter

      Pages 1-1

      PDF

   2. Introduction

      • Kevin Hammond, Greg Michaelson

      Pages 3-29

   3. Foundations

      • Greg Michaelson, Kevin Hammond, Chris Clack

      Pages 31-61

   4. Programming Language Constructs

      • Rita Loogen

      Pages 63-92

   5. Proof

      • Simon J. Thompson

      Pages 93-119

   6. Realisations for Strict Languages

      • Werner Kluge

      Pages 121-148

   7. Realisations for Non-Strict Languages

      • Chris Clack

      Pages 149-187

3. Current Research Areas

   1. Front Matter

      Pages 189-189

      PDF

   2. Data Parallelism

      • John O’Donnell

      Pages 191-206

   3. Cost Modelling

      • David Skillicorn

      Pages 207-218

   4. Shaping Distributions

      • C. Barry Jay

      Pages 219-232

   5. Performance Monitoring

      • Nathan Charles, Colin Runciman

      Pages 233-246

   6. Memory Performance of Dataflow Programs

      • A. P. Willem Böhm, Jeffrey P. Hammes

      Pages 247-265

   7. Portability of Performance in the BSP Model

      • Jonathan Hill

      Pages 267-287

   8. Algorithmic Skeletons

      • Murray Cole

      Pages 289-303

   9. Coordination Languages

      • Paul Kelly, Frank Taylor

      Pages 305-321

   10. Parallel and Distributed Programming in Concurrent Clean

       • Rinus Plasmeijer, Marko van Eekelen, Marco Pil, Pascal Serrarens

       Pages 323-338

   11. Functional Process Modelling

       • Ali Abdallah

       Pages 339-360

   12. Validating Programs in Concurrent ML

       • Flemming Nielson

       Pages 361-378

Programming is hard. Building a large program is like constructing a steam locomotive through a hole the size of a postage stamp. An artefact that is the fruit of hundreds of person-years is only ever seen by anyone through a lOO-line window. In some ways it is astonishing that such large systems work at all. But parallel programming is much, much harder. There are so many more things to go wrong. Debugging is a nightmare. A bug that shows up on one run may never happen when you are looking for it - but unfailingly returns as soon as your attention moves elsewhere. A large fraction of the program's code can be made up of marshalling and coordination algorithms. The core application can easily be obscured by a maze of plumbing. Functional programming is a radical, elegant, high-level attack on the programming problem. Radical, because it dramatically eschews side-effects; elegant, because of its close connection with mathematics; high-level, be­ cause you can say a lot in one line. But functional programming is definitely not (yet) mainstream. That's the trouble with radical approaches: it's hard for them to break through and become mainstream. But that doesn't make functional programming any less fun, and it has turned out to be a won­ derful laboratory for rich type systems, automatic garbage collection, object models, and other stuff that has made the jump into the mainstream.

• algorithm
• algorithms
• distributed programming
• functional programming
• portability
• programming
• programming language

• Division of Computer Science, University of St Andrews, St Andrew, Fife, UK

  Kevin Hammond

• Department of Computing and Electrical Engineering, Heriot-Watt University, Riccarton, Edinburgh, UK

  Greg Michaelson

Policies and ethics