To return to Elrad's question, what qualifies as an aspect-oriented language? Let us consider some possibilities:
Rule-based systems. Roughly speaking, rule-based systems like OPS-5 [5] or, to a lesser extent, Prolog, are programming with purely dynamically quantified statements. Each rule says, "Whenever the condition is true, do the corresponding action." (We are ignoring the tendency of some rule-based systems to execute exactly one matching rule and then recompute the matching rule set.) If we all programmed with rules, we wouldn't have AOP discussions. We would just talk about how rules that expressed concerns X, Y, and Z could be added to the original system, with some mention of the tricks involved in getting those rules to run in the right order and to communicate with each other. The base idea that other things could be going on besides the main flow of control wouldn't be the least bit strange. (Laddaga et al. proposed doing AOP with AI-style inference [30].)
But by and large, people don't program with rule-based systems. This is because rule-based systems are notoriously difficult to code. They've destroyed the fundamental sequentiality of almost everything. The sequential, local, unitary style is really very good for expressing most things. The cleverness of classical AOP is augmenting conventional sequentiality with quantification, rather than supplanting it wholesale.
Event-based publish-and-subscribe. In EBPS systems, the subscription mechanism is precisely a quantification mechanism. ("Let me know whenever you see something like. . . .") The question, then, is "Is EBPS oblivious?" If the application's programming style is to use events as the interface among components or if the underlying system automatically generates interesting events, then EBPS can be used as a black-box AOP mechanism. On the other hand, if we expect the programmer to scatter event generation for our purposes throughout otherwise conventional programs, then one cannot program EBPS obliviously, and hence it is not AOP.
Frameworks. Framework systems [10] provide a high-level organization (a main flow of control) into which the application programmer plugs behavior at particular points. In some sense, a framework comes with a particularly defined set of concerns and allows plugging in (and separately specifying) just those concerns. Often frameworks will have default behaviors for these concerns. While frameworks provide a way of separating certain concerns, their restriction to a set of predefined concerns and often predefined though parameterized behaviors keeps the framework mechanism from rising to the level of a language for separating concerns.
Domain-specific languages. Domain-specific languages (DSLs) offer small, often declarative syntax and semantics for programming a particular domain [43]. Examples of domain-specific languages are SQL, HTML, and yacc. DSLs succeed in intermixing crosscutting concerns into programs but, like frameworks, crosscut only the concerns anticipated by the language designer and often only with the mechanisms built into the language.
Intentional programming and meta-programming. Intentional programming (IP) [1] and meta-programming (MP) [26] provide the ability to direct the execution order in arbitrarily defined computational patterns. They can be seen as environments for writing transformation compilers (that is, a mechanism for implementing clear-box AOP), rather than as self-contained realizations of the AOP idea.
Generative programming. Similarly, generative programming [11] works by transforming higher-level representations of programs into lower-level ones (that is, by compiling high-level specifications). By incorporating aspects into the transformation rules, one can achieve AOP in a generative programming environment.
