A challenge of many transformation-based generators is that they are trying to achieve three mutually antagonistic goals simultaneously: 1) deeply factored operators and operands to gain the combinatorial programming leverage provided by composition, 2) high-performance code in the generated program, and 3) small (i.e., practical) generation search spaces. The anticipatory optimization generator (AOG) has been built to explore architectures and strategies that address this challenge. The fundamental principle underlying all of AOG's strategies is to solve separate, narrow, and specialized generation problems by strategies that are narrowly tailored to specific problems rather than a single, universal strategy aimed at all problems. A second fundamental notion is the preservation and use of domain-specific information as a way to gain extra leverage on generation problems. This paper focuses on two specific mechanisms: 1) Localization: the generation and merging of implicit control structures and 2) Tag-directed transformations: a new control structure for transformation-based optimization that allows differing kinds of retained domain knowledge (e.g., optimization knowledge) to be anticipated, affixed to the component parts in the reuse library, and triggered when the time is right for its use.

No abstract available.

No abstract available.

Defining domain-specific abstractions for generator systems leads to a quandary between choosing abstractions that exhibit powerful programming amplification through the combinatorial opportunities provided by composition, and choosing abstractions that can be easily transformed into high-performance code. Most generators opt for abstraction to improve programming productivity, which usually compromises target program performance. Transformation-based generators widen the quandary through deep factorization of operators and operands to amplify expressive power, but this explodes the search space. My hypothesis is that existing architectures are inadequate to achieve simultaneously high levels of abstraction, high-performance target programs and small solution search spaces. To explore architectural variations to address this quandary, I have implemented a generator in Common LISP designed specifically to address these problems. It is called the Anticipatory Optimization Generator (AOG) because it allows programmers to anticipate optimization opportunities and to prepare an abstract, distributed plan that attempts to achieve them.

Combinatorial increases in programming productivity are possible by the introduction of high level operators and operands for composite data structures such as arrays, matrices, trees, record composites, etc. Such operators and operands can be composed to generate combinatorially many virtual components. However, the performance of such compositions is often inadequate because of code fragmentation and delocalization engendered by the building blocks. Attempts to automatically reorganize this code to optimize performance using conventional optimization strategies are usually impractical because of the large search spaces engendered. Anticipatory optimization (AO) is a method for compiling such compositions directly to optimized code without large search spaces and indeed, without any search space at all. The keys to AO are: distributed optimization plans expressed via code annotations; and transformation based optimization planning that concurrently reasons over the domain information, the generated program and the evolving optimization plan.

For domain analysis to provide operators and operands that have the ability to both combinatorially amplify programming productivity and provide high performance code, we have to provide optimization strategies that can automatically localize code without engendering the huge search spaces of conventional optimization and transformation methods. The author proposes the method of Anticipatory Optimization to accomplish this task. AO turns a large search space into a super highway.

No abstract available.

The growth of component libraries puts them on a collision course with a key reuse problem-the difficulty in scaling reuse libraries in both component sizes and feature variations. Because of the concreteness of conventional, mainstream programming languages, one is torn between combinatorial growth of reuse libraries containing components with good run-time performance, or linear growth with poor performance. The paper identifies the extensions necessary to solve the scaling problem, notably 1) factored component libraries based on a "layers of abstraction " notion, 2) a composition operator and compile-time generator to manufacture combinatorially many custom components from compositions of factors, and 3) extra-linguistic attributes associated with individual programming constructs to make inter-factor dependencies explicit and machine processable. This paper analyses and compares existing reuse systems that contain instances of these extensions and indicates the directions for factored component libraries.>

Good technology should make a difference where it counts-in the market place, but I have noticed an interesting phenomenon. The goodness of technology does not make much of a difference, at least in the short term. Measured by the market place, Visual Basic's VBX componentry is a wildly successful example of reuse. While the Visual Basic System itself is quite an elegant system and the interface to VBX components is clean and simple, the technology weakness of VBX components is the BASIC programming language. And yet, VBX components are a success by almost any measure. The biggest factor in their success seems to be that they solve real application problems with great ease, providing a great deal of programming leverage. On the other hand, looking at object oriented programming (OOP) languages I see a lot of pretty elegant technology. On the whole, OOP is a powerful and elegant technology. But measured by the VBX componentry available, OOP's componentry is pretty weak. Much as we might like to believe that OOP or VBX technology is a revolutionary paradigm shift, they probably are not. And thus, they are probably second order terms in the equation that determines success. They succeed or fail for other reasons-first order reasons. VBX components succeed largely because they were born in the mainstream of the desktop revolution. Likewise, OOP is a small technological delta that is somewhat out of the mainstream of this revolution and to the degree that it is, it seems to be a less than stellar example of reuse success.>

Development environments are entering a period of dramatic change. A major component of this change is a reorientation toward domain driven environments including an integration of domain-oriented support tools. This reorientation will bring about a decline in the role of conventional programming languages and at the same time force an evolution toward more abstract programming representations more abstract in the sense that most of the implementation details (as they are currently known) will be abstracted away. Thus, development is moving farther away from conventional software engineering models and closer to the problem.>