Hi Pengcheng:

I think we should follow Mitch's advice and replace
section 6 with new text. Enclosed are some thoughts.
Please work them out and put them into section 6.

-- Karl

AspectJ programs that are written in static per-execution style,
such as the LoD class form checker, serve as designs
for static checkers that solve the problem for all executions.
We present a vision for how AspectJ 
could be extended with statically executable advice.

The AspectJ compiler provides for a given 
AspectJ program p an object called AST(p) of a
class dictionary (grammar) for AspectJ. (This
is analogous to the Java Data Binding approach where
an XML schema is used to both define classes and a language
and a parser and printer to move between objects and
language elements.) We use the facilities of AspectJ
to write programs for these classes by introducing methods
and advising them. 

Our vision of having statically executable advice in AspectJ
has the following ingredients:

1. An AspectJ program may have a static part that computes
information related to the static part of join points in the program.
The information is made available to the ordinary dynamic
part of the AspectJ program.
2. The static part is linked to an API for exploring and manipulating
the abstract syntax tree of AspectJ programs. The API has
capabilities copied from the DemeterJ API: getters, setters, constructors,
predefined visitors (PrintVisitor, DisplayVisitor, EqualVisitor, etc.)
and support for traversals as in DAJ (Demeter/AspectJ).
3. The regular dynamic part can access information computed in the
static part through thisJoinPointStaticPart and
thisEnclosingJoinPointStaticPart.

The clean separation into a static part and a dynamic part
with communication through the static part of join points
avoids many complications. It is sufficient to statically exprees the CF
of LoD but it has many other applications.