V.PROGRAMMING RESEARCH

A.Cedar

Activities

Language: The Language Features Design Committee completed a revision of the proposal for the version of Cedar Mesa to be initially implemented ("Cedar Mesa--Version 6C2," February 15, 1980). [Horning, Morris, Rovner, Satterthwaite(SDD)].

Many of the changes needed for Cedar Mesa (e.g., NEW, typed NIL and NIL-checking, simple opaque types) have been incorporated in the Mesa 6.0 compiler supported by SDD [Satterthwaite]. The garbage collector, which is the most critical component of the Cedar Mesa runtime system, has been thoroughly tested [Rovner]. Other changes needed for Cedar Mesa have been incorporated in the compiler [Satterthwaite(SDD), Atkinson] and runtime system [Rovner], including: automatic initialization of reference-containing variables, reference-counted assignments, NEW, zones, Atoms, type equivalence, run-time type checking. Part of Poplar has been converted to use the garbage collector.

A Cedar Style sheet has been developed [Mitchell], to encourage uniformity of coding style within Cedar. Guidelines for the use of signals that cross abstraction boundaries have been published [Levin]; these have led to a few proposals for further modest changes to Cedar Mesa that will be considered later this year.

The rest of this year will be devoted primarily to implementation of the remaining Cedar Mesa changes described in the 6C2 document, including: enforcement of safety restrictions in checked regions; sequences; TEXT; bases; REF ANY; dynamic type discrimination; code generation for FREE; APPLY; LIST OF; and object-oriented notation [Atkinson, Satterthwaite(SDD), Rovner]. The compiler will be restructured to permit use/replacement of several pieces (compiler factorization)[Satterthwaite(SDD), Horning, McKeeman, Atkinson, Teitelman].

Kernel: The Cedar Kernel group has produced an initial version of the kernel as a layer on top of Pilot. Plans are being developed for extending the kernel to support remote files accessed through the virtual memory system and cached locally for increased performance. A directory system and runtime facilities to support the safe language’s storage allocator are largely designed and implementation is projected to begin later this year. Two program development environments, one based on Alto/Mesa and one on Pilot, are being produced in cooperation with SDD. We expect that these development environments will be in regular daily use throughout CSL by the end of the calendar year.

Methodology: During this period we spent some time developing a set of stylistic conventions for writing programs that are to be part of the Cedar system. These conventions fell into two main classes, syntactic conventions for writing programs, and structural conventions for object-oriented programming. The former is important to make programs more readily understandable, and the latter is important because it establishes one well-understood mechanism for defining interfaces to objects as a de facto standard.

User Facilities: Following a design developed during the previous period, we implemented the displaying of a number of classes of Cedar documents, including simple string documents, desktops, windows (a window is a desktop composed of panes that completely fill the rectangular desktop area). The implementation uses the Cedar graphics package. [Warren Teitelman, Bill Paxton]

We investigated how the Cedar debugger, compiler, and run-time support (the Cedar "Abstract Machine") would interact to evaluate expressions at run time, to provide Interlisp-style advising, a powerful breakpointing facility, and to access/display values using the run-time type system designed by Paul Rovner. This resulted in the specification of a set of interfaces for these tasks [Jim Mitchell, Will Crowther, Paul Rovner, Ed Satterthwaite]

We have begun implementation of the base-level software for providing input events from the user (keystrokes, mouse positions and selections) to higher level software [Dan Swinehart]

We have specified, as a set of drawings and notes, the main features of the Cedar Executive, to allow a user to have many separate programs simultaneously active, to move his focus of attention from one to another smoothly, and to be notified when a program requires attention without preempting what he is doing at the moment. To the same level of detail, we have designed parts of the "debugger panel" seen by a user when controlling, modifying, and examining a program under development. [Jim Mitchell, Will Crowther]

In the next period, we plan to document what we have learned so far about displaying Cedar documents, to develop the interfaces that will enable selections, editing, and formatting of Cedar documents, and then to implement those interfaces for a selected class of documents, including menus, desktops, windows, and text documents. This will also require integrating the user input facilities with Cedar document facilities.

We plan to implement enough of the Cedar executive to test the ideas about the user interfaces for managing a set of simultaneously active programs and to provide the basic functions of logging in, loading and starting programs, listing directories, etc.

We also plan to implement the debugger functions for displaying variables simply and for displaying contextual information including which modules and configurations are loaded in a program, the state of the various processes that exist in that program and the stacks for the processes. The variables in module and stack frames will be displayable as well.

Data Base: We completed a description of our system that is accessible to novice database users (C+F.press). It documents DBTuples, the Mesa interface to the initial database facilities, and gives guidelines for database design. We implemented much of DBTuples, and lower levels of the system have been extensively tested. [Brown, Cattell, Suzuki] We have nearly completed a database "browser" user interface and a simple report generation facility that run on DBTuples. [Cattell]

The system is now sufficient to support "friendly" applications, and such applications are just what we need to test the adequacy of the DBTuples interface. We shall work on two applications this summer, with the help of summer students: a Mesa source code database [Brown], and a CSL notebook database [Suzuki]. Both of these will require further development of the browser [Cattell]. We shall also put effort into filling out the implementation of DBTuples, and building basic system utilities such as a scavenger.

System Models: A design document specifying the system modelling language has been written and revised once after some examples were tried. An interm facility, called MakeConfig, has be developed to create systems from their configuration files by performing all the necessary file trasfers, compilations, and bindings automatically. Besides its immediate usefullness, this facility contains many building blocks for the eventual model implementation.