AOSD'03 keynote talk, and DSF again

[Pascal Costanza <address@hidden>]

Here is a follow-up to the DSF discussion we had a few weeks ago. This 
is a rather long post, and the connection to DSF (dynamically scoped 
functions) will become clear only in the last paragraph.

In his AOSD 2003 keynote talk [1], Gregor Kiczales gives an account of 
what he thinks is the main contribution of the AOSD community so far. 
He also gives a perspective on the future of AOSD.

In both respects, I have strong doubts whether the claims he makes are 
sound. Here is why.

Wrt to the future of AOSD he characterizes join point mechanisms as 
re-registration mechanisms. He refers to the book "On the Origin of 
Objects" by Brian Smith. See the notes for slide 36:  "Brian talks 
about a process of registration, that involves identifying objects out 
of a fog of undifferentiated stuff". However, on slide 38 Gregor has 
made a slight change to the wording and talks about a "fog of JPs". 
However, this is a very strong change in meaning, because join points 
are by definition not undifferentiated. Events in a computer, at least 
in computers as we know them today, are always differentiated, no 
matter how fine the granularity. Indeed, Mitchell Wand characterizes 
join point models as "shared ontologies" [2], which seems to be closer 
to what is proposed in Gregor's talk. On the other hand, Brian Smith 
explicitly denies the possibility of reasonable ontologies of this 
kind. See [3]. So I think these two views are not compatible. I believe 
that the field of AOSD would be too narrow if we would require 
researchers to believe in the possibility of ontological bases.


With respect to the contribution of the AOSD community - the issue that 
is more important to me -, Gregor points out the space of join points 
as the main discovery (see the notes for slide 28). A join point 
mechanims is said to consist of a model for join points, a means of 
identifying join points, and a means of semantic effect at join points 
(slide 25).

An important comment wrt join point mechanisms is made in the notes for 
slide 27: "we don't yet have a clear model of this space, but we know 
that there is a space of JPMs here". I disagree: I don't think that 
there is a genuine space of join point mechanisms, and it's not clear 
that we will ever have a model of such a space apart from what we 
already know in programming language research in general.

In order to back my claim, let's first assume for a moment that such a 
genuine space of join point mechanisms really exists. What are the 
requirements for a good characterization of that space? I see two: a) 
we need to be able to describe all conceivable ways to identify join 
points and b) identification of join points should be possible in a 
relatively convenient way.

These requirements can be achieved in a systematical fashion, by 
looking at what an AOP language must do to reach its goals: it must be 
able to analyze and change the behavior of programs. The only data an 
AOP language can get hold of to do this are the syntax trees for 
concrete programs. Abstract syntax trees are recursively defined data 
structures. The most straightforward way to traverse a recursively 
defined data structure is via recursively defined 
functions/methods/procedures. This ensures that any conceivable 
analysis can in fact be carried out. Any approach that does not cover 
all branches of such a data structure is necessarily less powerful. 
This implies that a general-purpose join point mechanism must be 
computationally complete.

The idea that a restricted pointcut language will do the job for 
"most", or the "important" cases seems to be attractive. However 
especially when one cares about ilities, the language with which to 
identify join points should be a general one because otherwise one 
risks that a base program needs to be refactored in order to fit the 
constructs of the aspect language. (Such a refactoring might not be 
feasible in all circumstances.) Even if the notion of a restricted join 
point languages is pursued in order to make them more convenient, the 
very space of join point languages will always consist of subsets of 
general languages that are able to traverse arbitrary syntax trees, and 
therefore the range of possible subsets is defined by the general ones.

Now, the important point is that we already have approaches for 
general-purpose traversal (and subsequent modification) of program 
representations. The ones that come to my mind are program 
transformation frameworks (like JMangler), Lisp-style macros (that are 
also available for other languages like Dylan and Java, for example 
Java Syntactic Extender) and logic metaprogramming (like SOUL). This in 
turn means that the "space of join point mechanisms" is decidedly not a 
genuinely new contribution. So no, the AOSD community has not 
discovered the space of join point mechanisms, it has only rediscovered 
it.

However, it is still pretty obvious that AOP is not just macro 
programming in disguise. In terms of Robert Filman's analysis, AOP is 
quantification and obliviousness. Quantification is captured in a 
general sense by traversals of syntax trees, as described above. What 
AOP adds here are language constructs to make quantification more 
convenient. This is like creating new iteration constructs on top of 
the general notion of recursion, not more and not less.

On the other hand, obliviousness can be achieved by language constructs 
that effect the behavior of a program beyond the scope of the concrete 
part of the syntax tree being traversed and transformed. Especially in 
the case of macros, the scope that is by default the only one being 
influenced is the textual, i.e. lexical scope enclosed by a macro. The 
only way known as yet to "break out" of the lexical scope and influence 
other parts of a program are language constructs that provide 
dynamically scoped definitions. In this sense, I stand by my claim that 
dynamically scoped (re)definitions of functions are the essence of AOP: 
they effectively model that ingredient of AOP that has not been 
available before in other language paradigms. [4]


Pascal


[1] slides available at http://www.cs.ubc.ca/~gregor/
[2] see http://doi.acm.org/10.1145/944746.944732 - see also the slides 
for his talk at http://www.ccs.neu.edu/home/wand/
[3] "The Foundations of Computing", 
http://www.ageofsig.org/people/bcsmith/print/smith-foundtns.pdf
[4] At least, I have not found any examples of language constructs that 
intentionally allow for dynamically scoped functions in the literature, 
as described in my DSF paper, except in a very limited form as 
exception handlers.