Aspects are very popular in academic circles. Aspect oriented programming, in which aspects such as persistence or error handling are implemented more or less separately from the rest of the program, and weaved in later using an aspect weaver, can already be used in practice, albeit in rather limited form. There is also quite some academic interest in extracting aspects from traditional code, and in helping users recognize aspects in traditional code. Extended programming editors have been implemented that allow users to colour or annotate code, slightly more sophisticated systems can be fed regular expressions to be used for semi-automatic annotations, and still others try to make their programs even smarter. One thing they all have in common, however: they require programmer interaction.
They are therefore not used by ordinary programmers. Ordinary programmers rely on three things to make their life easier: syntax colouring, automatical indentation, and hyperlinks from identifiers to the place where they are defined. What these three have in common, is that they are very good, but not perfect; and that they require no user interaction (except for running a code indexer like ctags from time to time): they are simply and unobtrusively there. Syntax colouring and indentation add immediate visible structure to the code: they help the user understand correct code, and implicitly alert the user when he inputs incorrect code; but they never interrupt him. And just as a cyclist can ride his bike and concentrate on other things in the meantime, an experienced programmer can react to their hints without having to take his mind off the larger problem.
So if we want to bring a tool based on this interesting notion of aspects to the ordinary programmer, it should be in the form of aspect colouring: requiring no effort and giving subtle unobtrusive hints in an immediate way. What it does not need to be, is perfect.
Fortunately, brute-force automatic aspect colouring can be surprisingly easy to implement in a satisfactory way for languages in which all the important identifiers have global scope, because for these languages the actual colouring can be done quite well based on regular expressions. This should include most imperative and functional languages, but not the object oriented languages. Identifiers with global scope will probably be unique: they could be shadowed in local contexts but this is considered bad style. So there will be few or no false positives at all when colouring not-too-badly-written code.
The simple method by which I propose to colour aspects, is to periodically extract the global identifiers from the source files which implement the basic operations related to those aspects; to do this by partial and fuzzy parsing, and let the output of this process be input to the programmable syntax colouring mechanism that good programming editors already have. This parsing can be partial, because we are only interested in global declarations, and should be fuzzy, because we might be working on incomplete or syntactically incorrect source code.
Such a colouring will indicate aspects reliably in imperative and functional source code because it may confidently be assumed that a chunk of code that handles a particular aspect will contain some names of function or procedure calls or constants or other global-scope identifiers pertaining to that aspect. A similar assumption may not be made for object-oriented languages, in which the basic operation is a message send; because methods are by the very nature of object-oriented programming not globally scoped.
It should be mentioned that namespaces and modules may complicate matters in imperative and functional languages. It is however to be expected that the important identifiers, i.e. those that form the interface of the module with the rest of the project, will either be refered to under fully-qualified names outside of the module in which they are defined, or, when they are exported and used by their short name throughout the project, be considered as global by the programmer and therefore not shadowed by local identifiers. In the first case we can colour based on fully-qualified names, and leave the occurrences of the short names uncoloured, which is not too grave a defect, because colouring everything pertaining to persistence in the module devoted to persistence is not very useful anyway.
For some languages brute-force aspect colouring will require more implementation work than for others. For some, existing tools can be reused. Interestingly, C is one of the languages for which all the hard work has already been done. Additionally, the process can be extra efficient for C because of the convenient existence of separate header files, which contain all the interesting identifiers. Header files or collections of header files will contain approximate but usable "signatures" of aspects.
I extended my C editing environment with aspect colouring to be able to assign four selected unobtrusive colours (dark green, dark red, dark cyan and dark magenta) to different aspects. When I am editing source code for an interpreter, for instance, and I want to have everything related to memory management coloured in dark green, and everything related to abstract grammar in dark red, I can type:
vim-green mem*.h vim-red grammar*.hwhich generates aspect colouring files .green and .red in my working directory; and the syntax colouring script for C of my editor vim has been extended to look for such files and include them. So from that moment on, and until I change it, my editor will use this colouring scheme for this project. All this requires minimal user action and almost no intellectual effort: it is as easy as running ctags to index code to set up hyperlinks.
It is actually implemented with ctags. Ctags is a standard tool to index code in many different languages, and it can be used for the easier problem of extracting all the identifiers from code. It also does a reasonable job of ignoring syntactically incorrect passages in its input. So vim-green is not a long program, but a one-liner:
ctags -x --c-kinds=+p-m $@ \
| sed 's/\([^ ]*\).*/syn keyword acGreen \1/' >.green
Ctags extracts all identifiers from the code, including "+p" function declarations (which are ignored in normal use of ctags, when you are only interested in the definitions), but excluding "-m" the names of struct and union members (which are often unimaginative names like "name", "size" and "next" and would generate many false positives during aspect colouring). And sed then generates commands for these identifiers for the syntax colouring mechanism of vim. Vim-red, vim-cyan and vim-magenta are similar.
To finish the overview of the implementation, here is how to add the hooks to the c.vim syntax colouring file:
highlight acGreen ctermfg=DarkGreen guifg=DarkGreen
if filereadable(".green")
source .green
endif
My vim-colour scripts deliberately exclude global variables, which is a matter of taste; I prefer to have a dedicated script vim-globals, which extracts all the variables declared "extern" and nothing else, to be coloured bright red. Vim-globals is meant always to be used as:
vim-globals *.h
Vim-globals is implemented as:
ctags -x --c-kinds=x $@ \
| sed 's/\([^ ]*\).*/syn keyword acGlobals \1/' >.globals
I expected to be able to reuse code from ctags to implement aspect colouring; instead I discovered that for C at least, and probably also for other imperative and functional languages, I could use the mainstream version of ctags as it is. The trivial implementation that ensued, a combination of two ubiquitous unix utilities, should demonstrate that aspect colouring can be easy.
It is also useful. Brute-force aspect colouring does not aim at correctness but at usefulness in real-life situations, as do syntax colouring, automatic indentation and code indexing for hyperlinks. Among other experiments, I have tested it on the linux kernel sources to highlight scheduling and locking; and without understanding the code in detail, I started to discern more structure in the core kernel, at first sight, so to speak. Also, based on my preliminary testing, incorrect colourings are quite rare in code found in the wild.
This mini-paper represents about one day of research, research into a domain in which I am not an expert, and was spurred by a presentation of a colleague who is. I take it on the word of another such colleague, that the idea is original. Maybe it was always disregarded because of its lack of academic sophistication. Nevertheless, aspect colouring could bring the concept of aspects to the general programmer. Simple, unobtrusive but useful extensions to traditional tools should be a starting point for introducing results of academic research. They should also help hackers to "grok" code.
William G. Griswold, Yoshikiyo Kato, Jimmy J. Yuan, "Aspect Browser: Tool Support for Managing Dispersed Aspects", position paper, OOPSLA '99 Workshop on Multi-Dimensional Separation of Concerns in Object-Oriented Systems.
David Coppit, Benjamin Cox, "Software plans for separation of concerns", in David H. Lorenz, Yvonne Coady, "ACP4IS: Aspects, Components, and Patterns for Infrastructure Software", 2004.