///Cedar/Notes.tioga -- Last Edited by: Swinehart, March 25, 1985 7:29:04 am PST Warren's paper maybe not cited prominently enough now. {Need to make sure that "where the processes are" shows up somewhere. Still worried about extent to which nature of the multiple process environment shows up -- extension to inscript?} Mark's notes on the Cedar release cycle should be developed into a paper for this conference too, actually! RPC part: communication with other languages. Relationships to STAR??? 2.3.6 Left out: DFPackage (but see tool/command later). User profile, Credentials, .... Is there something in here that ought to go back into thee Cedar Language section? Later is OK. A Cedar interface type is a specification for a collection of procedures, variables, and data types that together implement a particular abstraction: a text stream, a symbol table, or a compiler. A Cedar program module does not provide its services directly to other modules, but instead exports their implementation to an interface, a value derived from the associated interface type. A client program that wants to make use of the abstraction does so by issuing calls on the interface's procedures, qualified by the interface name. An implementation for that interface is supplied by a later binding or runtime loading procedure. This later binding of the actual implementation for a particular instance of the interface permits implementations to be modified or even substituted without the need for recompilation of client programs in order to guarantee type-safety and version consistency: as long as a modified implementation still satisfies its interface description, it still satisfies at least the formal requirements of its clients. Remains to fix: Integration, coexistence, cooperation prattle. Life support "off in a corner" discussion: make points clearly -- needs example. Way to talk about the hardware and microcode. More multiple processes -- assoc. with TIP. Howard additions: Runtime types get better press. Things to do: Shorten Make theme more comprehensible. Finish bibliography. Bug Elkind. Tightened-up theme: Notion of procedures and separately-loadable code made Open architectures in single address spaces possible -- with care. Mesa/Pilot, with interfaces, configs, type checking, decent-sized VM, and automatic code swapping, made it reasonable: documentation, some protection, some automatic structuring, not so much hand-tuning. Cedar makes it (almost) SAFE, so that it is a true competitor to the "closed" system: safe subset made possible by automatic storage management. Safe to call procedures in the same address space, to pass allocated objects back and forth, to pass around objects with procedures in them and expect the same procedures to be there when you try to call them: Comparisons: Unix -- closed Lisp -- inherently safe, open, no help (need term) Smalltalk -- similarly safe (except?), open, different help. Mesa -- open, helpful, not so safe. Section 3 rewrite. Old section 3 outline. We're talking about Cedar language and runtime features that support OA; and what's missing. Interfaces and such. M Good grain of resolution for components. Names meaningful throughout. M Type checking of calls and parameters. Configurations M Helps to provide closed sub-components, define which interfaces are really translucent Translucency A But configuration loses all structure among translucent components A For enforcing downward only A For user documentation A Probably we could extend the language and load state. Safe Storage C (Permits safe subset of language that adds much bullet-proofing to open system.) C Cleaner interface between user and system. C Ownership made less an issue C Convenience as well -- cleaner code. Usage discussion B/C Can readily replace a component because the system comes in pieces and is carefully described by DF files, and booting is set up to accommodate this. A Can often run exptl. version alongside, sharing lower (and sometimes higher) layers. M Can use incompatible lower components privately, using configs DF's C (but inherited) Type checking catches problems. Good system description prevents them. New outline Intro: Progression has been from possible/experimental to Reasonable to Safe/Reliable. Will discuss the additions at each point. Consider in detail only the major progression. Earlier PARC open systems BCPL-based Intro: Possible. Language with procedures, sep. compilation, loading, like C. Full-fledged open system. Substitute or alternate implementations, full translucency. Levels, memory management, validity of procedure pointers in objects, data structures in general, code loading and swapping, all done by convention and packages. Effective, but dangerous. Mesa Intro: Reasonable. Interfaces for good grain of resolution, documentation through official names usw. Type checking for calls and parameters and contents of fields in records. Configurations allow hiding of non-players, use of non-standard lower-level components. Pilot VM. Careful design of lowest levels. Processor-independence. Cedar Intro: Safe, reliable, competitive with "Closed" systems. Safe subset adds safety in type checking, confidence in memory integrity -- code, frames, and allocated data. Use of SafeStorage types add convenience, cleanliness, reliability based on ownership argument. Replacement/parallel operation made convenient because system is constructed in pieces and because DF files describe consistent versions of those pieces. Still missing Language and runtime support for enforcement of TA rules, direct revelation of H of C structure. Hardware possibilities without losing OA. 3/10/85 Notes "Open" system, as we mean it, seems to mean all of the following: Open2: meaningful lower-level "VMachines" available, substitutes possible Uniform: language-level call syntax & data types @ all levels that programmer can reach at all. Layered: careful attention to dependencies, organization of system, as kernel & higher levels Transucent: Open2, Layered Safe: Cedar-safe Protected: Safe or firewalled. Packaged: some notion of interface. BCPL Open2, Uniform, part-layered, translucent. Mesa/XDE Open2, Uniform, layered, translucent, packaged. Cedar All of the above. All Open systems to date are based on single-address space. Most open2 systems would have to be categorized that way, although any single-user system is in a sense open2 (one can go change the operating system.) Cedar (& Pilot) are really modified open2, since lots of stuff is intentionally buried in configs, open2 only to subset of system. Smalltalk Has always been Safe, thus Protected Has always been at least nearly-Uniform Layered maybe, but not particularly explicit -- class structure shows composition of implementations, doesn't indicate intended dependencies among disjoint classes -- global name space provides near-complete access. Packaged -- yes, at object-level and category level. Recent versions are largely Open2. More notes: Be sure to mention finalization in Safe Storage component section. Discussion should inherit all or part of: Providing automatic storage management eliminates the concern over ownership of shared objects. When a module interface returns a new object (a pointer to some newly allocated memory space) the space for that object is always owned by the storage management system rather than by the client or the implementation program. The client program may use the pointer as it sees fit, pass it on to another client, retain it, or dispose of it. Since the storage management system can discover what storage is accessible, the storage will be reclaimed only when no remaining valid references to the object exist. As a result of automatic storage management, programmer time and effort spent on solving problems related to storage management has decreased from an estimated 40% in Mesa to an estimated 5% in Cedar. Safe Storage: This component also deserves considerable attention, because it is both a significant source of improved programmer productivity and an important contributor to the success of Cedar as a reliable but open programming environment. In response to an explicit program request for a new region of storage of a specified type, SafeStorage allocates one and returns a reference (pointer) to it. A pair of garbage collectors reclaim the storage when no reachable references to it remain: one is incremental and unobtrusive but incomplete, while the other is thorough but preemptive [5]. Type information associated with each allocated object allows the garbage collectors to locate and process embedded references. These characteristics make programming easier; in section 3 we also argue that they help to improve the structure and reliability of the Cedar open architecture. Because Cedar has SafeStorage, it can also have some other things. Variable-length text strings (ROPEs), linked lists containing values of arbitrary (but specified) type, and Lisp-like atoms are data types that have been introduced into the Cedar language. The inclusion of type information with every allocated object also enables a safe (and cheap) implementation of generic pointers. Cedar programs can manipulate references to objects whose types they do not specify, performing runtime type checks or type-based dispatches in order to access the referenced objects. Rovner covers Cedar storage management in more detail in [20]. See Also 2.3.4 in the original non-summary. Extracted from the Viewers section, for use in "part 2": The relationship between the lower-level Terminal interface, the Graphics interface, and Cedar Viewers provides the setting for a compelling example of the nature of the open, or translucent, architecture of Cedar: Most clients obtain their screen real estate by creating viewers, then using built-in display capabilities of one of the standard viewer classes, or providing their own images through the Graphics interface. With some care, one can descend below the Graphics abstraction and directly manipulate the bit map within a Viewer -- for performance, or in order to render something that the Graphics package does not directly support. Finally, by using facilities in the lower-level Terminal interface, an experimental or antisocial application can gain access to a virtual screen/keyboard pair that is completely separate from the standard Cedar screen. On this screen the application has free rein to manipulate its screen's bitmap, using all or none of the Viewers and Graphics facilities as it chooses. There are functions in Terminal for switching from one virtual terminal (or virtual universe, as far as the user is concerned) to another. These examples represent a consistent degree of coexistence, with varying degrees of integration! Each step away from standard behavior requires more effort and more care, both to obtain the desired results and to avoid untoward side effects. As usual, few programs need to use these escape mechanisms, but in these few instances their availability is vital. For every application, there's usually a package. That doesn't come through very well in the higher levels of the overview. Notably missing are ReadEvalPrint and Interpreter. Here is some text that has been left out, relating to the above. Life Support includes a parser and interpreter for Cedar expressons. Given a Cedar ROPE containing a valid expression and some parameters that specify the execution context, the interpreter evaluates the expression, returning the result in the descriptive form used by the Cedar abstract machine. The interpreter can be used for debugging, of course, but it is equally applicable to other applications. In support of debugging, one can create an Interpreter Tool that uses the Intepreter package to evaluate successive expressions as the user types them into the tool's viewer. Here's an apologia for the command tool -- shouldn't exist when nice display-oriented tools are developed. As Cedar applications mature, they usually are equipped with user interfaces that exploit the power and convenience of the two-dimensional, high-resolution display. During development, it is often easier to test new features through a simple command interpreter. Several such interpreters have been produced for cedar (including the Cedar expression interpeter, of course), some specialized, some more general. (Leads to Command tool discussion)