[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [aosd-discuss] Dynamically scoped functions
Gregor Kiczales wrote:
> (warning, this message is long!)
> I guess I think this framework misses key aspects of AOP.
> I do agree that there is a sense in which the cflow pointcut feels like
> a "lexically scoped dynamic binding". But to try to cast all of AOP into
> this intuitition doesn't work.
> Some of the problems I see with the dynamic binding characterization are:
> - Dynamic binding is too restrictive for AOP.
> We want AOP to be able to have pointcuts that involve static
> analysis as well. Consider just the simple within pointcut
> in AspectJ.
> Or consider the more elaborate example from my AOSD talk
> [http://tinyurl.com/p22w]. In that example, we want the pointcuts
> to work in terms of a static control flow analysis. We essentially
> write a pointcut that says "find the places control can reach from
> here, and do something interesting there".
Both examples are concerned with field accesses, AFAICT. (At least, the
examples I have seen so far for "within" are concerned with field
accesses as well.)
I think Java's approach for handling fields is broken, and I think most
people would agree who have tried to implement language extensions for
Java. So for the time being, I take the freedom to ignore field access
issues. ;) (More below.)
wrt "pcflow" - wouldn't you need to capture the "real cflow" anyway,
according to the notion of Jumping Aspects? What does "pcflow" add then?
> There are a number of interesting aspects that could use such
> functionality, and several researchers are working in this area.
I would be very happy to see examples that go beyond field access issues.
> - dflet is too restrictive.
> We don't want to have to wrap the entry to the computation in a
> dflet. This interferes with non-invasiveness (obliviousness).
This is very straightforward to fix. Just redefine that entry.
> - Just functions is too restrictive.
> We want join points to be able to be other things, like field
Huh?!? You probably know best that field accesses are also modelled as
function calls in CLOS. (...and - before that issue comes up - that it
doesn't necessarily interfere with efficient execution.)
> - Lack of compositional crosscutting.
> We want to be able to write things like:
> (see http://tinyurl.com/p259 for details of ... )
> pointcut move(): ...;
> pointcut topLevelMove(): move() && !cflowbelow(move());
> The poincuts are the crosscutting mechanism. They let you take
> a cut or slice through the code (or execution) and affect
> semantics there. And, critically, the pointcuts are compositional.
> (The ll1-discuss people remember Hal and Gerry saying that
> PL mechanisms have to be compositional and support abstraction.)
> I don't see that the dflet mechanism is compositional.
Take a look at multidflet. It takes a list of function names as a
parameter. All I need now is another function that produces a list of
function names to be captured by multidflet.
Any approach that allows one to write functions that produce lists of
function names would be candidates for valid pointcut models.
For example, it seems to me that the best way to handle negative
information ("!cflowbelow") is a logic metaprogramming approach (in the
sense of SOUL and Tyruba). It's pretty easy to include a logic
programming framework in Common Lisp...
> Of course you could fix these problems easily enough. You could:
> - Add more kinds of points than function calls. Maybe call
> them join points!
See above. Everything can be modelled as a function call in Lisp.
> - Define compositional predicates on those points. Maybe
> call them pointcuts!!
See above. multidflet is able to cooperate with any function that
produces lists of function names. (It's interesting to note that this
marks a line between base-level and meta-level programming: while dflet
is purely at the base level, functions that produce lists of function
names are clearly at the meta level.)
> - Make it possible to define advice on pointcuts globally,
> to get complete non-invasiveness (obliviousness) back.
> Maybe call this advice!!! :)
(setf (symbol-function 'main)
(lambda (&rest args)
> I think that would end up being pretty close to the characterization
> in Mitch Wand's papers.
I haven't read his papers in detail yet. On a first sweep it seems to me
that his work is more concerned with semantic descriptions of "full" AOP
whereas I am more concerned with the isolation of the fundamental
I am not claiming that my paper provides everything you will ever need
to do AOP. However, I think it describes the essential contribution of
AOP. From a Lisp perspective, everything else is pretty straightforward
macrology. (Or at least, it gets you very far...)
Pascal Costanza University of Bonn
mailto:email@example.com Institute of Computer Science III
http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)