Hi Theo, Jeff and Pengcheng:

I have reformulated the algorithmic issues behind aspect interfaces.

I think it is very useful to find algorithms to compute EQUIV[G](s).

Feedback please before we send this to Ravi.

-- Karl
===============================
When designing aspect interfaces it is important to
know all the constraints that must hold whether they
are explicit or implicit.

The implicit constraints should become explicit by using algorithmic
support.

For a simple example consider the context of adaptive methods
and the interface class graph G:

Program = List(ClassDef).
ClassDef = ClassName List(Part).
Part = PartName ClassName.

and the explicit constraint (we call it a constraint because we mean
that TraversalGraph(s,G) is non-empty):

"from Program to PartName"

The implied, implicit constraints are:

s1 = from Program via ClassDef to PartName
s2 = from Program via Part to PartName
s3 = from Program via ClassDef via Part to PartName

s1 says that we will visit all ClassDef-objects on paths to PartName
and this may be crucial for the correct functioning of the adaptive method
which is written against the interface class graph.

We need a design tool that helps us to find the implicit constraints.

Given a (interface) class graph G and a strategy s,
we want to know the set of strategies equivalent to s: EQUIV[G](s).
s1 and s2 are equivalent for G if PathSet[G](s1) = PathSet[G](s2).
The general rule for an interface class graph G is that in all implementations
the set of all strategies in EQUIV[G](s) must be satisfiable and the same strategy equivalences
must hold.

We need a precise definition of "implementation". For an example, see the NSF proposal.

The set EQUIV[G](s) is expected to be small in practice although in general
it will grow exponentially in the size of G.

The formulation above is for class graphs and strategies but it
readily generalizes to meta graphs and selector expressions in general.