I've been reading a little about aspect oriented programming - which is reminiscent of intentional programming as evidenced by the recent company formation by intentional pioneer Simonyi and Aspect pioneer Kiczales.

Other than being a cool concept it also fits very well into the pragmatic vein being almost precisely a technology for making good use of the discursive state of language.

The basic notion is overloading the program flow with 'stacked' pre-method and post-method calls packaged as aspects. The typing comes about by specifying target predicates for the method signatures a particular aspect modifies.

Once that idea has settled in as defined on top of an OO language like Java the extension to a pure aspect language where ALL function calls are basically invoked by predicate comes to mind. Clearly the execution order of very large sets of predicated computations become an issue - especially since aspects explicitly allow sideeffects (a pet example of an aspect is 'design by contract') but the final execution model has other advantages like implicit simple langage for multitasking of operations. It is easy to consider aspect invocation events - certainly if you are used to the Delphi class libraries where implementation by delegate uses a pre- and post-method pattern all the time.

Continuing that thinking you end up with a notion reminiscent of Linda tuple-space, only the tuples are now method signatures where program state has been reified (fancy word for 'stored as data' - with some theoretical sauce added), so that the dynamic state of a particular computation is available inside the tuple space to any available processor. I'm not to sure about the reification part though. Methinks I should hack something like that together. Of course the real beauty of someting like AspectJ is that all the decisions on 'pattern matching', i.e. typing, make sense at compile time, so that dynamic complexity and type inferencing complexity is not multiplied, whereas the fully dynamic model does NOT do this, but clearly it doesn't have to be that bad at all. If desired one could dispense with the ability to compuet predicates dynamically and do the same compile time optimization for each definable pre- and post-state available.

Coming up with a viable language to express such a complicated flow of execution is certainly an admirable achievement, and the formulation given in AspectJ seems very elegant. The equivalence with pure java is a nice selling point. As long as you're in doubt you have a perfect code generator at your disposal and can work in generated code. The original code is a good design medium though - and the developers of AspectJ even took pains to debug enable aspects. That is very close to being the complete list of requirements for good tooling.