Lambda the Ultimate

but only because I think you're praising AOP with faint damns.

I think the most fundamental mistake is to confuse AOP (especially as embodied in AspectJ) and Dijkstra's separation of concerns, and Parnas' information hiding, which seems to be commonly done, especially in AOP propaganda. As both Dijkstra and Parnas have emphasized in their writings, separation of concerns and information hiding are fundamentally design-time concepts. Only crude approximations can (currently) be done in any programming languages using safe, organized way of programming.

Another issue is one of anti-modularity of many AOP features; because advice depends on implementation details of a particular routine (method, etc), those implementations details are effectively leaked (breaks information hiding) and de facto become part of the routine's interface (otherwise a change would break the aspect). But worst probably is that to understand what any particular routine does (at least in AspectJ), you have to understand all the advice that is applied to that routine, in other words, local reasoning does not help understanding. Granted, without aspects, the same routine would be huge and as difficult to understand, but at least the reasoning would be local!

This is not to say that AOP is value-less, by any means. AspectJ is as good and as bad as many breakthrough languages, with features that are both useful and astoundingly dangerous. LISP did have setq and dynamic scoping, goto was ubiquitous, etc. Just as I personally consider ML and Haskell to be ``tamed'' versions of Scheme, we are still several years away from having a similar understanding of aspects (though the research has clearly started, as witnessed by AspectML, and the myriad other systems). In my not-at-all-humble opinion, the current systems take the basic ideas of advice and pointcut much too literally, and seem to have forgotten the wise words of Dijkstra and Parnas. But that's a common symptom in computer science -- any paper more than 5 years old can't possibly say something useful, can it?

The first mention of AOP features, i.e. the notion of advice, is Warren Teitelman's PhD thesis from 1966 - see ftp://publications.ai.mit.edu/ai-publications/pdf/AITR-221.pdf This itself seems to have been influenced by John McCarthy's advice taker, but I am not sure whether that's actually true. Warren Teitelman's notion of advice became part of Xerox PARC's Interlisp, apparently found its way to MacLisp, then Flavors, LOOPS and finally CLOS. Gregor Kiczales was involved in the CLOS specification, so that's where he probably got this ingredient of AOP from. MacLisp was also a precursor of emacs lisp.

Dylan was mostly derived from CLOS but left out a number of features that were apparently deemed too complex and/or confusing, among them the CLOS notion of method combinations, that is, before/after/around advice. That's probably an early example of a rejection of (some elements of) AOP.

except that those higher-order wrappers need to be able to be created after the wrapping function, and applied independently without altering the call sites. That's the crux of it, and what makes AOP so easy to abuse.

It would no longer be possible to reason about the behaviour of a piece of code by looking at it. Some aspect somewhere else might silently be messing with it.

I can imagine an IDE colorizing or something to warn me an aspect is applying - and I could imagine trying to edit the same code in vi, and being unable to trace a bug in what looks like a bug-free function.

I prefer the principle that code should be explicit. If you want to add hooks for pre-and-post invocation code, you can do that, and a sufficiently powerful language will let you do it cleanly.

Hi Erik,

look at this code:

fac 0 = 1
fac n = n * (fac n)

It is "evil" because it will generate an infinite recursion - the programmer made a bug. Would your advice to the programmer be to

a) replace the "n" in the recursive call by "n-1", or
b) propose "stratefied functions", where each function can only call functions on a higher layer, thereby making it impossible to write looping programs (and functions like fac, too)?

I discussed this "problem" with one of the authors when he presented this work at the FOAL workshop. I don't believe that the infinite recursion he talks about is any more or less a problem than infinite recursion due to recursive function or method calls. In fact, recursion is one of the most elegant and powerful concepts we have in computer science.

Apart from these "philosophical" considerations, the proposed stratification does not really solve the problem because an aspect may still indirectly advise himself by calling a function that triggers the aspect. Hence a simple refactoring of advice code into an external method is sufficient to break the model. This is how I remember it, at least. Let me know if this has changed.

Well, choosing (a), you can still get an infinite recursion:

fac 0 = 1
fac n = n * (fac (n-1))

since fac(-1) would count to negative infinity. :-)

Hi, Klaus.

I do agree with you that there might somewhere out there be an aspect or two where stratification costs you flexibility. However, up till now I still have not seen a single one. But that only as a side remark.

Regarding your functional example: This really does not compare. First of all, the infinite recursion *we* tackle is the one caused by an advice advising itself. This is always a mistake because such a recursion cannot be broken in a meaningful way. The problem here is that advice invocation is implicit. For the programmer it's hard to see right away if he made a mistake in the pointcut specification or now. Moreover without stratification he has to remember considering this issue *every time* he writes a pointcut.

In you example, (fac n) is invoked explicitly. We do not break such recursion. The problem here is mainly that the question arises of how you would break it in a meaningful way. (Maybe the compiler should still give an error message though, at least in a non-lazily evaluating language.)

Aspects are completely diffrent. They are invoked through inversion of control. An advice is never invoked explicitly. That makes sensible recursion on advice invocation impossible. Hence we proposed the solution to stratify aspects. Please note that we do *not* stratify usual function calls. So you can still use whatever recursion you want. You can just not get any more recursion through advice application. I know there are AspectJ advocates who claim that such recursion could be meaningful but by today I have not ever seen a single meaningful example. Feel free to proof me wrong.

Eric

I did not assume you were stratifying functions; this was just an analogy to show that the "closure property" of a uniform, non-stratified mechanism is a wonderful feature and not a bug :-)

Whether this example makes sense or not is arguable, but since I brought up this example consider the problem of "outsourcing" the body of fac into an advice. So, we would have a "fac" method/function with an empty body (or: returning 0). The advice is triggered by any invocation of fac. If the parameter is >1, then the advice calls "fac" - a call which must of course trigger the advice in order to get the desired semantics.

This is contrived, of course, but I guess one can find more useful examples in the context of recursive funtions or loops. Like for example a naive exponential-time implementation of the fibonacci function, which is turned into a linear-time "dynamic programming" variant by a caching aspect.

By the way, why is a projection of advice on join point shadows as visualized by AJDT not sufficient? It clearly shows me when I have advice that may trigger itself, and I can then decide whether this was a bug or intended. Why make the programming model more complicated then necessary?

The problems with merely allowing a programmer to check for bugs via the design tool vs. allowing them to state constraints on their program which are automatically checked is that a change elsewhere in the program may introduce an unexpected problem. This is particularly relevant on large development teams. After all, why make the programmers' tasks more complicated than necessary?

Stratification amounts to enforcing that the (implicit) call graph is a directed acyclic graph, true, but you can easily introduce explicit calls for the cases where you actually need cycles. This can be generalized in the following ways:

• Allow advice to be explicitly defined as recursive, so it can implicitly call other advice at the same level, as well as at higher levels--corresponds to "letrec" as opposed to "let."
• Implicit calls to higher levels (or same level, with letrec)--standard advice-taking
• Explicit calls to the same level--standard function calls, and
• Super-explicit calls to lower levels--down calls.

As Eric mentioned, the control flow graph can be used to determine whether a method is to be at one of the advice levels or the base level of the program. The reason I think down calls should be differentiated from explicit calls at the same level is that they are the most likely case to introduce errors due to separate development. One common use for down calls would be advice which rewrites an expression to a different expression which evaluates in the same context. In fact, such advice which operates without any I/O or runtime value dependence is essentially a macro, which can be simplified away at compile time.

Final note, I'm actually working on a language which uses this stratified calling convention (as a more sophisticated replacement for dynamic scoping), so you might see more about this if I ever get my act together.

This is only partially correct. In general: Yes, there may be circumstances where the advice might still be triggered recursively. We thought about handling this via cflow in the future. Having said that, when you simply factor out advice code into a method, this method is still on the same layer as the advice and would hence not be matched. No recursion is possible this way.

But how do you know which method is executed? Let's say the advice calls "Object.toString()" on some object known as "Object" only. Do you then consider all "toString()" implementations in your whole system? In general I believe you would need a global, approximating/conservative analysis of your program. Usually it is not a good thing if the static semantics (correctness) of your program depends on global properties...

We do not know which method is executed. As mentioned above, we would had to use cflow to capture all of those cases, which is probably a good idea, especially given that some compilers now provide cflow with zero runtime overhead.

The property you mention has nothing to do with whether you factor our your advice code into a method or not. Without using cflow, when your advice calls a method on a lower level that is woven into, then the advice can match on the execution of this method and trigger itself. But this is independent of whether this call takes place directly or indirectly through a separate method.

As Eric said, factorial is a good example for recursive functions, but I am afraid it is not for aspects. Let me explain.

By definition advice encapsulates behavior which is crosscutting for several functions. This encapsulation is done by using new first class entities (advices) which are 'external' from the functions' point of view. Contrary to this a recursive function is 'closed' in itself. So the problem we address is the one where the 'external' entity and the function which it advises are the same, i.e. the advice advises itself. When we had our discussion after my FOAL talk I challenged you and Gregor to give me an example where an advice must advise itself in order to work. Unfortunately until now no such example was given. But to convince me that our proposal limits the expressiveness of AspectJ, I would like to see such an example.

For this, you first have to find an advice which advises itself in an meaningful way, and more so, whose advising itself is necessary to provide its functionality. Second the functionality provided by the advice has to be crosscutting, as this is the very nature of functionality encapsulated in an advice. Last but not least, there would have to be a meaningful, if not natural, termination criterion for the recursion.

'Hence a simple refactoring of advice code into an external method is sufficient to break the model. This is how I remember it, at least. Let me know if this has changed.'

This depends on the kind of refactoring or what you consider to be an external method. If you refactor the advice so that the extracted method resides in the same aspect, and therefore at the same type level, no recursion is possible in our approach. However, if you refactor the advice so that the extracted method resides in a class and the advice is capable of advising the new method in any way, infinite recursion can occur. We address this problem in our more recent paper "Avoiding Infinite Recursion with Stratified Aspects":

"We cannot avoid all recursion with our approach. In particular, we cannot avoid recursion resulting from an aspect accessing elements of lower levels (including classes), because for us, these accesses are indistinguishable from accesses by program elements on the same level, which are to be advised. However, our compiler could produce a warning wherever an aspect crosses levels by accessing elements from a lower level and this may result in recursion. In fact, the cflow analysis built into abc could be used to statically compute those warnings."

Welcome to Lambda, Prof. Leavens!

While I am guilty of not having read the papers under discussion, it seems to me that viewing language design goals as "concerns" in this sense is really the only available option. While people may use an "all or nothing" rhetoric, language design requires by necessity decisions that try to optimize several (indeed, quite a few) goals.

We should keep in mind that even if the scale is continuous optimization may still be difficult to achieve, that the scale is in several important cases subjective, and that it often makes sense to decide to sacrifice some goals to a certain extent in order to better serve another set of goals. The latter is a useful technique, it seems to me, for keeping the language design coherent, a meta-goal in a sense. Examples of this design philosophy are pure FP languages, pure OO languages etc. One way of thinking about these approaches is to see them as deciding that one goal is an all-or-nothing concern - at least in the sense that it is non-negotiable. This reduces the dimensionality of the design space, yet still leaves a multi-dimensional continuous optimization problem, of course.