There is a continuing struggle to deal with Dijkstra’s “separation of concerns” in an appropriately modular manner. It is an interesting problem in that it is both completely solved (at the design level) and rather open (at the implementation level). Aspect-oriented programming (AOP) has been touted as a solution for this problem. But, in practice, AOP has turned out to provide solutions as well as new problems. If one uses a traditional notion of modularization of modules as based on information hiding, then AOP has deservedly been called anti-modular. Furthermore, while it has at least one quite mature implementation in AspectJ, there are no good semantic formalizations available that would give AOP a satisfying theoretical foundation.

This work firmly attempts to deal with that last problem. The theory brought to bear is not light: 2-categories. More precisely, there is an attempt to mimic the work done on categorical semantics of the lambda calculus. There, it was found that the internal language of a Cartesian closed category was (essentially) the simply typed lambda calculus. It is natural to explore the same question for 2-categories. The novelty claimed here is that this corresponds to some sort of aspect language.

And this is where things start to fall apart: in this rather short (five-page) paper, crucial ideas, and certainly proofs, are omitted. Since there is a much longer version in existence, and the workshop also accepted long papers, one wonders why only a short version was published. Furthermore, while it is convincing that the internal language of a 2-category adds certain features for program transformation, it is quite a large stretch to claim that this corresponds to “aspects.” Lastly, the gulf between practice (aspects on top of object-oriented languages) and this theory (program transformations on top of the lambda calculus) is enormous, and it is not clear how it will be bridged.

I cannot decide whether this is an early paper on the semantics of AOP showing interesting insights, or a vain attempt to use fancy mathematics to explain AOP. There are insights here, but they seem to be about program transformation, not about AOP.