Heading:

Second PE report (section 3a)

Page Numbers: No

Second PE report (section 3a)

Global technical issues

Consensus principles

In the course of our discussions, a few principles emerged which were not captured as "features" in the original report, or were so fundamental that we thought they needed to be singled out for special mention. These principles included:

Automatic storage deallocation is an absolute necessity. It produces a qualitative improvement in the ease of programming and the reliability of the results. This need not preclude another class of variables with programmer-managed allocation, but the latter must not be able to destroy the data structures necessary for the former.

Easy use of programs as data underlies many other facilities in the system. Implementing this seems to require having Lisp-style atoms, a run-time type system, and universal pointers (pointers that carry a type with them).

Editing facilities closely coupled with the compiler and the executive interface to the system are essential, both to reduce the turnaround time for minor changes, and to allow easy construction of tools that interact with these facilities.

Capabilities for precisely defining interfaces, and restricting the communication between modules to those interfaces, are essential to reliable and readable programming. This includes, as a special case, the ability to restrict the use of types and names to a local lexical context.

The ability to perform static checking (including, but not necessarily limited to, type checking) over designated program regions is necessary for both security and efficiency reasons.

The present Lisp, Mesa, and Smalltalk programming styles must all be supported in a satisfactory way. The same packages, and tools of equivalent power, must be available in all styles. In particular, the Lisp capabilities for embedded variant languages and for programming entirely without type declarations must be supported.

Both large, multi-person and small, single-person styles must be supported well. Bringing a wider range of experiments within the scope of a single person’s effort is an important EPE goal.

The EPE must support a wide range of binding times, including the Mesa and Smalltalk extremes, in a way that allows changes in binding time without structural changes in the program. Different choices of binding time by the programmer may lead to different turnaround times for apparently minor changes, and to different execution efficiencies, but the functional behavior of programs must not depend on such choices.

Smalltalk

Fairly early in our discussion we decided that either Lisp or Mesa would be preferable to Smalltalk as a candidate for the EPE base system -- sufficiently preferable that we did not need to consider Smalltalk further. This decision was based on the following observations:

The present Smalltalk implementation is written in Alto assembly language and intrinsically cannot support more than 128K of real memory or 64K addressable objects. A major redesign and reimplementation of the lowest level of the system would be required to make it suitable as an EPE base. Neither Lisp nor Mesa has this problem.

There is no evidence that large systems can be written in Smalltalk; the Smalltalk view of the world is enough different from that of either Lisp or Mesa that fundamental problems may be revealed if we try to apply it to our larger projects. Large systems have been successfully written in both Lisp and Mesa.

Significant groups in CSL are familiar with either Lisp or Mesa; there is no CSL user community familiar with the Smalltalk view of the world.

The present direction of Smalltalk evolution is towards smaller machines (NoteTaker), while EPE should take significant advantage of the Dorado’s capabilities.

However, there are a number of ideas in Smalltalk, not present in either Lisp or Mesa, which we believe are important to provide in the EPE:

The notion of class-structured behavior, and the ability of more specialized classes to inherit behavior from more general classes.

The user interface style.

The lack of structural distinction between user- and system-defined objects.

The working group spent essentially no time discussing these questions: it is up to the eventual project participants to make sure they receive proper attention.

(EP)E vs. E(PE)

At the beginning of our discussions, we assumed that the facilities required for E(PE), i.e. work on programming environments per se, were a subset of those required for (EP)E, i.e. construction of experimental systems in general. Consequently, we did not discuss the E(PE) parsing separately. However, it should be noted that the plan for a Lisp-based environment was strongly influenced by a desire to facilitate further work in language and system construction, since in the Lisp programming style, every medium- to large-scale project develops some language and system extensions; such considerations were much weaker in the Mesa-based plan. Several members of the working group with strong interests in programming languages and systems feel that neither proposed plan is likely to lead to a system that supports their interests for at least a couple of years.