Lambda the Ultimate

BTW, is anyone else disturbed at the amount of attention AOP is getting lately? Is there a need for AOP or is there just a need for something new to talk about in the industry press?

What concerns me is that maybe there's a simpler program waiting to get out rather than a need to slice up the complexity itself into "aspects".

Bringing this back to dynamic scoping, I'm not sure even if the classic case is a sufficient argument for that, i.e. Emacs. But it is good to have the insight into how to provide it when desired.

I guess the same is true for AOP. I think it will just be more complexity through being overused.

I guess it depends upon what you think AOP is. Ever since it's become easy to programatically read and rewrite Java bytecode (i.e. through BCEL), I've been using it to perform AOPish tasks.

Ways I've used BCEL:

- To add C++ peer lifetime management to Java peers for Jace.

- To add monitoring to application objects (i.e. track who created or last modified an object, and when they did it).

- To add "custom attributes" to application objects.

- To add resource management tracking to any object (i.e. did the user remember to call close()/dispose() on this object?)

Another example of AOP at work is JDO (transparent persistence) - I now use this on a daily basis.

Basically, I've come to think of AOP as a way of describing the capability of transparently providing a "service" or "capability" for an object. I use the term "transparent" here to mean that the user doesn't have to directly implement any interfaces or otherwise change the definition of their object to support the service (though an object may explicitly cooperate with a service).

There are actual aspecting systems out there (AspectJ,AspectWerkz,JavaAssist) that make this easier than working directly with bytecode, but I haven't had good luck with them yet. For example, AspectJ requires you to have the original source code (which I often don't have) and to use their own compiler (which may not be up to date with the latest language changes). AspectWerkz seems to have a problem where it's preventing objects from getting garbage collected.

Personally, I don't find it difficult to work with the bytecode. In fact, I find it easier to describe an aspect in a single class using BCEL, than to describe it with three different introductions classes, an advice class, and some xml to tie it all together.

Yes, it's nearly as disturbing as all the attention devoted to OOP and `dynamic typing'. :)

No doubt we'll soon have a wave of trade magazines, self-appointed pundits, conferences, programming languages and bumper stickers for AOP. Then after ten or fifteen years of bumbling they'll realize AOP can be boiled down to a set of standard, extant ideas like monad transformers (see Prehofer). By then, though, AOP languages will have accumulated a ton of obscure and unnecessary cruft, and we'll be calling these things `pointcuts' and `aspects' instead of by their original names, so that the AOP zealots don't have to feel bad about using twenty-five-year-old technology.

It doesn't bother me much. I'm used to this situation already. :)

Not to mention `static typing'. :) :)

I really enjoyed the style of this paper - using Lisp without apology, and giving you "the meat" as a page of code that you can actually run. Very refreshing!

And although it's not sanctioned by the AOP powers that be, it is the most tangible AOP-related work I've seen, and it actually whet my appetite enough to read more of the "official" stuff.

But I still think that if you have a lot of cross-cutting concerns then you're using the wrong paradigm. As an Erlang hacker I hate reading that "concurrency is a cross-cutting concern". It's like assuming everyone programs with GOTOs and saying that "control-flow is a cross-cutting concern". Use subroutines! Use isolated processes! Why bolt stuff on the side!

CMU Common Lisp can indicate positions in source code with "source paths". A source path is a list like (1 2 3), meaning "over one sexp, then in, then over two sexps, then in, then over three sexps, and you're in the right place". They use this internally to dig out a particular sub-form in some code that has been read into a list.

What we want to do is slightly different: go from a source-path to the corresponding character position in a source file. But the trick is this: what is a "sexp", lexically speaking, when you have reader-macros? It's "something the READ function returns". So we can't just count parenthesis.

One solution is call READ on a file, which will merrily recurse away, and somehow have it `break' when it reaches the point in the call tree that corresponds to the source-path. Then the number of bytes of input will tell me the character position of the form I want. But how do I make it break? I don't really want to hack their READ function, and the only other way that comes to mind is `advising' READ during the dynamic extent of my source-path lookup...

This transparent enhancement is different in my mind from AOP. AOP is in the hands of the end programmer, whereas enhancing the generated code is in the hands of the system programmer.

If the AOP mechanisms were used by systems programmers to provide transparent features, that's one thing. My fear is that end programmers begin slicing up their code for the sake of doing AOP itself.

Exactly. Slicing up complexity is not the same as simplifying the notation and implementation to begin with.

No doubt we'll soon have a wave of trade magazines, self-appointed pundits, conferences, programming languages and bumper stickers for AOP.

This is my fear. And indeed it is happening as we speak, literally, at OOPSLA.

But this is systems programming with the tools at hand. Sometimes you just do these things.

When you run into a similar problem, a second time, you begin to see how a better mechanism could solve the general case. As a systems programmer, you get to design new language mechanisms.

I would be afraid if this were being popularized for end programmers. A one off systems hack is not as concerning.

I'm not sure that I see the difference. AOP systems can work on generated code or as part of the language itself (i.e AspectWerkz vs. AspectJ). In any case, I agree that the bytecode enhancement (whether or not you call it aspecting), should be in the hands of a very small number of team members. I believe that, even for a large project (say several hundreds of classes) there should be relatively few aspects. Those aspects should be designed by a senior developer and documented very well.

> As a systems programmer, you get to design new language mechanisms.

I'm not sure what you mean by this, but I do see aspecting as very similar to writing language extensions. In fact, I'm growing fond of the idea of a standardized mechanism for plugging in AST transformers into compilers so that you can affect language semantics that way. You wouldn't be able to change the syntax of the language (which is probably a good thing), but you'd be able to change the behavior of the program. That behavior could be directed by metadata attributes supplied by users (i.e. MetaData JSR 175). While very similar in capabilities to the bytecode enhancing that is done now, you could probably do more flexible things with the ability to introduce new type information into the process during the compilation phase.

This is also a really great illustration of the usefulness of variables with dynamic scope and extent. When the dflet is exited by any unwinding of the stack, whether by function return or catch-throw or a condition being raised, the function is implicitly re-bound to it's previous state (this is the one big addition that I haven't seen in vendor-specific advice facilities). This paper is what really made me see the usefulness of dynamic binding.

Now, to get back on topic. Right now (my views may very well change if I ever need to dig deeper), I see function advice/method combination (call it whatever you will) as the most useful aspect of aspect oriented programming (and one I actually use on a very frequent basis in CLOS). After this paper (and a bit of mucking around trying to implement conditions/exceptions using continuations in Scheme), I see the real power of variables with dynamic scope and extent. It's a pleasant surprise to see that one can be so cleanly implemented using the other.

Solved! Another hacker came up with the better approach of creating a new readtable that wraps a location-recording function around each function in the normal readtable. A higher-order readtable, if you will. :-)