Don’t let the title fool you--this paper is only partly about the technical details of some seemingly obscure program transformation technique. This engagingly written paper brings the reader along a much richer discovery path, toward organizing the various high-level transformations performed by high-level language processors.

Danvy and Millikin first define refunctionalization very carefully, using appropriate examples to illustrate the key ideas. Briefly, refunctionalization is seen as a (left) inverse to the better-known defunctionalization technique of Reynolds, used to rewrite higher-order programs as first order. It is when the technique is put into the context of many other standard--or should-be standard--techniques (such as disentangling, direct style, function merging, continuation-passing style (CPS) transformation, and so forth) that the paper really shines. We get the feeling that the authors have really learned something deeper about the structure of programs and are doing their very best to explain it to us.

However, I wish the authors had been more explicit in pointing out that refunctionalization is most definitely not a unique transformation, but rather a family of transformations, just as defunctionalization involves choices--for example, of data types. Real interpreters do not use association lists to implement environments; the reader is left to wonder if this is intrinsic to these methods or not. My impression is that it is not; this issue could well deserve a sequel.