My decision to specify (and implement) C language extensions to serve as annotations for a clever compiler was driven primarily by the fact that C is widely used, hence developing a system which can improve performance for programs written in C will be pragmatically more useful than developing such a system for a language which is used for research only. Extending with a functional language with quasistatic constructs would have been simpler than extending C; however, only a small proportion of the total compute cycles consumed each day are consumed by programs written in functional languages. In addition to being imperative, C was more difficult to work with because the language model of multiple source files compiled independently has traditionally made certain kinds of global program analysis more difficult.
It is difficult to ascertain whether the constructs described in this chapter are sufficient for the programmer to adequately communicate to the clever compiler what the different versions of the program are. There certainly does not seem to be any hope of proving anything meaningful about whether they would be sufficient when what they might be sufficient for is not formally defined. Actual usage would be necessary so that programmers can provide feedback to the clever compiler writer as to when the existing constructs are inadequate, and what modifications or additional syntax would be necessary. Strict sufficiency aside, there's also the question of how convenient these constructs are to use --- and not just by human programmers. Although not explored further in this thesis, human programmers are not necessarily the only ``users'' of these constructs. Yet another stepping stone between clever and smart compilers might be provided by additional independent compiler passes which generate alternatives based on partial, limited analysis and then used the kinds of constructs described in this chapter to express the results of the analysis; i.e., the writers of those kinds of passes would not need to worry about the details of selecting between the alternatives, but only need to know how to generate them. Such usage might generate different criteria for sufficiency or convenience.
Stroustrop claims that one of the criteria he used in evaluating whether particular proposals for extensions to the / language was whether they were simple enough that within 10 minutes of explanation to a group of programmers, the audience would understand the proposal well enough to be asking questions about how to use the extensions in particular scenarios with implications which neither Stroustrop nor the proposers had considered. Hopefully, these constructs fall into that category --- simple enough to quickly understand, and yet sufficient to provoke interesting questions with implications about the clever compiler and quasistatic computing.