dynamic aspects

…is paved with meta-formalisms.

A while back (here and here), I argued that realising so-called fluid AOP will require a more formal approach to real-world languages and tools. This emphasis on formality seemed to be at odds with Gregor Kiczales’ recent advocation of a less formal approach to software. Gregor’s goal seemed reasonable; it was the methodology which perturbed me a little.

Having had several months to digest Gregor’s response to my blog post, I can see now that most of the apparent incompatibility between our claims goes away if we construe them at the appropriate meta-level. In particular if we distinguish the content of a view from the computation of that content, we can see that informality as a (first-order) goal is in no way incompatible with identifying formality as a (second-order) means to that goal. One potential source of confusion, as Matt Hellige noted, is that this second-order formality can itself be viewed in both formal and informal ways. Nothing a programmer can’t handle, though. First a recap.

Fluid AOP

As I touched on in my last post, fluid AOP frees the programmer from having to work with a single canonical view of a program, instead providing a variety of dynamically generated views, allowing her to use the view most suited to the task at hand. Changes made to these views are “put back” to a persistent representation called the primary decomposition. Fluid AOP, at least in any kind of generality, is largely vapourware, a great idea waiting for the enabling technology which renders it feasible.

Viewing the same thing in multiple ways is what we already do, in a language such as Java, when we have a class implement multiple interfaces. But with fluid AOP, these static facts about program organisation are no longer absolute, instead being relativised to particular views. Some organisational characteristics will made salient by a particular view, others will not. Abstractions become ephemeral things, visualised or made explicit when they are needed, remaining latent (Gregor’s word) the rest of the time.

First-order informality

The big challenge facing fluid AOP is making these flexible views effective. Effective means bidirectional, so that the view can mediate changes to the underlying model (“view” and “model” to be understood relatively). Effectiveness is trivial if we work directly with the primary decomposition, but becomes arbitrarily non-trivial as we work with increasingly abstract views. The more information the view abstracts away, the harder it is – all other things being equal – to usefully interpret a change to the view as a change to the model. The kind of “informal” or fuzzy views that Gregor discussed in his OOPSLA talk are simply ones where the view disregards a large amount of information.

We can’t expect any magic resolution to the tension between effectiveness and abstraction, of course, but what we can hope for, as both Gregor and Matt suggested, is more access to the trade-off, so that the situation becomes “parametric”, rather than “binary”, as Gregor put it. We would like the difficulty of achieving bidirectionality to be broadly correlated with the gain in abstraction. If we’re not interested in abstraction or informality, we might be able to obtain automatic or near-automatic effectiveness; if we don’t care about effectiveness, we may be able to make (limited) use of some very abstract or informal views. We might even be able to achieve both, if we’re prepared to settle for a part-manual, part-automated process.

(A quick aside: bidirectional views have been studied since at least the ’80s. The so-called “constant complement” approach to relational views involves defining a “complement” of a view, which determines how view changes are put back to the underlying tables. There can be multiple complements of a given view, each such complement defining a particular put-back policy. More recent developments include Foster, Pierce et al‘s work on the bidirectional language Boomerang, and this paper by Wang and Gibbons on bidirectional transformations between algebraic data types.)

Second-order formality

But how to obtain practical access to the effectiveness vs. informality trade-off? I think we have little choice but to take a more formal (but ultimately simpler) approach to computing. I’m not talking about the formality of the views themselves, but of the mechanism used to compute the views. With a caveat (which I’ll come to), we will need much more of this “second-order” formality if we are to have any hope of making progress on the bidirectionality issue. Backward computation is forward computation made a lot harder, and so to succeed at the former will require a non-ad-hoc solution to the latter. Trying to make the jump to “informal” computing without getting “formal” computing right is like trying to make the jump to lightspeed on a tricycle.

Once again I’m out of time, so I will have to defer the discussion of how our current approach is ad hoc to my next post. But it should at least be clear that my claim that we need more formality, and Gregor’s that we need less, are not really incompatible; we’re simply talking about different meta-levels.

The caveat is just the point made by Matt Hellige that I mentioned in the introduction. The higher-order formality that I suggest should characterise the relationship between model and view will itself ultimately be viewable in various ways, some formal, some informal. Once we have fluid languages, we’ll be able to use them to implement fluid languages, and that’s where the fun begins.