The overhead of spawning a new task to compute some expression in a functional language is often high. It is therefore important to know that the amount of work that the spawned task will do is enough to cover the costs of its creation, initial setup, and destruction.

The proposed solution uses a combination of abstract interpretation at compile time, to find those places where complexity depends on the size of data structures, and runtime approximation of the actual sizes of data structures as computation proceeds. Results using a functional language on a shared-memory parallel computer show execution time reductions as large as 20 percent.

The actual data structures used are cons lists. I remain mystified by the continual appearance of a data structure so inherently sequential in functional languages intended for parallel execution. Cons lists are relatively easy to analyze, but they are not very useful for solving problems in parallel. As the authors point out, their idea extends to more useful data structures, such as join lists and trees, but it becomes much more complex. Its actual performance on richer data structures remains an open question.

Surprisingly, the authors do not discuss the large body of European work on compilation of functional languages for parallelism. Many systems have actually been built, so their designers must have faced up to the issue of subtask creation. Indeed some, such as Flagship and Grip, have had to do it for distributed-memory targets, where the costs are correspondingly higher. A comparison of the present result with existing techniques would have strengthened the paper.