Heading:

Second EPE report (section 3c)

Page Numbers: No

Second EPE report (section 3c)

Character of result

We have agreed that very similar results could be obtained starting from either Lisp or Mesa. We also agree that the EPE must accommodate a range of styles including the present Lisp, Mesa, and Smalltalk styles, and our goal is to support these styles without prejudice. However, we expect that a variety of influences will cause both the intermediate and final results to differ depending on the starting point, primarily in terms of the efficiency with which they support early versus late binding. The following two sections set forth what we think the "flavor" of a Lisp- or a Mesa-based EPE would be -- the strengths (and weaknesses) that would result from starting with each of the two possible base languages.

Lisp-based

Aside from the AI effort, a number of other projects in the lab (such as the original wirelister, the Dorado timing analyzer, the PARCHIVE program) have been implemented in Lisp. Perhaps the single most important observation about the use of Lisp is that as users become more experienced, they start building tools within the system to help them. These tools may span many projects, or they may be very specialized; they range from complete languages (KRL) to minor extensions (automatic checking for undefined functions when one leaves the editor). The AI group in particular has made heavy use of this ability to extend the Lisp system: Lisp has been uniquely suited to their approach, which is to solve problems by first building a new language in which to express significant parts of the solution, and then building the solution (simultaneously extending the language). The Humus effort within Mesa offers a contrasting example of an attempt to build an extension on a system that did not support it well: Juniper, for example, probably could have benefited substantially from some extensions of this kind.

It is important that an EPE support the working style which builds tools and even languages as part of the problem-solving effort. Lisp supports this style well in part because it is:

Incremental: Small changes require only a small amount of work (both mental effort and real time). This is true for both ordinary Lisp programs and programs written in embedded languages. (Current implementations, unfortunately, have relatively weak tools for discovering whether one’s changes are consistent.)

Open: The basic facilities of Lisp are open to change at a very low level: one can modify the operation of the entire system from a user program. There is no distinction between system and user code, variables, name spaces, etc. (This is also a weakness, in that it is not uncommon to find that parts of the system make assumptions about each other that casual modifications violate.)

Integrated: The user can slip relatively gracefully from procedures written in an embedded language back to procedures written in Lisp itself, and vice versa. Since the parser and interpreter are packages, code (in a variety of languages) can be stored in data structures and executed when retrieved.

Aware of user activities: Standard packages in Lisp keep track of new objects added to the system by the user on-line, and changed objects, and help the user keep track of his complex environment. Because all transactions with system objects (such as editing, creating new variables, etc.) are handled through an active intermediary and a set of functional interfaces, it is easy to provide all the "hooks" for complex assistants like Masterscope. .

Abstraction-based: The user is completely freed from concern with basic questions like the representation of integers and symbols, and management of storage. (Most Lisp implementations, including the present Interlisp, have a related weakness, in that they provide few mechanisms for attaining better efficiency even when the user knows full generality is not needed.)

Mesa-based

The "Mesa style" tends to place greater emphasis on structure than on unconstrained flexibility. Probably its two most important aspects for an EPE are its emphasis on static checkability and its provision for explicit interfaces. Both are important in speeding up the programming process and in improving the quality of the result; they become even more so if the units that programmers manipulate are large (packages or subsystems), rather than small (statements or functions); the advantages will be small for programs whose "characteristic times" (design, programming, checkout, existence, total execution) are all measured in minutes, large if they are measured in weeks or months. In an environment where programs are undergoing rapid change, however, mandatory checking mechanisms tend to introduce unnecessary overhead by requiring complete internal consistency at every step of the development process.

Static checking: The present Mesa style encourages (and often requires) relatively early binding of many aspects of programs that in Lisp are typically bound during execution. Mesa also incorporates redundant information (e.g., declarations) that can be checked for consistency. These properties make it possible to routinely check statically for program faults that in Lisp would normally only be detected at run time. (A good example is Mesa’s type-checking.) It is generally better to locate faults by static checking, because

Many faults can be identified in a single run of the checker, rather than surfacing one at a time in debugging runs.

There is experimental -- as well as anecdotal -- evidence for the proposition that program faults located statically are diagnosed and removed more quickly than those located dynamically.

Passing the static test ensures that all faults in a given class have been removed; in general, no finite set of test cases gives such assurance with dynamic checking.

"Correctness" is a static property of the program text; it is hard to ensure that a program that relies heavily on dynamic properties actually does what is intended.

A Mesa-based EPE would make provision for binding at a variety of times, but delayed or dynamic bindings would occur at the programmer’s request, rather than by default. Tools would also be available to exploit program redundancy to infer suitable declarations for programs written without them, and otherwise make it easy to convert programs originally written in a delayed-binding style to earlier bindings. (It should be noted that such tools have already been developed, experimentally, in a Lisp-like environment.)

The belief that this style actually speeds programming (measured as problem solutions per unit time) is intimately tied to the observation that most programmers spend more time worrying about the possibility of programming errors -- and coping with their consequences -- than they actually spend writing new code. This style does require more planning before a running program is created -- some would consider this a disadvantage. A definite weakness of this approach is that it will be relatively difficult to add flexibility that was not anticipated in the program design, thus restricting the range of experiments that can be performed easily.

Explicit interfaces: Much of the effort in the design of Mesa went into the development of facilities for a modular style of programming. Definition modules are program components used to specify interfaces between clients and implementors of abstractions -- permitting them to work independently, and make changes independently, as long as they respect the interface. (Ideally, they would completely liberate each side from any knowledge of the internals of the other, but Mesa has not quite attained this ideal.)

It seems quite clear that one of the major thrusts of our future research must be building systems out of standard components, and decoupling the implementors and users of such components; Mesa provides our best effort so far in this abstraction-based direction. The need to specify interfaces in advance may be cited as either a strength or weakness of the Mesa approach, depending on circumstances and prejudices. The present need for vast recompilations whenever a fundamental interface is changed is a weakness that can certainly be reduced, and probably eliminated by incremental recompilation on demand.

Other notes:

A Mesa EPE would allow programming to be, in a very real sense, incremental, because much more of the burden of propagating the consequences of any change to a program could be assumed by the compiler and other EPE tools; conceptually small changes would not generally require large amounts of reprogramming.

One happy consequence of relatively early binding is that decisions made statically are generally much less expensive than those made (repeatedly) dynamically. This consequence should not be interpreted as the motivation for encouraging early binding in the EPE. Some of the present efficiency of Mesa would definitely be sacrificed in those situations where greater flexibility and later bindings are introduced. However, it should not be hard to retain an "efficient subset" (roughly SDD Mesa).