This joint panel between UIST and CSCW brings together leading researchers at the intersection of the conferences-systems researchers in collaborative and social computing-to engage in a discussion and retrospective. Pairs of panelists will represent each decade since the founding of the conferences, sharing a brief retrospective that surveys the most influential papers of that decade, the zeitgeist of the problems that were popular that decade and why, and what each decade's work has to say to the decades that came before and after. The panel is intended as a space to celebrate advances in the field, and reflect on the burdens and opportunities that it faces ahead.

No abstract available.

No abstract available.

Experience implementing CES, a distributed collaborative editing system, is described. CES was written in Argus, a language that was designed to support the construction of reliable distributed programs, and exhibits a number of requirements typical of distributed applications. The authors' experience illustrates numerous areas in which the support provided by Argus for meeting those requirements was quite helpful, but also identifies several areas in which the support provided by Argus was inadequate. Some of the problems arise because of the distinction in Argus (and in other systems) between locally and remotely accessible data and the mechanisms provided for implementing each. Others arise because of limitations of the mechanisms for building user-defined data types. The authors discuss the problems they encountered, including the implications for other systems. They also suggest solutions to the problems, or in some cases further research directed at finding solutions.>

No abstract available.

No abstract available.

Data sharing is fundamental to computer-supported cooperative work: People share information through explicit communication channels and through their coordinated use of shared databases. This paper examines the data management requirements of group work applications on the basis of experience with three prototype systems and on observations from the literature. Database and object management technologies that support these requirements are briefly surveyed, and unresolved issues in the particular areas of access control and concurrency control are identified for future research.

Data sharing is fundamental to computer-supported cooperative work: 'people share information through explicit communication channels and through their coordinated use of shared databases. Database support tools are therefore critical to the effective implementation of software for group work. This paper surveys data sharing requirements for group work, highlighting new database technologies that are especially likely to affect our ability to build computer systems supporting group work.

This paper describes our experience implementing CES, a distributed Collaborative Editing System written in Argus, a language that includes facilities for managing long-lived distributed data. Argus provides atomic actions, which simplify the handling of concurrency and failures, and mechanisms for implementing atomic data types, which ensure serializability and recoverability of actions that use them. This paper focuses on the support for atomicity in Argus, especially the support for building new atomic types. Overall the mechanisms in Argus made it relatively easy to build CES; however, we encountered interesting problems in several areas. For example, much of the processing of an atomic action in Argus is handled automatically by the run-time system; several examples are presented that illustrate areas where more explicit control in the implementations of atomic types would be useful.

Research on human factors in computer systems has emphasized supporting individuals. This panel will discuss new issues that emerge when computer systems support groups of people and whole organizations. Malone (see following paper) will suggest a broadening of the definition of user interfaces to include “organizational interfaces” and will indicate how a theoretical base for such an endeavor might be developed. Then Cashman will describe a “coordinator tool” in use at DEC for tracking the assignment of tasks to people in activities such as software maintenance. Finally, Brown will suggest how computer systems can be designed to radically increase the bandwidth of cooperation in groups by, for example, exploiting linguistic notions of context.

We consider three kinds of mathematical objects which can be designated as the "meaning" or "semantics" of programs: binary relations between initial and final states, binary relations on predicates (partial-correctness semantics), and functionals from predicates to predicates (predicate transformers).We exhibit various formal specification mechanisms: induction on program syntax, axioms, and deductive systems.We show that each kind of semantics can be specified by several different mechanisms.As long as arbitrary predicates on states are permitted, each kind of semantics uniquely determines the others, with the sole exception of the weakest precondition semantics for nondeterministic programs.

Hoare and Lauer [1974] have advocated using a variety of styles of programming language definitions to fit the variety of users from implementers to program verifiers. They consider the question of whether different definitions and specifications determine the same language by showing that the definitions are what they call "consistent". However, their treatment skirts the question of whether their definitions can each be taken to specify the language adequately. Although, as we will show, any one of the kinds of semantics they discuss -- operational, relational, deductive -- can be used to specify meaning uniquely, Hoare and Lauer do not make the case in their paper. In fact, both their relational and deductive definitions are satisfied by several different semantics, only one of which is desired.Thus, the main point of this paper is to clarify the characteristics of a proper specification of language semantics and to formulate alternative specifications each of which is equally good as the language definition. We basically agree with Hoare and Lauer that several specifications can and should be given, but are disturbed by confusions about such specifications, some of which are illustrated in their paper. In particular we refer to confusions between the mathematical object which is designated to be the meaning of a program and methods for specifying that object; the similar confusion between predicate and expression; between consistency and equivalence of two definitions; between completeness of a theory and its having a unique model. While these issues are familiar in mathematical logic, we take this opportunity to survey them in the context of programming language semantics.This paper can be read without prior familiarity with Hoare and Lauer's paper. The authors plan another paper extending this work which will include a more comprehensive bibliography.

Work on PLANNER-73 and actors has led to the development of a basis for semantics of programming languages. Its value in describing programs with side-effects, parallelism, and synchronization is discussed. Formal definitions are written and explained for sequences, cells, and a simple synchronization primitive. In addition there is discussion of the implications of actor semantics for the controversy over elimination of side-effects.

The PLANNER project is continuing research in natural and effective means for embedding knowledge in procedures. In the course of this work we have succeeded in unifying the formalism around one fundamental concept: the ACTOR. Intuitively, an ACTOR is an active agent which plays a role on cue according to a script. We use the ACTOR metaphor to emphasize the inseparability of control and data flow in our model. Data structures, functions, semaphores, monitors, ports, descriptions, Quillian nets, logical formulae, numbers, identifiers, demons, processes, contexts, and data bases can all be shown to be special cases of actors. All of the above are objects with certain useful modes of behavior. Our formalism shows how all of these modes of behavior can be defined in terms of one kind of behavior: sending messages to actors. An actor is always invoked uniformly in exactly the same way regardless of whether it behaves as a recursive function, data structure, or process.