[_CD8_]<cedardocs>PE2>Report>pe2.4a2!1

As discussed under Facilities above, the plan for a Mesa-based EPE has three major stages: Preliminaries, Foundations, and Features. The stages must be done in approximately the indicated order, although some overlap is possible. An important property of the plan is that growth of the system is highly incremental: even within a stage, there are many points at which a stable system with improved function is available.

This section of the report is a condensation of a memo submitted to the working group. For more detail, see the full memo in the appendix to this report, and the earlier discussion under Facilities.

Phase I represents the bulk of the IME effort. When completed, it will have produced an environment in which a text editor, the compiler, the binder, the debugger, and the user’s program(s) are all simultaneously available. The components of the Phase I system are listed below with estimates of the effort required to produce them.

Extend the microcode to handle long pointers and page faulting. Approximate effort: 1 work-month. (Note that this work will be done regardless of IME plans.)

Change the Alto/Mesa runtime environment to handle page faults and support (code) segment allocation in the 24-bit address space. Nearly all of this work has already been done for the Extended Memory Alto version of Alto/Mesa. Approximate effort: 1 work-months.

Provide rudimentary protection through separate MDSs for major entities. Approximate effort: 2 work-months.

Acquire a window-oriented display manipulation package, from either the Mesa debugger or the Tools Environment. Approximate effort: 0 work-months (That is, we’ll take what they give us.)

Alternatively, acquire the Chameleon package from AOS; this would supply a data base package and a text editor as well (see below). Approximate effort: 0.5 work-months. (That is, we won’t adopt this package unless it appears stable and we can use it with only minor tweaks.)

One possible source for an adequate text editor (i.e. about as good as the Laurel editor) is an existing editor that runs in the Tools environment. Approximate effort: 1 work-month.

(The effort estimates above are intended to be upper bounds. Butler believes we can "hack together an editor in 2 work-months", so we probably shouldn’t invest more than 1 work-month in some other package.)

Extend the debugger command language to include editing, compilation, binding, etc. Also change the debugger to use the common symbol table cache. Approximate effort: 1.5 work-months.

Phase II will provide two extensions to the Phase I system. These extensions are independent and could be performed in either order.

Make the compiler retain more information about the structure of a compiled module, so that a slightly changed module can often (almost) be slipped into the system as a replacement for the old version without altering the current state. Approximate effort: 2 work-months.

Change the loader to find and alter extant frames affected by loading a new version of a module. Approximate effort: 1 work-month.

Implement the DeSoto dependency analyzer, which ensures that all modules that must be recompiled will actually be recompiled. Approximate effort: 1 work-month.

As discussed under Facilities above, there are five major basic language/system facilities which need to be added to existing Mesa. These facilities comprise the Foundations stage of the Mesa-based EPE work.

Approximate total effort for Foundations stage: 20 work-months, including 4 work-months for cleanup of the current Mesa compiler. These estimates result from consultation with Ed Satterthwaite for compiler-related things, and with Peter Deutsch for things copied from Alto/Dorado Lisp.

Implement programmer-controlled parsing at input time, using the existing Lisp read-table design. Approximate effort: 3 work-months.

Implement programmer-controlled extension at compile time, using macro expansion, based on Mesa in-line procedures. Approximate effort: 1 work-month.

for each compilation unit, and use this to implement Lisp-style dynamic variable binding. Approximate effort: 1 work-month.

Prevent uninitialized pointers and array descriptors. Do bounds checking on arrays. Exclude dangerous constructs (e.g. LOOPHOLE) from the language. Replace @ on local variables by var parameters. Replace explicit freeing by deferred freeing or automatic deallocation. Make relative pointers safe. Approximate effort: 2 work-months.

Implement the Deutsch-Bobrow scheme for incremental garbage collection. This requires knowledge of the location and type of every pointer to an automatically deallocated type. Approximate effort: 3 work-months, including necessary compiler changes.

This section attempts to estimate the cost of the "programmer’s assistant" facilities of a Mesa-based EPE. Here we consider the activities required to provide a more or less direct replacement for existing Interlisp functions. As discussed in the Facilities section above, we do not believe that this is the best approach to providing these facilities in the EPE.

We assume that the work described under Preliminaries and Fundamentals has been completed. The text editor and debugger described in those sections, perhaps augmented by Mesa Tools, would certainly provide an adequate interface. The time estimates are presented in the same spirit of optimism that pervades the rest of this document.

Extend the compiler to handle single non-declarative statements in specified contexts. An evaluator within the debugger would generate the appropriate linkages to get the statements executed. Save sufficient information to provide the History List features (below). Approximate effort: compiler extension: 2-4 work months; evaluator, top-level environment: .5-1.0 work months. If all or part of this work is implicit in providing the "programs as S-expressions" fundamental capability, the estimates can be reduced accordingly.

Extend the Mesa debugger’s current conditional breakpoint code to obtain a break/advise facility at least as good as Interlisp’s. Approximate effort: 1-3 work months.

Implement Undoing, as in Lisp, by retaining S-expression representations of the original statements and their reversing functions. Integrate history facilities with Mesa’s more complex environment structure. Add language syntax for undoable operations. Approximate effort: 2-4 work months to implement the mechanism; development of primitives and system procedures with undoable versions as time goes on.

If the editor chosen for the Preliminaries implements an undo/redo capability, integration with the more general version should be straightforward. Otherwise, these commands would have to be built from scratch, at considerable cost (depending on the editor design). Approximate effort: 1 work month or ? work months.

Incorporate some correction of minor spelling and typographically induced syntax errors into the compiler. No estimate.

Extend the interface used for the other tools to provide user access to a Masterscope-like data base. Put code in the compiler, binder, or an intermediate agent to notice changes and update the data base. Approximate effort: the data base facilities, no estimate; the interface, 2 work months.