Abstract. The box calculus is a formalism for reasoning about the properties of multi-process systems which enables account to be taken of pragmatic as well as computational concerns. It was developed for the programming language Hume which explicitly distinguishes between coordination, based on concurrent boxes linked by wires, and expressions, based on polymorphic recursive functions. This chapter introduces Hume expressions and surveys classic techniques for reasoning about functional programs. It then explores Hume coordination and the box calculus, and examines how Hume programs may be systematically transformed while maintaining computational and pragmatic correctness.
OverviewHaving constructed programs that meet their specifications, we often want to change them to take advantage of changing operating environments. For example, we might want to migrate a program from environments with smaller to larger numbers of processors to improve performance, in particular as the number of cores grows in new generations of the same CPU architecture. In changing programs, we want to ensure not only they still meet their original specifications, but also that their pragmatic (i.e. time, space, sequencing) behaviours change in well understood ways. In particular, in making what appear to be local improvements to a program, for example by introducing parallelism, we want to avoid unexpected global impacts that make overall performance worse, for example as a result of unanticipated additional communication or scheduling costs. Thus, we need some means of reasoning about changes to programs that can account for pragmatic as well as computational program properties.Most software is constructed in imperative programming languages; abstractions from von Neumann architectures 1 based on sequences of state changes mediated by mutable memory. Here, different program components interact by manipulating the same memory areas. Thus, changing the order of component execution often changes the sequence of memory manipulation, changing what the program does. This complicates reasoning about imperative programs because the state change sequencing must be made explicit in the reasoning 1 And also Harvard architectures.