strictness analysis aids time analysis
Analyzing time complexity of functional programs in a lazy language is problematic, because the time required to evaluate a function depends on how much of the result is needed in the computation. Recent results in strictness analysis provide a formalisation of this notion of need, and thus can be adapted to analyse time complexity. The future of programming may be in this paradigm: to create software, first write a specification that is clear, and then refine it to an implementation that is efficient. In particular, this paradigm is a prime motivation behind the study of functional programming. Much has been written about the process of transforming one functional program into another. However, a key part of the process has been largely ignored, for very little has been written about assessing the efficiency of the resulting programs. Traditionally, the major indicators of efficiency are time and space complexity. This paper focuses on the former. Functional programming can be split into two camps, strict and lazy. In a strict functional language, analysis of time complexity is straightforward, because of the following compositional rule : The time to evaluate (( g x )) equals the time to evaluate ( g x ) plus the time to evaluate ( y ), where y is the value of ( g x ). However, in a lazy language, this rule only gives an upper bound, possibly a crude one. For example, if  is the head function, then ( g x ) need only be evaluated far enough to determine the first element of the list, and this may take much less time than evaluating ( g x ) completely. The key to a better analysis is to describe formally just how much of the result needs to be evaluated; we call such a description a context . Recent results in strictness analysis show how such contexts can be modelled using the domain-theoretic notion of a projection [WH87]. This paper describes how these results can be applied to the analysis of time complexity. The method used was inspired by work of Bror Bjerner on the complexity analysis of programs in Martin-Lf's type theory [Bje87]. The main contribution of this paper is to simplify Bjerner's notation, and to show how contexts can replace his demand notes. The language used in this paper is a first-order language. This restriction is made because context analysis for higher-order languages is still under development. An approach to higher-order context analysis is outlined in [Hug87b]. Context analysis is based on backwards analysis, rather than the earlier approach of abstract interpretation; both are discussed in [AH87]. Some work on complexity analysis [Weg75,LeM85] has concentrated on automated analysis: algorithms that derive a closed form for the time complexity of a program. The goal here is less ambitious. We are simply concerned with describing a method of converting a functional program into a series of equations that describe its time complexity. This modest beginning is a necessary precursor to any automatic analysis. The time equations can be solved by traditional methods, yielding either an exact solution, an upper bound, or an approximate solution. (Incidentally, although [LeM85] claims to analyse a lazy language, the analysis uses exactly the composition rule above, and so is more suited for a strict language.) The analysis given here involves two kinds of equations. First are equations defining projection transformers that specify how much of a value is needed. Second are equations that specify the time complexity; these depend on the projection transformers defined by the first equations. In both cases, we will be more concerned with setting up the equations that with finding their solutions. As already noted, traditional methods may be applied to satisfy the time complexity equations. Solving the projection transformer equations is more problematic. In some cases, we can find an appropriate solution by choosing an appropriate finite domain of projections, and then applying the method of [WH87] to find the solution in this domain. In other cases, no finite domain of solutions is appropriate, and we will find a solution by a more ad-hoc method: guessing one and verifying that it satisfies the required conditions. More work is required to determine what sort of solutions to the projection transformer equations will be most useful for time analysis, and how to find these solutions. This paper is organized as follows. Section 1 describes the language to be analysed. Section 2 presents the evaluation model. Section 3 gives a form of time analysis suitable for strict evaluation. Section 4 shows how projections can describe what portion of a value is needed, and introduces projection transformers. Section 5 gives the time analysis for lazy evaluation. Section 6 presents a useful extension to the analysis method. Section 7 concludes.
analysis time analysis timing time complexity complexity functional programming functional program language evaluation value computation future software writing implementation efficiency motivation process space paper functional languages compositing examples context model project method complex analysis type theory developer abstraction automation algorithm approximation ad-hoc sorting extensibility analysis method order