PILOT(ID:8407/)Teitelman's structured editing environment References: The PILOT system, implemented within the interactive BBN LISP system, is a step in the direction of a programming laboratory. PILOT operates as an interface between the user and his programs, monitoring both the requests of the user and the operation of his programs. For example, if PILOT detects an error during the execution of a program, it takes the appropriate corrective action based on previous instructions from the user. Similarly, the user can give directions to PILOT about the operation of his programs, even while they are running, and PILOT will perform the work required. In addition, the user can easily modify PILOT by instructing it about its own operation, and thus develop his own language and conventions for interacting with PILOT. Several examples are presented. Extract: Introduction Introduction The research described in this paper focuses on the programmer's environment. This term is meant to suggest not only the usual specifics of programming system and language but also such more elusive and subjective considerations as ease and level of interaction, "forgivefulness" of errors, human engineering, and system "initiative." In normal usage, the word "environment" refers to the "aggregate of social and cultural conditions that influence tile life of an individual." The programmer1s environment influences, to a large extent determines, what sort of problems he can (and will want to) tackle, how far he can go, and how fast. If the environment is "cooperative" and "helpful" — the anthropomorphism is deliberate — then the programmer can be more ambitious and productive. If not, he will spend most of his time and energy "fighting" the system, which at times seems bent on frustrating his best efforts. One immediate goal to strive for is an environment comparable to that found in the well designed laboratory of the physical sciences. Such a laboratory usually contains equipment for many applications as well as facilities for designing and building new apparatus, or adapting that already present. In a large (well-funded) installation, the researcher will also often have available assistants for performing the "routine" tasks. For example, a chemist might simply request an analysis of a sample, and not have to itemize each step in the process. This type of assistant and assistance frees the researcher for problems more worthy of his attention. Computer based systems have been constructed that create this type of laboratory environment for certain well-defined areas, e.g., mathematics [3,5,6], design of electronic circuits [7], and generalized graphical design [4,8], such as for aircraft, automobiles, bridges, etc. These systems are organized to allow the computer to perform the routine work (where routine is a function of the sophistication of the system), While the user guides and directs the process at a relatively high level. For example, in the mathematical laboratory developed by William Martin, [5], the mathematician interacts with the computer by asking questions or making requests. The system employs graphical input and output (liqht-pen and display) to allow the mathematician to operate in an environment that closely resembles the pencil and paper with which he is already familiar. For output, the display utilizes subscripts, and observes the conventions concerning physical size, grouping, and placement or subexpressions which mathematicians have adopted to make it easier to read and comprehend mathematical formulae. For input, the mathematician can communicate directly with the computer via the light pen, either by writing new expressions, or by pointing to old ones, or portions thereof. In a typical case, the user might be trying to find the solution of a differential equation. On the screen are displayed one or two equations, while the user has in his head the name of several other expressions or partial results already studied and filed away. The user decides to perform an action such as substituting a displayed equation, solving it for some variable, expanding some subexpression in a certain way, or perhaps asking to see something else. He makes the request using a combination of light-pen and key-board signals. These are encoded and transmitted to the system where the appropriate routines compute or retrieve the required new expressions and transmit them back to the display routines which then compile and display the desired new picture. In this way, the user can perform in a few minutes a long and involved analysis which, assuming he did not make any mistakes or lose track of what he was doing, might otherwise take him many hours. This paper describes a step in the direction of such a laboratory for programming and programmers: the PILOT system. As with the mathematical laboratory, the goal is to allow the computer to perform the routine tasks while the user, in this case a programmer, is left free to concentrate on the more creative aspects of his problem, which is the writing and debugging of a program. Most of the previous efforts bent at improving the environment of the programmer have concentrated on providing and improving packages, such as editors, compilers, trace packages, display routines, etc. While a good deal of effort has been devoted to such facilities in the design of PILOT, the basic innovation of the PILOT system is the emphasis placed on the problem of making changes in programs. The reason for this emphasis is that making changes in programs is the task that occupies most of a programmers time and effort, from the early stages in the development of programs when they consist primarily of correcting syntactical and simple logical errors in individual subroutines, to the final stages when the programmer makes the type of logical and organizational changes that affect many different parts of his program. The problem of making changes to the PILOT system itself is handled as a special case of the problem of making changes in programs in general. Since PILOT is designed to facilitate making changes in programs, its tools and techniques can be ap-3lied directly to itself in what is essent-Lally a bootstrapping process. The user :an thus easily introduce new tools and/or modify existing ones to suit his own methods and problems, in short, tailor the performance of the system to suit himself. Furthermore, PILOT is designed with this in mind, so that it can cooperate with the user during this phase of the development. Extract: The PILOT System The PILOT System PILOT is implemented in the LISP programming language at Bolt Beranek and Newman Inc.. Cambridge, Massachusetts. [l] Although there is a PILOT subsystem in LISP, all of the features and tools described in this paper were incorporated directly into the BBN LISP system once their usefulness was established, and are now in general use by the entire community of LISP users. It is thus more meaningful to view PILOT as a conceptual system, a philosophy of design. It is this philosophy that we are trying to impart, in the hopes that it may prove useful in the design and construction of systems in other languages. Extract: Improving PILOT Improving PILOT "PILOT is the result of an evolutionary process extending over more than two years. However, there is no reason to assume that this process has terminated, nor that PILOT has reached some sort of ultimate state." This statement was written in my Ph.D. thesis three years ago, and in the elapsed time, many of the goals established for improvements and additions to PILOT have been realized in our present system. But the statement is still true, and the process still continues. One area of current interest is that of program-writing programs. Programming languages are currently designed to allow the programmer to express the operations he wants the computer to perform in a simple and concise fashion. However, often the programmer many not know precisely what operation he wants the computer to perform, although he may have a clear idea of what he wants the program to accomplish. That is, he may be able to give a description of its output, or the changes it should make in a data structure. This is not to say that the programmer could not construct the program. However, a system which could accept more goal-oriented descriptions of tasks and produce programs to accomplish them, even if only effective for simple, subroutine-level tasks, would further free its users for high-level operations. Such a system would require a fair degree of problem solving capability, and should have a sufficiently rich store of information about programming and programs to enable it to determine similarities in tasks. It should be able to adapt previously written or constructed programs to a new task. In other words, we are trying to construct a system that can handle more of the routine aspects of programming, in order to free the human to concern himself more with the creative aspects of the problem. This is the basic philosophy of the PILOT system: let the computer do it. The significance of PILOT is that it demonstrates this feasability and desirability of ths approach. Even in its current form, PILOT clearly siiows that it is possible to get computers to participate in, and cooperate with, research efforts in programming to a much greater extent than is now being done. in Donald E. Walker, Lewis M. Norton (Eds.): Proceedings of the 1st International Joint Conference on Artificial Intelligence IJCAI-69, Washington, DC, May 1969. William Kaufmann, 1969 view details |