Re: [aosd-discuss] Dynamically scoped functions

[Pascal Costanza <address@hidden>]

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
>     accesses.

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)
         (dflet ...
           (main ...))))

;-)

> 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 
language mechanisms.

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

-- 
Pascal Costanza               University of Bonn
mailto:costanza@web.de        Institute of Computer Science III
http://www.pascalcostanza.de  Römerstr. 164, D-53117 Bonn (Germany)