Refunctionalization at Work
First-order programs are desired in a variety of settings and for a variety of reasons. Their coming into existence in first-order form may be unplanned or it could be the deliberate result of a form of “firstification” such as closure conversion, (super)combinator conversion, or defunctionalization. In the latter case, they are higher-order programs in disguise, just as iterative programs with accumulators are often recursive programs in disguise.
This talk is about Reynolds’s defunctionalization [1, 2]. Over the last few years, we have observed that a number of existing first-order programs turn out to be in the range of defunctionalization, and therefore they directly correspond to higher-order programs, even though they were designed independently of any higher-order representation. Not all first-order programs, however, are in defunctionalized form.
The goal of this talk is to refine our earlier characterization of what it means to be in defunctionalized form , and to investigate how one can tease a first-order program into defunctionalized form. On the way, we present a variety of independently known programs that are in (or can be teased into) defunctionalized form, and we exhibit their functional counterpart—a process we refer to as ‘refunctionalization’ since it is a left inverse of defunctionalization.
KeywordsSoftware Engineer Formal Language Left Inverse Recursive Program Declarative Programming
- 1.Reynolds, J.C.: Definitional interpreters for higher-order programming languages. In: Proc.of 25th ACM Nat. Conf., pp. 717–740. ACM Press, New York (1972); Reprinted in Higher-Order and Symb. Comput. 11(4), 363–397 (1998)Google Scholar