<?xml version="1.0" standalone="yes"?>
<Paper uid="J80-2001">
  <Title>Toward Natural Language Computation 1</Title>
  <Section position="2" start_page="0" end_page="0" type="abstr">
    <SectionTitle>
1. Introduction
</SectionTitle>
    <Paragraph position="0"> Natural language programming has been proposed by many authors (Balzer\[2\], Green\[13\], Heidorn\[17\], Petrick\[25\], Sammet\[27\], Woods\[38\]) as the best way for humans to input their commands to computers.</Paragraph>
    <Paragraph position="1"> Humans have developed exquisitely efficient abilities for communicating with each other through natural language, and the possibility of similarly interacting with maclaines is worthy of investigation. The ability to program in natural language instead of traditional programming languages would enable people to use familiar constructs in expressing their requests, thus making machines accessible to a wider user group.</Paragraph>
    <Paragraph position="2"> Automatic speech recognition and synthesis devices could eventually smooth the communication even further. null On the other hand, many problems could arise when natural language programming is attempted (Dijkstra\[11\], Petrick\[25\], Simmons\[32\]), and any such research must deal with them. For example, it has been argued that current natural language technol- null system has the difficult task of learning what constitutes an acceptable input to the system. Instead of having to learn the relatively simple syntax of a clearly defined programming language, the user would be forced to learn a voluminous and very detailed set of rules giving what words and phrases can be used and how they can be combined. Thus the user would be taxed more heavily with a natural language system than with a traditional system. A second argument against natural language programming relates to its intrinsic vagueness and ambiguity. It is maintained that if one wishes to manipulate information precisely and reliably within a machine, a clearly defined and unambiguous language should be used. The programmer should not have to wonder about the meaning of a particular input to the system; he or she should know the meaning or be able to look it up easily in a manual. A third argument asserts that no one would use a natural language programming system, even if one existed, because it would be too verbose. Why should one be willing to input long and wordy descriptions of a desired computation when there exist simple, easyto-learn, and concise notations for doing the same thing? Copyright 1980 by the Association for Computational Linguistics. Permission to copy without fee all or part of this material is granted provided that the copies are not made for direct commercial advantage and the Journal reference and this copyright notice are included on the first page. To copy otherwise, or to republish, requires a fee and/or specific permission.</Paragraph>
    <Section position="1" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
1.1 A Natural Language Computer
</SectionTitle>
      <Paragraph position="0"> Formidable as these criticisms may seem, this paper will attempt to show that some of them can be overcome with a careful system design, while others may be simply wrong. This paper describes a system, called the Natural Language Computer (NLC), which makes it possible to perform a limited amount of natural language programming. This system enables a person to sit at a computer display terminal, observe his or her data structures on the screen, and watch the computation proceed as the individual commands are typed. The current implementation is specifically designed for array and matrix computation. In the example interaction of Figure 1, the user is creating a subroutine to add up the rows and columns of an arbitrary matrix. Each item that is modified by a command is marked with an asterisk and other items used in the calculation are marked with an apostrophe. The first two commands cause two matrices to appear on the screen, one to be operated on and the other to receive the answer. The third command provides some sample data for the calculation and the fourth command indicates that the imperative verb &amp;quot;sumcolrow&amp;quot; is about to be defined. Subsequent inputs tell exactly what operations must be done to sumcolrow a matrix into another matrix. For example, if after this dialogue the system receives the input &amp;quot;Sumcolrow matrix A1 into matrix Z.&amp;quot; where A1 and Z are matrices of appropriate dimensions, the procedure body following the define statement will be executed. Thus the dialogue causes the system to create a subroutine to be called by using the newly defined imperative verb &amp;quot;sumcolrow&amp;quot;.</Paragraph>
      <Paragraph position="1"> This process is explained in greater detail in later sections of the paper. The important point to be noticed here is that the user is able to watch the system respond to each command as it is entered. Whenever the system yields an undesired action, the user can back up and rephrase his or her command more clearly. This format for natural language programming enables users to examine system performance as each command is typed and to detect most errors immediately. null</Paragraph>
    </Section>
    <Section position="2" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
1.2 Concerning the Objections
</SectionTitle>
      <Paragraph position="0"> Given this brief introduction to the NLC user interface, it is already possible to respond to the first criticism of natural language programming given above.</Paragraph>
      <Paragraph position="1"> Although we feel that present day natural language processors tend to have very limited capabilities, it is quite possible within the NLC environment to direct the user to restrict the inputs appropriately. For this reason, the user is asked to follow two simple rules which are easily understood from the user's point of &amp;quot;Display a 3 by  view and which simultaneously ease the job of the system designers and implementers considerably.</Paragraph>
      <Paragraph position="2"> The first rule concerns the semantics of inputs: (1) The user may refer only to the data structures seen on the terminal screen and specify simple operations upon them.</Paragraph>
      <Paragraph position="3"> That is, the user may refer to matrices, rows, columns, entries, labels, numbers, variables, etc., and specify simple operations such as add, subtract, move, exchange, delete, label, etc. The user may not use domain specific vocabulary or concepts such as airplane flights, seats, passengers, and reservations. This rule is easily explained to a user and makes it possible to build a system without getting into the peculiarities of any specific domain. Although it requires the user to translate his or her problem into the vocabulary of the 72 American Journal of Computational Linguistics, Volume 6, Number 2, April-June 1980 Alan W. Biermann and Bruce W. Ballard Toward Natural Language Computation system, it also makes it possible to experiment with the system in many different domains.</Paragraph>
      <Paragraph position="4"> The second rule concerns the syntax of the inputs: (2) The user must begin each sentence with an imperative verb.</Paragraph>
      <Paragraph position="5"> This rule is also easy to explain to the user and it also greatly restricts the variety of sentences to be processed. If this rule is followed, the system can find out much about each clause from its first word, including what words or concepts may occur later in the clause.</Paragraph>
      <Paragraph position="6"> In summary, the strategy for achieving person-tomachine language compatibility taken here is (1) to find a small number of simple rules which a person can easily follow to restrict the set of inputs; and then (2) to stretch the language processing technology to the point where it can reasonably cover that set. When this is done, the first criticism of natural language programming stated earlier is overcome.</Paragraph>
      <Paragraph position="7"> The other major objections to natural language programming relate to its vagueness, ambiguity, and alleged verbosity. Perspectives on these issues can be achieved by examining some examples of natural language and the corresponding programs in traditional programming languages. Consider for example the command &amp;quot;Square the sixth positive entry in matrix M.&amp;quot; Vagueness does not appear to be a problem with the English of this example. In fact, the sentence is probably shorter than most equivalent formulations written in traditional programming languages. The corresponding code in almost any programming language will require some declarations and a nesting of looping and branching constructs. As an additional example, the reader should examine the English language program and its corresponding PL/I counterpart which is included in the Appendix. Our experience so far with English language programming seems to indicate that the language is as precise as its user wants it to be.</Paragraph>
      <Paragraph position="8"> Concerning the length of English language programs, they seem to be comparable to the length of ordinary programs in the domains we have examined. Of course, one could write down a complicated arithmetic expression from some standard programming language and note that its English equivalent is relatively long, unreadable, and unwieldy. The solution to this problem is to include in the natural language processor the ability to handle such arithmetic expressions. Considering the complexity of any reasonable natural language processor, the cost of adding something like an arithmetic expression handler is modest. Other constructs from programming languages which are shown to be convenient could also be considered for inclusion. null</Paragraph>
    </Section>
    <Section position="3" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
1.3 Background
</SectionTitle>
      <Paragraph position="0"> The NLC system has grown out of an earlier series of studies on the &amp;quot;autoprogrammer&amp;quot; (Biermann\[6\]) and bears much resemblance to it. Program synthesis in both the current and the previous systems is based upon example calculations done by the user on displayed data structures. In the current system, the example is done in restricted English with all its power, which is a dramatic departure from the earlier approach, which simply involved pointing with a light pen. However, it is expected that many of the features from the autoprogrammer, such as &amp;quot;continue&amp;quot; and &amp;quot;automatic indexing&amp;quot;, will transfer quite naturally into NLC. This paper emphasizes the natural language aspects of the system, while other reports deal with some of the additional automatic programming features. The relationship of NLC to other research in natural language processing is discussed in a later section. null The next section presents an overview of NLC, after which subsequent sections discuss scanning, syntactic and semantic processing, and interpretation of commands in the &amp;quot;matrix computer&amp;quot;. The next two sections discuss the processing of flow-of-control commands and the level of behavior achieved by the system. The final sections include a discussion of related research and conclusions.</Paragraph>
    </Section>
  </Section>
class="xml-element"></Paper>