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

A Lisp-based EPE (here called XLisp) can evolve from our current systems in a series of steps, with a working (although not stable) system after each step. The steps listed below need not be done in exactly the order given, although we believe this order leads to the least total work. We also believe little parallelism is possible between any two of the steps, although, as the assignments of people indicate, a lot of parallelism occurs within a single step.

The names attached to steps other than the first should not be taken too literally -- the named people have not been consulted. We have assumed the worst, namely, that almost no volunteers from outside the current Lisp community will participate in this work.

The total of the figures below is: 87 work months, 27 1/2 elapsed months. This total does not include work on Masterscope, but we assume that this work will be done eventually by Larry Masinter, who is not currently available. At the end of this period, we have a system which includes all the present Lisp facilities plus the critical Mesa-like facilities discussed earlier in the Facilities section.

The memo on which this section is based, which contains a fuller discussion of the sequencing and rationale for the various steps, appears in the appendix to this report.

The first step is to get Alto Lisp running on the Dorado. This work began in early November and is well underway. For more details see a memo by Bobrow, [Ivy]<Bobrow>dlisp-status.memo.

Work months: 18
Elapsed months: 6?

People: Bobrow, Deutsch, Haugeland, Teitelman; Fikes, Goldstein, Kaplan, M. Kay; Laaser, Masinter, Thompson

This step produces no externally visible changes in the system, except that GLOBALVAR declarations are no longer necessary.

Work months: 3
Elapsed months: 1

People: Bobrow (stack fns & interpreter), Deutsch (compiler & loader), Haugeland (microcode)

Change the way macros and special syntactic forms are handled, to eliminate "error-driven interpretation". In particular, eliminate DWIM corrections that require altering or examining the state of the interpreter.

We can arrange things so that after this step the system will still run existing Interlisp programs, but MACRO properties and NLAMBDAs will produce warning messages. On the other hand, packages like the iteration and pattern match statements will fit into the system much more cleanly.

Work months: 6
Elapsed months: 1

People: Bobrow (interpreter), Deutsch (compiler), Teitelman (DWIM/CLisp), any 3 Lisp programmers (scan the system); defer work on Masterscope

Add dictionaries to the system, but not lexically-scoped closures. The hardest part of this step is probably designing the proper interfaces to dictionaries-as-virtual-objects.

After this step we have a system which supports localization of names. Individual packages can be rewritten to take advantage of this at any time. Some lame-duck code must remain in the file package to be able to dump and load individual definitions in a global dictionary so that existing programs will run.

Work months: 15
Elapsed months: 2 (design), 3 (implementation)

People (design): Bobrow, Deutsch, Masinter, Horning/Lampson

People (implementation): Bobrow (stack & interpreter), Deutsch (compiler), Fikes (record package), Kaplan (dictionary objects), Teitelman (file package & miscellaneous); defer work on Masterscope

Implement closures. This includes lexically scoped FUNARGs, and arbitrary closures like Mesa module instances. Careful design is needed here to produce reasonably efficient results.

After this step the system will support instantiable packages and Smalltalk-style object-oriented programming. Old programs are not affected; however, some existing packages should be recast in instantiable form, and there will be a period of confusion and trauma while this happens.

Work months: 9
Elapsed months: 1 (design), 2 (implementation)

People (design): Bobrow, Deutsch, Levin

People (implementation): Bobrow (stack functions), Deutsch (compiler), Haugeland (microcode), Teitelman (BREAK et al)

Implement the type calculus (types as objects, type checking), but entirely on a dynamic basis -- no variant representations, and no compile-time checking.

The result of this step is to make the type system a first-class citizen, rather than an intermittent visitor as in the Decl package. Programmers can start writing type declarations in the knowledge that they will reap the benefits after the next step.

Work months: 9
Elapsed months: 1 1/2 (design), 2 (implementation)

People (design): Bobrow, Deutsch, Horning/Lampson, Morris, Scott?

People (implementation): Bobrow (interpreter), Deutsch (compiler), Kaplan (type objects)

This step gives us a system that has nearly all the functional capability of a "safe" Mesa, although it is considerably less efficient in its representation of some kinds of objects, e.g. bounded integers and set elements. It is not clear what to do about the Binder.

Work months: 12
Elapsed months: 3

People: Deutsch, Levin, Satterthwaite (compiler), Kaplan (PUTD, APPLY*, etc.)

This system should be competitive with Mesa, aside from the questions of LOOPHOLEs, pointer arithmetic, etc., and of course it has a lot of capabilities not in current Mesa.

Work months: 6
Elapsed months: 1 (design), 1 (implementation)

People (design): Deutsch, Satterthwaite

People (implementation): Bobrow (stack functions), Deutsch (compiler), Fikes (record package), Haugeland (microcode)

Work months: 3
Elapsed months: 1

People: Goldstein (prettyprinter), Swinehart (editor), Teitelman (integration)

Implement permanent pointers. Permanent pointers, as part of a programming system, require some research. Integrating them into the system will be an ongoing project.

Work months: 6?
Elapsed months: 2?

People (design): Deutsch, Horning, Sturgis

People (implementation): Sturgis (primitives), Teitelman (file package)