[_CD8_]<cedardocs>eperevisited.memo!3

The "First report from the Programming Environment Working Group," dated July 21, 1978
(hereafter, "EPE Report"), contained a list of desirable features for an "experimental programming environment," and discussed both their priority and their expected difficulty. Since this was the springboard from which the Cedar Project was launched, it is appropriate to review that list of features, and compare it with our current consensus.

The following discussion concerns the items that the EPE Report identifies as Priority A or B
(on an A, B, C, D scale). Much of the effort of Cedar has been devoted to issues that were not on that list, because recognition of their importance has grown as the project evolved. Thus omission here is not an indication of lack of importance.

The assessments given below are my own, tempered by comments from the Cedar Coordinators group, and especially Mark Brown.

First, a summary of the priority rankings given in the EPE Report. (For a more complete discussion of the meanings that were then associated with the various headings, see the EPE Report.)

403 FObject management—garbage collection/reference counting
300 FStatically checked type system
270 IMemory management—object/page swapping
250 FAbstraction mechanisms; explicit notion of interface
202 IFast turnaround for minor program changes (< 5 sec)
180 FAdequate runtime efficiency
180 FLarge virtual address space (> 24 bits)

170 FEncapsulation/protection mechanisms (scopes, classes, import/export rules)
153 FWell-integrated access to large, robust data bases
152 ISelf-typing data (a la Lisp and Smalltalk), run-time type system
150 AConsistent compilation
152 IVersion control
150 FSource language debugger
152 AText objects and images
152 IUniform screen management
150 AUser access to machine’s capability for packed data
141 FRun-time availability of all information derivable from source program
(e.g., names, types, scopes)
132 FCSL control over the system’s future

The difficulty codes were supposed to mean
0-available
1-easy
2-straightforward, but takes time
3-hard
4-impossible

The "fundamentality" codes were supposed to mean
F-Fundamental, much harder if not allowed for originally
I-Intermediate, somewhat harder if not allowed for
A-Add-on, difficulty does not depend significantly on pre-planning
(although it may be intrinsically hard anyway)

This has been a high priority item from the start, and has interacted with many other aspects of the Cedar system. Nevertheless, it still looks like a big win; the effort has been well-spent. Garbage collection was the forcing function for designing the Safe language, which we believe will also have high utility on other grounds.

Although Cedar was not supposed to be "a language project," the Language Features Design Committee and the implementation team made major investments in improving the language in response to all sorts of requests, including many areas not given priority in the EPE report. (The results of some of this work also showed up in Mesa 6.0.)

This came with Pilot, which is hardly the same as "free" or "easy." Nevertheless, the cost has been acceptable, considering the expected benefit.

Mesa started with explicit, language-enforced interfaces. We expended a fair bit of design effort on ways to improve its abstraction mechanisms, but wound up making relatively modest changes, with low implementation effort. (Interface records have yet to appear.)

This still looks straightforward but time-consuming. It still looks like this goal can be met, for a suitable definition of "minor program changes," on Dorados, at least. Until very recently, considerably more effort went into many lower-priority items. (This may reflect the EPE view that it would not be much harder to retrofit this ability than to build it in initially.)

One realization that has come out of recent discussions is that there are two distinct subgoals: retention of program state across recompilations, and fast switching among the editor, the compiler, and the client program. Although more attention has been focussed on fast switching, retention of program state may have a higher payoff.

We started with a Mesa system that was adequate, and have been able to retain that property with modest investments in tuning critical components. (Note, however, that garbage collection could have been easier had there been no efficiency constraint.)

Again, Mesa started with what the EPE Report considered vital, and we have invested little additional effort. Implementation of the design for multiple superclasses has been deferred.

This problem turned out to be at least as hard as it looked. The database group carved off a reasonable initial chunk that should provide a good return on the investment. This has been, in some sense, an "A" approach, at least partly because "F" facilities needed for a more tightly integrated system (e.g., compiler factorization and pickled type, procedure, and data values) were missing or deferred.

Juniper’s availability, functionality, and performance problems have delayed the development of important integrated databases. There remain important research issues in application-specific (high-level) logging and recovery. More straightforward implementation issues are involved in introducing protection that is not tied to files. Enforcement of the checked subset of the language will be critical to guarantees of integrity in the face of database modifications by
application programs.

This was truly straightforward and worthwhile. REF ANY and the RunTimeTypes interface provide functionality comparable to more dynamically bound systems, and their implementation has not been unduly costly. We don’t yet have much experience with their use.

This should have been classified as "hard." What we have to date are a number of successively more useful hacks; the problems of history and parameterization, as sketched in the EPE Report, are still under attack by Schmidt and Lampson. Anecdotal evidence of problems in the construction of Cedar suggests that this larger-than-anticipated investment will be worthwhile.

It’s not clear why this was given an "available" rating. Modifications already made to the existing Mesa debugger for IME and Cascade would rate at least a 2, and we are presently building a complete new set of debugging facilities. Those who are heavy users of the existing Mesa debugger are among the strongest advocates of this investment.

This has largely been subsumed under the design of the DOC interface. Given that design and Cedar Graphics, implementation of representative text DOC classes was a modest additional investment.

The DOC design was seen as an opportunity to clean up and unify several things, as was the design of InStreams/Creeks, etc. These 3’s were not mentioned in the EPE Report, but seem to be paying off.

Again, this was partly subsumed under DOC design, but mostly relates to Cedar Graphics, which has gone well beyond the minimal requirement of virtualizing the screen—at a correspondingly higher implementation cost, which seems to be justified by ISL’s needs.

Access to the type system has been provided by the RunTimeTypes interface. Access to the rest of the compiler-derived information is proving to be a somewhat harder problem than originally anticipated, although no insuperable barriers have been discovered.

At various points, we have avoided the need for substantial investments at the cost of linking our progress to that of SDD. By and large, this has worked out well; we have gotten further than we could have gone on our own (and managed to influence SDD in directions we expect to be productive), but our own direction and timing have been somewhat influenced by this linkage. We have acquired CSL expertise in the various SDD-supplied components on an "as needed" basis. At some point, we will probably reach an unbridgable divide, and decide that the freedom justifies the cost.