The Keykos kernel is devoted to providing a platform to support highly modular programs. Indeed it helps modularity to the extent that it also provides security. One result is that the kernel is itself highly immodular. There is a general pattern for removing things from the kernel but the tradeoff between performance and modularity causes a good deal of code to remain in the kernel. The Keykos kernel is currently about 100KB of machine code which is not terribly big for a modular program but cumbersome for an immodular one.
By immodular I mean that performance improvements and bug fixes are typically of the form of a small change to some structure format and then mods to each of several files. I have often seen a mod consist of one instruction in each of four or five files.
IBM’s CMS software development environment provided storage of source files in the conventional forward difference scheme. A change had a name and it was possible to remove a change even if it were not the most recent change. I think that no system can ensure that all combinations of changes will work or even compile. If the two changes do not collide, or nearly collide, in each of the files that they impact, then there is a good chance that they will be orthogonal and can be selected independently. Even when we supported just one machine in assembler, the kernel would undergo tentative changes that had to be integrated with production systems to evaluate their performance and stability. Most mods were successful but it was a great benefit that we could occasionally back out a mod which was several released mods back.
Orthogonal mods are also a great aid in parallel development of software. I worked on a Fortran compiler involving three small development groups that were adding new function. One group fixed exigent bugs and high priority improvements while the other two worked on larger improvements that required many months. We frequently needed to test long term improvements with the most recent version of the compiler, yet such code would be useless until the improvements were done.
It seems clear to me that it is possible to develop an “editor” that provides read-write access to some variation of a source. In such a compiler “if (WROG) amp(13,sam) else amd(sam)” appears as “amp(13,sam)” when the editor is invoked in an environment in which WROG is true. Furthermore changing “13” to “14” would change the underlying source to “if (WROG) amp(14,sam) else amd(sam)”. It is even possible to write an editor that guarantees that the meaning of the program will not change except when WROG is true. This may collide with current use of preprocessors, however.
Sometimes it is necessary to see the underlying conditionality. The environment should also be able to be silent on WROG in which case the full text would show. Colored text can be used in several ways here.
This environment that carries values for variables such as WROG should also control selection of relocatables (.o files). This is often a desirable form of control of variation.