…is paved with meta-formalisms.
A while back (here and here), I argued that realising so-called
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
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
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
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
(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.)
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
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
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.