Aninteresting dissertation suggests that in the future, quite a lot of applications might be able to be defined in terms of a generic editing framework like this one.
The Proxima prototype is written in Haskell and uses wxHaskell for the GUI. It integrates a slideshow editor, a chess board, an equation editor, and a Haskell source editor in a single multi-function editor as proofs of concept for its flexibility.
The really interesting bit, for me, is that it’s a lot like the GUI constraint maintenance stuff I’ve been blathering on about here, in that it has to deal with different versions of a fact and the possibility that changes to one fact type may not be immediately translatable into a change to another fact type.
Of course, they don’t speak of it in such terms. They talk about “levels”, which are alternate forms of a document, corresponding roughly to its textual or graphical form, its AST, its semantics-annotated AST, and so on. Each level may have changes which cannot yet be incorporated into a different level, e.g. because you’re still typing and you haven’t written something that’s syntactically valid yet. The system uses various declarative mini-languages to represent the transformations between levels, so that creating a new editor mostly requires just specifying sort of style sheets in each of the relevant transformation languages.
I haven’t investigated this in depth yet, mainly because it’s all very Haskell-based, including the transformation languages, so I’m going to have to learn at least a bit of Haskell in order to really understand what they’re doing. Anyway, it’s already given me a lot to think about, such as the question of how to represent the notion of a “selection” in a GUI, in a way that’s useful for the sort of generic function-based GUI framework that I’ve been blathering about on the PEAK mailing list.
It sounds as though their prototype isn’t very useful for large documents, currently. Apparently the current implementation uses a non-incremental attribute grammar, which means that even minor changes can trigger large scale recomputation of internal structures. This, of course, is what I want to avoid in the stuff I’m trying to design. More specifically, I’m curious about what you might call “automated differentiation” of declarative code, translating declarative concepts like constraints or transformations into event-driven code that makes changes to derived data when base data is changed
Proxima has some features like that, but with the interesting additional constraint that it has to support bidirectionality. That is, there isn’t really a fixed “base” and “derived”; whichever data you change is the “base”, and the rest of the data is “derived”! This is something I’d like to try and support in the fact-base system to some extent, wherever there is a one-to-one correspondence between fact types, even when there is “extra state”. (“Extra state” is Proxima’s term for information in one representation that is not used by another, like comments in the text that don’t appear in the AST, or type information in the AST that doesn’t get displayed).
