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

The working group did not spend any time on organizational questions. However, we identified two areas in which people would be needed almost immediately, and noted the possible relevance of the current work on Dorado Lisp. In addition, a 3-person coordinating committee for the EPE project has been appointed by CSL management (Bob Taylor). This committee (Deutsch, Horning, Lampson) has met briefly and produced some organizational ideas described below.

If a Mesa base is chosen, we will need someone to function as a continuing liaison with SDD. This person will need to be familiar with the language and system work being done in both places, to bring both potential divergences and opportunities for sharing code to the attention of the appropriate people doing the work. We believe that our goals and SDD’s are similar enough, at least at the language level, that such a liaison could be very helpful.

As mentioned in the earlier section on Effort, we believe it is worthwhile to make a short-term investment in improving certain gross aspects of the current Mesa environment, if a Mesa base is chosen. We view this as an initial phase of the EPE (even though much of the code is likely to be superseded later) and hence it should be coordinated with the rest of the project.

The current project to produce an Interlisp system for the Dorado is independent of EPE. However, if a Lisp base is chosen, the starting system will be Dorado Interlisp. In this case it will be to our advantage for people with EPE interests to become involved in the Dorado Lisp project sooner rather than later. We also expect that in this case the current CSL Lisp community will be the initial core of the EPE design and implementation effort.

We (the coordinating committee) believe the project should be organized into three areas: language/system, tools, and packages. Naturally these areas overlap; one of our functions is to facilitate communication among them.

In the language/system area, we believe the work will demand a fairly small, closely knit group of 3-4 people to work on the compiler and run-time system. At least one person from the coordinating committee should be a member of this group.

In the tools area, we believe that more autonomy of individual projects is possible, although certain decisions with system-wide consequences (such as display management, low-level hooks for programmer assistance, and data base interfaces) must be made at a global level.

In the packages area, we would like benevolent anarchy to prevail, subject to some planning for things we know will be widely used throughout the system (e.g. network communications) or require special expertise (e.g. high-quality mathematical routines). Our idea is to set up a standards committee, which would develop and publish a set of criteria that would be applied to all packages submitted for inclusion in the official library. Packages would be read by the committee for agreement with these standards, and by one other person (not the implementor) for appropriateness of design and implementation. Since this procedure would introduce a certain amount of inertia into the system, we envision the existence of an unofficial library, with the understanding that a package is only allowed to exist in this library for a limited amount of time (say six months), and that anyone who uses the package during that time may have to rewrite some code if the package’s interfaces change as a result of the approval process.