[_CD8_]<cedardocs>per>report>per.5b!1

Danny Bobrow prepared a discussion of directions in which the Lisp environment will probably evolve if there is no special PE effort (on [Ivy]<Deutsch>per>future>epe-features.memo). At least some attention will be paid to several of our high-priority items, so things aren’t quite as orthogonal as with Smalltalk, but neither will it be anything close to what we have been hoping for and discussing. The following is a condensation of the major points from Danny’s memo.

(L6, L23) (processes, monitors, interrupts) Assuming that Pilot is easily available, Pilot’s features in this area will be supported, including the ability to resume a process independent of what language it is written in.

(L8) (packed data) Facilities for user data types, including packed data, will be made available. There will be nothing to compare with Mesa’s use of packed data; Danny doesn’t believe this is important in building experimental programs on the Dorado.

(L11) (static type checking) Larry Masinter’s thesis is likely to extend DeclTran to inter-function consistency checking. Mesa-style optimization is unlikely.

(L13, L25) (encapsulation) Something like the block compiler will get into the Dorado system, perhaps along the lines Danny and Peter worked out for the proposed XL system.

(L14) (abstraction) The type checking provided as a result of Larry’s thesis will make it possible to provide interface functions that resemble the current Mesa idea of an interface as a set of type specifications.

(L21) (integrated sublanguages) This is an area in which Lisp users have strong feelings. Here are Danny’s comments in full:

The ability to create sublanguages is one of the most important facets of Lisp programming as it is done. Interlisp itself has almost a dozen such sublanguages. KRL, ATN’s, etc. are all examples of how we capture our basic ideas in an abstract language which we want to use in conjunction with Lisp itself. I would rate this as an A priority item. Currently Lisp has the best facilities for building such languages, but full integration is a way off. In the next two years I see much more work done on this issue, making it even easier to drop into a dialect, and through that back into Lisp while passing the appropriate contexts.

(L30) (control and data trapping) KRL will be extended to make it cleaner and more efficient. There is some chance that more primitive facilities will be pushed down into the record package.

Ed Satterthwaite contributed a long memo (on [Ivy]<Deutsch>per>future>mesaprospects.bravo) discussing probable future SDD activities towards improving the Mesa environment. The following is a condensation of his overall remarks.

In the short term, any incompatible changes to the virtual machine or language will be strongly resisted unless the benefits of such changes are very substantial and very obvious. In the longer term, SDD should be interested in helping to design and implement significant extensions in these areas when they address acknowledged problems of interest to SDD (development of the process stuff provides a good model of how this might happen).

A lot will be done to improve the performance of all components of the Mesa system. I believe that the compiler, for example, will respond well to tuning and cleanup, especially on the Dstar.

For obvious reasons, there is interest in more extensive optimization (both speed and space), as in item (T13), and in static analysis that is likely to reveal lurking bugs (e.g., range analysis, uninitialized variable detection), as in item (T19). I (Ed S.) am personally interested in doing these sorts of things.

A lot of effort will go into tools. My feeling in the past has been that SDD’s tools are likely to be somewhat heavy-handed in providing administrative control; I have come to appreciate the controls for large, multi-person projects but am not convinced I would like them for a one or two person experiment.

SDD-produced products will clearly provide many of the functions we would like in packages, but it is unrealistic to expect packages from the product program except by luck (it might be possible to extract and repackage chunks of code). Collaborative development of packages with the prototype software group (who also need an (EP)E) seems more likely and promising.

(L12) (self-typing data) Sequences, cleaner variant records, some help with initialization and finalization; some language support for object-oriented programming, which is already in wide use as a programming style.

Development of a constraints interface, following Alan Borning’s work, possibly including pushing some of this down into the lower implementation levels.

Aside from the information retrieval area, which might address item (L3), this work does not relate directly to our high-priority items. Of course, the Smalltalk environment will also continue to improve in unanticipated ways as LRG builds tools for themselves.