201 tific laboratory without walls. The growing acceptance of multimedia conferencing also reflects a change in the way conferencing is promoted; it is a supplement to, not a replica of, face-to-face collaboration. A testament to the staying power of the concept of conferencing is the emergence of commercial products that have actually made inroads in the market; Silicon Graphics' InPerson, ShowMe from Sun Microsystems, Intel's ProShare, and publicly available tools that are in widespread use on the Internet and MBone [Jacob-In particular, these developments are a result of the emergence of standards for interoperability. Windowing systems, such as the X window system [Scheifler et al. 1988], configurable graphical user interfaces, like the Tk/Tcl toolkit [Ousterhout 1990, Ousterhout 1991], and widely available network application programming interfaces (APIs), such as Unix sockets [Sun Microsystems 1988], all have given rise to more generalized software platforms on top of which interoperable systems can be built. Additionally, the increased speed of processors, disks and networks have contributed to the more rapid adoption of distributed solutions and the move to include various real-time media as standard data types. Nonetheless, there are still many aspects about computer architectures that make it difficult to achieve widespread availability of these services, from the need for communication standards to seamless techniques to accommodate multiuser GUIs. There is the continued challenge to support not only small groups or moderate sized organizations [Grudin 1994], which have traditionally been the focus of most groupware systems, but much larger scale telecollaborations [Schooler 1993a]. The expectation is that integrated solutions, combining audio, video and shared workspaces, will eventually make it as easy to rendezvous electronically as it is physically. More importantly, telecollaborations must support not one, but many real-world interaction protocols. Finally, an integral part of the coming-of-age process will be the continued attention to issues beyond the scope of technology itself.

Although individual use of computers is fairly widespread, in meetings we tend to leave them behind. At Xerox PARC, an experimental meeting room called the Colab has been created to study computer support of collaborative problem solving in face-to-face meetings. The long-term goal is to understand how to build computer tools to make meetings more effective.

Prolog was originally developed as a programming language for writing natural language parsers. This paper presents a prototype of a "grammar kit" written in Prolog. The kit consists of tools and examples intended to be used by children interested in exploring language. A grammar written in Prolog using this tool kit can be used not only to parse, but also to generate, sentences. A serious shortcoming of Prolog for children is that when a program misbehaves one must understand its complex operational semantics. A major tool in the grammar kit to alleviate this problem is a dynamic graphical tracer. This allows the user to see a parse tree as it is being built. This tool, in turn, depends heavily on a mechanism for delaying goals built into LM-Prolog. A rather significant side-effect of using the graphical tracer is a better understanding of Prolog's chronological backtracking. 1. Computers and Children The major goal of this research is to provide children with a rich computational environment for doing interesting natural language projects. While this environment is built upon Prolog, the methodology and philosophy is closer to that of SmallTalk (Goldberg and Ross, 1981) and Logo (Papert, 1980). In other words, children are encouraged to do relatively long-range projects in a very rich and powerful environment, and in the process, learn about the domain of the project (languages, translation, and grammar in this case), computational concepts such as variables, recursion, representation, process, etc. and learning itself. This research, in contrast with other projects dealing with Prolog and children (Ennals, 1982), is based upon the belief that the children should understand how Prolog works in order to use it. The pragmatic reason for this so that the children can cope with programs that don't behave properly. To some extent this problem is a consequence of the fact that Prolog does not live up to the ideal of logic programming very well. The order of clauses and goals matters. Shortcomings of the language are filled by extra-logical primitives. It may be the case that the most important thing that a child can get from using a computer is an understanding of process. A more powerful and cleaner logic programming language which comes closer to declarative programming than Pro log may actually be inferior from this point of view. There are at least three ways of helping children to understand the procedural interpretation of Prolog programs. • Develop a clear and simple operational model of Prolog and a methodology for introducing children to it. • Translate "troublesome" Prolog programs into a notation which the children can already understand procedurally. For example, the program could be automatically translated into Logo and studied in that form. 1 :revised February 2 1985 Grammar Kit Kenneth M. Kahn • Provide tools for observing Prolog in action. This is the approach presented in this paper. The major tool is a dynamic backtracking graphical trace facility. 2. Prolog and Language For doing projects such as building parsers, generators, translators, questionanswering systems and the like Prolog has the following advantages. • A parser can be used as a generator or visa versa. A translator works in either direction. • A program can be run on partial inputs. A sentence can be parsed with a few words unknown or generated where it is constrained to be a certain length or contain certain words. • The grammar can be described relatively declaratively without using a special parser. rt An "ask about" facility which asks the user if something cannot be found in the database and then adds the answer to the database is important for being able to use a system before it is complete. The sample parser presented in this paper, for example, has no vocabulary at all, it just knows enough to ask. • The Prolog database provides a natural and uniform way of connecting a natural language system and a database. • Pattern matching makes it easier to deal with structures such as lists and parse trees. On the negative side the implicit control does not always do the right thing. An expert Prolog programmer knows how to anticipate or detect such situations and to transform the program to fix the problem. A child cannot be expected to do that, at least without some simple yet powerful tools. An always up-to-date graphical image of the current state of computation is one such tool. There has been much work within the Prolog community on devising grammars that translate straight-forwardly into Prolog programs (Pereira and Warren, 1980). The grammar kit contains a predicate called ---1which transforms its arguments into an ordinary Prolog clause and adds it to the database. Consider the LM-Prolog (Carlsson and Kahn, 1983) definitions of the rule that a verb phrase can consist of a verb followed by a noun phrase, first with, then without, --+. (An LM-Prolog statement is a non-atomics-expression where variables are distinguished by beginning with a ?). (--+ !verb-phrase (vp ?verb ?np)) verb ?verb) noun-phrase ?np)) In DEC-10 Prolog, the above rule would, modulo Prolog syntax and placement of arguments, translate into a clause extending the verb-phrase predicate which is a relation between a tree structure and a part of a list of words: 2 :revised February 2 1085