In August 1982 we observed great inconvenience in the simple cycle of changing source code and testing that code. We call this activity the development cycle. We will gather ideas here for a solution of this problem. We use "user" here to refer to the application developer.

My ideas are predicated on the idea that all but trivial objects are constructed by user supplied programs. Where an OS programmer would write a half page of JCL we anticipate a half page of PL/I.

The Binder Project

In September I began to write some programs to drive the binder. I record the techniques here primarily as an example of the kind of development effort that has influenced me.

I had to copy the PL/I program libraries from another computer. AUXFILE did this for me.

I wrote a program to read each of the members of this library and caused the binder to ingest them. I wrote a program to concatenate the block-lists into one and perform other operations on the binder.

Upon finding bugs in the second program I needed to rerun it but not the first program.

The development of the first program necessarily overlapped the development of the second. Other phases are yet to come.

The end product of this effort should support the incorporation of revisions to IBM's library without great pain.

Lets call this "object construction code", or OCC. This OCC would call PL/I code that the user didn't write that in turn calls the binder. We call this other code the "loader". I don't yet know whether the OCC and the Loader should run in the same domain. There are no security reasons to keep the user from calling the binder directly, only the cost of learning how. I do not now anticipate a loader so powerful that there would be no need for anyone but the loader to call the binder. I do think, however that most application developers will not need to learn to call the binder.

We will concentrate first on the sub problem of development of the code that runs in one domain. We assume at least that such code is a collection of assembler and compiler code. I will concentrate on PL/I because I know it better but will try to avoid placing other languages at unnecessary disadvantage.

A sub-sub goal is to be able to write and test a program designed to instruct a domain.

I want to think at a little higher level than above.

Until recently Gnosis design has focused mainly on the production environment. We also need an environment in which to develop and support production programs.

I first define the term "source":

By this I mean that body of information that is the end product of the development cycle. Today the sources are symbolic input to compilers and assemblers and miscellaneous pieces of data such as tables and installation instructions. We may decide to include Application specifications and program logic documentation in the term "source". Sources are delivered to the buyer of an application program or to a QC function or to an archive system.

Augment files are an exciting candidate for application sources.

These activities must be supported and I think that they may divide the job into three nearly distinct parts:
Building, viewing, analyzing and changing the source,

Interpreting the source (compiling, assembling the programs and carrying out any other special instructions),

Monitoring and analyzing the execution of the application.

The nature of "source"
Today and in the near future source will be symbolic files in a language understood by some compiler, assembler or some interpreter such as a command system.

The form of the source must be:

Sufficiently rich to represent the logical structures necessary to describe software,

Understood by editors that support browsing and changing the source in a manner satisfying the ergonomic and intellectual human requirements,

Copyable and archivable (not all things in Gnosis are),

Subject to some sort of version and update control.

Understood by compilers or interpreters.

Source objects must support change notification {(p2,sp)}. This means that if a compiler has read the source and the editor changes that the compiler is notified of the change.

I will pursue the second scheme {(s2)} here for a bit.
I assume that we provide something like the producers described in (p2,sp).

We also need a means of breaking the following recursion:

We write a program X to describe the loading of program Y -- but how do we load program X?

The GC's and smart producers are both open objects in the sense that their state can be archived.
It suffices to make a copy of the data in the segment of the CG. A builder's key to a smart producer can be used to extract the requestor's keys to other smart producer's.

To record the state of the set of smart producers that belong to the source of an application, it suffices to note the .function and .space of each. In most applications the .space of each producer would be the same. The .functions would each be a start key to a GC or perhaps a requestor's key to another Smart producer.

Levels of change
This system deals with changes at two levels. For long periods of time the set of smart producers remains fixed and their .functions and .spaces are also fixed. During such times the only changes are triggered by changes to the segments of the CG's. The world must be redone, perhaps, when new producers are introduced or their relationships change.

Perhaps a conversational program is needed that has the only plumbing tools and is able and willing to tell you all there is to know about who is connected to what. I think that the plumbing tools consist of only the builder's keys to each of the smart producers.

Version control
The fact that the source can be copied may be the foundation of version control. For version control tools are needed to help understand what the differences are. Symbolic compare is the last resort, but effective.

If the copying is virtual the optimizations can occur.

If the application software is highly parameterized we may be faced with a situation where two different instances of the application (with different parameter values) share the sources except for a few "macros" that hold the parameters.

The smart producers are themselves very small and need not be {and cannot be} shared. The .functions that they depend on are in fact typically references to CG's that may be shared.

Recall that when one of these .functions run the have access to components that are local to the application instance and which have already been parameterized correctly.

Debugging
I am not sure whether debugging tools are relevant to this design. I think that this design should treat debugging tools as it does any other part of the application software.

Scheme Two:
If the system is to remove the burden of remembering what parts of a system must be rebuilt as a consequence of a source modification, we must provide a language and an interpreter in which to describe the top levels of application construction.

Perhaps we can run the application build programs in an environment where observe and record what depends on what. In this way we know what must be rerun when something has changed.

Imagine a virtual directory from which application build programs could fetch keys. In fact there is a watcher program between the application build program and the directory. This program learns what depends on what.

As a concrete example imagine an assembler fetching a macro definition from a library. Our demon would know that a change to that macro definition would require reexecution of the assembly.