Abstract: Functional programming languages and their implementations are basically well-understood, and research is drifting towards topics that are not specific to functional languages. Several questions arise from this changed situation: Is there any reason to prefer functions as units of programming over other forms, such as predicates, relations, objects, processes, etc.? Will functional programming become just one of many alternatives in hybrid programming languages of the future, or are there any special properties that make functional programming particularly attractive?
In the present paper, we argue that most of the virtues attributed to the functional style of programming and to functional languages are not at all specific to the use of functions as the basic units of programming. In particular, we propose to view the λ-calculus not as a calculus of functions, but as a calculus of abstractions, abstractions which can be used uniformly over different basic units of programming. Their support for a general scheme of abstraction is one of the major attractions of functional languages.
Support for abstraction is also a major topic of the language design methods based on semantic principles, as collected by Tennent and Morrison in the late 1970s. We find that functional languages are, in many respects, designed according to these principles, and we show how the principles can also aid the design of extensions to functional languages, e.g., to support input/output or modular programming. This approach leads to a language design with `first-class modules' and support for persistence while keeping the overall language simple and general, much in the style of the functional core.
This report presents some afterthoughts on the design issues that were the topic of my PhD thesis work. Most of it was written immediately after I submitted my thesis, and a draft was presented at the Workshop on the Implementation of Functional Languages, St. Andrews, UK 1997. As it seemed to find many interested readers, it was later turned into a technical report (NOTTCS-TR-98-2) for ease of reference (please note that it is not included in the official IFL workshop proceedings).