<?xml version="1.0" standalone="yes"?>
<Paper uid="J83-2002">
  <Title>Treating Coordination in Logic Grammars</Title>
  <Section position="3" start_page="0" end_page="0" type="metho">
    <SectionTitle>
2. Modifier Structure Grammars
</SectionTitle>
    <Paragraph position="0"> The most fundamental type of logic grammar is Colmerauer's (1978) metamorphosis grammar (MG).</Paragraph>
    <Paragraph position="1"> Grammars of this type can be viewed as generalized type-0 phrase structure grammars in which the grammar symbols (terminals and non-terminals) are terms from predicate logic. In derivations, the rewriting of symbol strings involves unification (Robinson 1965), instead of simple replacement.</Paragraph>
    <Paragraph position="2"> F. Pereira's (1981) extraposition grammars (XGs) are essentially generalizations of MGs designed to handle (left) extraposition. In the left-hand side of an XG rule, grammar symbols can be connected by the infix operator '...', indicating a gap. When such a rule is used in rewriting, the gaps appearing in the left-hand side may match arbitrary strings of grammar symbols, and then the left-hand side is replaced by the right-hand side followed by the symbol strings matched by the gaps (in the same order). For example, the XG rule a,b...c...d --&gt; e,f is really a rule schema a,b,X,c,Y,d--&gt; e,f,X,Y where X and Y stand for arbitrary grammar symbol strings. There is a constraint on the use of gaps in rewriting called the bracketing constraint, for which we refer to F. Pereira (1981). However, our MSG interpreter includes XG interpretation, so the use of gaps is in fact completely specified below.</Paragraph>
    <Paragraph position="3"> In XG rules, symbols on the left-hand side following gaps represent left-extraposed elements. For example, the extraposition of noun phrases to the front of relative clauses (with replacement by relative pronouns) can be handled by the XG rules: relative clause --&gt; rel marker, sentence.</Paragraph>
    <Paragraph position="4"> rel_marker...trace -- &gt; rel_pronoun.</Paragraph>
    <Paragraph position="5"> nounphrase --&gt; trace.</Paragraph>
    <Paragraph position="6"> where 'trace' marks the position out of which the noun phrase is being moved, and is used by the second rule above in conjunction with a relative marker to produce (or analyze) a relative pronoun.</Paragraph>
    <Paragraph position="7"> Pereira's implementation of XGs is a Prolog program that compiles XGs to Horn clause systems, which in turn can be run by Prolog for parsing sentences. In the compiled systems, extraposition is handled by the manipulation of a stack called the extraposition list, which is similar to the HOLD list for ATN's (Woods 1973). Elements (like 'trace' above) on the left-hand sides of XG rules following the initial symbol are in effect put on the extraposition list during parsing, and can be taken off when they are required later by the right-hand side of another rule. Our MSG interpreter uses a reformulation of this same method.</Paragraph>
    <Paragraph position="8"> Since the grammar symbols in XGs (and MGs) can be arbitrary terms from predicate logic, they can contain arguments. These arguments can be used to hold useful information such as selectional restrictions and analysis structures. For example, in the rule</Paragraph>
    <Paragraph position="10"> each non-terminal is augmented with an argument representing a syntactic structure. (Here, following Prolog-10 syntax, the capitalized items are variables.) Manipulating such arguments is the only way of getting analysis structures in XGs. As indicated in the Introduction, a new ingredient in MSGs over XGs is to automate this process, or to make it implicit in the grammar.</Paragraph>
    <Paragraph position="11"> MSG rules are of two forms. The basic form is A:Sem--&gt; B.</Paragraph>
    <Paragraph position="12"> where A--&gt;B is an XG rule and Sem is a term called a semantic item, which plays a role in the semantic interpretation of a phrase analyzed by application of the rule. The semantic item is (as in McCord 1981) of the form Operator-LogicalForm where, roughly, LogicalForm is the part of the logical form of the sentence contributed by the rule, and Operator determines the way this partial structure combines with others. Details on semantic items are postponed to Section 4 (on semantic interpretation). Actually, the current section and Section 3 deal mainly with syntactic constructions which are independent of the form of semantic items.</Paragraph>
    <Paragraph position="13"> The second type of MSG rule looks exactly like an XG rule (no Sem is exhibited), but the system takes care of inserting a special &amp;quot;trivial&amp;quot; Sem, g-true. (Here the '8' is the operator for left-conjoining, described in Section 4.) Most MSG rules for higher (non-lexical) types of phrases are of this type, but not all of them are.</Paragraph>
    <Paragraph position="14"> A simple example of an MSG is shown in Figure 1.</Paragraph>
    <Paragraph position="15"> Following the notational conventions of XGs (as well as the simpler definite clause grammars built into Prolog-10), we indicate terminal symbols by enclosing them in brackets \[ \]. Rules can contain tests on their right-hand sides, enclosed in braces {}, which are Prolog goals. In this example, the tests are calls to the lexicon, shown after the grammar rules, which consists of assertions (non-conditional Horn clauses).</Paragraph>
    <Paragraph position="16"> This grammar, together with the semantic interpretation component, will handle sentences like the following, producing the indicated logical forms:  72 American Journal of Computational Linguistics, Volume 9, Number 2, April-June 1983 Veronica Dahl and Mlichael C. IVlcCord Treating Coordination in Logic Grammars sent--&gt; nounph(X),verbph(X).</Paragraph>
    <Paragraph position="17"> nounph(X) --&gt; det(X),noun(X).</Paragraph>
    <Paragraph position="18"> nounph(X) --&gt; proper_noun(X).</Paragraph>
    <Paragraph position="19"> verbph(X) --&gt; verb(X,Y),nounph(Y).</Paragraph>
    <Paragraph position="20"> det(X):Sem--&gt; \[D\],{d(D,X,Sem)}.</Paragraph>
    <Paragraph position="21"> noun(X):g-Pred--&gt; \[N\],{n(N,X,Pred)}.</Paragraph>
    <Paragraph position="22"> proper_noun(N) --&gt; verb (X,Y): g-Pred -- &gt;  John saw Mary.</Paragraph>
    <Paragraph position="23"> saw(john,mary).</Paragraph>
    <Paragraph position="24"> John heard each woman.</Paragraph>
    <Paragraph position="25"> each(Y,woman(Y),heard(john,Y)).</Paragraph>
    <Paragraph position="26"> Each man saw a woman.</Paragraph>
    <Paragraph position="27"> each(X,man(X),exists(Y,woman(Y),saw(X,Y))).</Paragraph>
    <Paragraph position="28"> A larger example MSG is listed in the Appendix. This grammar includes rules dealing with extraposition, and the lexicon contains rules used by the MSG interpreter in handling coordination.</Paragraph>
    <Paragraph position="29"> Now let us look at the formation of syntactic structures by the MSG system. As stated in the Introduction, syntactic structures are trees called modifier structure (MS) trees.</Paragraph>
    <Paragraph position="30"> Suppose that a phrase is analyzed by application of an MSG rule A:Sem --&gt; B.</Paragraph>
    <Paragraph position="31"> and further rule applications in an MSG. (The Sem may be explicit or supplied by the system for the second type of rule.) Then the modifier structure of the phrase is a term of the form syn(NT,Sem,Mods) where NT is the leading symbol (a non-terminal) in A and where Mods is the list of modifier structures of the subphrascs analyzed with the right-hand side B of the rule. The 'syn' structure is considered a tree node, labeled with the two items NT and Sem, and having daughter list Mods.</Paragraph>
    <Paragraph position="32"> As an example, the MS tree for the sentence &amp;quot;Each man saw a woman&amp;quot; produced by the grammar in Figure 1 is shown in Figure 2. This tree is printed by displaying the first two fields of a 'syn' on one line and then recursively displaying the daughters, indented a fixed amount.</Paragraph>
    <Paragraph position="34"> Let us now indicate briefly how MSGs can be compiled into XGs so that these MS trees are produced as analyses. This method of compiling does not handle coordination metagrammatically (as does the interpreter), but it does seem to be of general interest for MSGs.</Paragraph>
    <Paragraph position="35"> In the compiled XG version of an MSG, each non-terminal is given two additional arguments, added, say, at the end. Each argument holds a list of modifiers.</Paragraph>
    <Paragraph position="36"> If the original non-terminal is nt(X1 .... ,Xn), the new non-terminal will look like nt(X1 .... ,Xn,Modsl,Mods2).</Paragraph>
    <Paragraph position="37"> When this non-terminal is expanded by a non-trivial rule, then Modsl will differ from Mods2 by having one additional modifier on the front, namely the modifier contributed by the rule application. A rule is trivial if its right-hand side is empty. When a trivial rule is used to expand 'nt' above, Modsl will equal Mods2.</Paragraph>
    <Paragraph position="38"> As an example of rule translation, the first rule in Figure l is translated to</Paragraph>
    <Paragraph position="40"> Any non-terminal on the left-hand side of an MSG besides the leading non-terminal is given a pair of identical Mods arguments (because it contributes no modifier by itself). For example, the MSG rule rel mk(X)...trace(X) --&gt; rel_pron.</Paragraph>
    <Paragraph position="41"> would translate to</Paragraph>
    <Paragraph position="43"> American Journal of Computational Linguistics, Volume 9, Number 2, April-June 1983 73 Veronica Dahl and Michael C. McCord Treating Coordination in Logic Grammars For parsing a sentence with respect to the grammar in Figure 1, one would use sent(\[MST\],\[ \]) as start symbol (with MST unknown) and the parse would bind MST to the modifier structure tree of the sentence.</Paragraph>
    <Paragraph position="44"> Pairs of list arguments manipulated in the way just outlined are called &amp;quot;difference lists&amp;quot;, and the technique is common in logic programming. One part of compiling MGs to Horn clauses is the addition to each non-terminal of an argument pair for the terminal strings being analyzed. Pereira's compilation of XGs to Horn clauses involves one more argument pair for extraposition lists. So the compilation of MSGs to Horn clauses involves three argument pairs totally. In the MSG interpreter, described in the next section, only a single argument (not a pair) is needed for each of these three lists.</Paragraph>
    <Paragraph position="45"> 3. The MSG Interpreter and the Syntax of Coordination Our MSG processor actually has a bit of compiler in it, because there is a preprocessor that translates MSG rules into a form more convenient for the interpreter to use.</Paragraph>
    <Paragraph position="46">  where NT is the leading non-terminal in A, Ext is the conversion of the remainder of A into an extraposition list, and B1 is the conversion of B to list form. The notion and representation of extraposition lists used here are just the same as F. Pereira's (1981). A node in such a list is of the form x(Context,Type,Symbol,Ext) where Context is either 'gap' or 'nogap', Type is either 'terminal' or 'nonterminal', Symbol is a grammar symbol, and Ext is the remainder of the list. We denote the empty extraposition list by 'nil' (Pereira used \[ \]). The &amp;quot;left-hand side remainder&amp;quot; in a grammar rule (the part after the leading symbol) is converted to an extraposition list in a straightforward way, with one node for each symbol in the remainder. The Context says whether the symbol has a gap preceding it, and the remaining fields of an 'x' node have the obvious meaning. For the rule a,\[b\]...c--&gt; d the extraposition list would be x(nogap,terminal,b,x(gap,nonterminal,c,nil)).</Paragraph>
    <Paragraph position="47"> The right-hand side of an MSG rule is preprocessed to a (simple) list form in the obvious way. Thus, a right-hand side (d,e,f) is converted to the list \[d,e,f\], and a right-hand side with a single element d is converted to the list \[d\].</Paragraph>
    <Paragraph position="48"> As a complete example, the MSG rule a...b:e-p--&gt; \[c\],{d},e is converted to rule (a,x(gap,nonterminal,b,nil),e-p,\[\[c\],{d} ,el). If the MSG rule exhibits no semantic item, then the preprocessor supplies the trivial item e-true.</Paragraph>
    <Paragraph position="49"> The 'rule' forms of the rules in an MSG are stored as assertions in the Prolog data base, to be used by the interpreter. One can understand rule (NT,Ext,Sem,B 1 ) as the assertion: &amp;quot;There is a rule for the non-terminal NT with extraposition list Ext, etc.&amp;quot; The rule preprocessor is listed at the beginning of the Appendix.</Paragraph>
    <Paragraph position="50"> Now let us look at the interpreter itself, which is listed after the preprocessor in the Appendix.</Paragraph>
    <Paragraph position="51"> The top-level procedure is parse (String,NonTerminal,Syn) which takes a String of terminals and attempts to parse it as a phrase of type NonTerminal, with the syntactic structure Syn. We should comment that 'parse' defines a top-down parser.</Paragraph>
    <Paragraph position="52"> This procedure calls the main working procedure prs (BodyList,String,Mods,Par,Mer,Ext) which parses String against a list BodyList of goals of the type that can appear in the right-hand side (the body) of a rule. The list of resulting syntactic structures is Mods (one modifier for each non-trivial expansion of a non-terminal in BodyList). The remaining three arguments of 'prs' are for stacks called the parent stack, the merge stack, and the extraposition list. These are initialized to 'nil' in the call of 'parse' to 'prs'.</Paragraph>
    <Paragraph position="53"> The parent stack serves two purposes. One is to control the recursion in the normal working of the parser. (The parser is much like an interpreter for a programming language - in fact, for a specialized version of Prolog itself.) The other purpose is to provide information for the coordination demon, when it backs up in (part of) the parse history.</Paragraph>
    <Paragraph position="54"> A non-empty parent stack is a term of the form parent (BodyList,Mods,Par) where BodyList is a body list, Mods is a modifier list, and Par is again a parent stack. A new level gets pushed onto the parent stack by the sixth rule for 'prs' and the ancillary procedure 'prspush'. This happens 74 American Journal of Computational Linguistics, Volume 9, Number 2, April-June 1983 Veronica Dahl and Michael C. McCord Treating Coordination in Logic Grammars when 'prs' is looking at a body list of the form \[NTIBL\], where the initial element NT is a non-terminal that can be expanded by a 'rule' entry. If that rule is trivial (if its own body is empty), then no actual push is done, and 'prs' continues with the remaining current body list BL. Otherwise, 'prspush' goes to a lower level, to parse against the body of the expanding rule. The items \[NTIBL\] and Mods from the higher level are saved on the parent stack (Mods is a variable for the remaining modifiers to be found on the higher level).</Paragraph>
    <Paragraph position="55"> Note that the body list \[NTIBL\] saved in the first field of the 'parent' term is more than is needed for managing the recursive return to the higher level.</Paragraph>
    <Paragraph position="56"> Only the remainder, BL, is needed for this, because NT has already been used in the parse. In fact, the rule that pops to the higher level (the eighth rule for 'prs') does ignore NT in doing the pop. The extra information, NT, is saved for the second purpose of the parent stack, the backing up by the coordination demon.</Paragraph>
    <Paragraph position="57"> Before going into the details of coordination, though, let us continue with the description of the &amp;quot;normal&amp;quot; working of the parser.</Paragraph>
    <Paragraph position="58"> In normal parsing, there is exactly one place where a new 'syn' node is added to the MS trees being built. This is in the second rule for 'prspush', which handles non-trivial rule expansions. The addition of this node is in accordance with the definition of modifier structure given in the preceding section.</Paragraph>
    <Paragraph position="59"> The pushing rule of 'prs' (the sixth rule) also manipulates the extraposition stack. The extraposition component of the expanding rule is concatenated onto the front of the main extraposition list (being carried in the last argument of 'prs'). This is analogous to a HOLD operation in ATNs. Of course, if no extraposition is shown in the rule, the extraposition list will remain the same.</Paragraph>
    <Paragraph position="60"> The third and fourth rules for 'prs' handle terminals in the body list. The first of these tries to remove the terminal from the string argument, and the second tries to remove it from the extraposition list (as in a VIR arc for ATNs).</Paragraph>
    <Paragraph position="61"> The seventh 'prs' rule tries to remove a non-terminal from the extraposition list (again, like a VIR arc).</Paragraph>
    <Paragraph position="62"> The last 'prs' rule is the termination condition for the parse. It just requires that all arguments be null. Now we can discuss coordination demons. All the rest of the interpreter rules deal with these.</Paragraph>
    <Paragraph position="63"> The first 'prs' rule is the one that notices demon words D. It calls a procedure 'demon', passing D as the first argument and all the rest of the information it has in other arguments. 'demon' takes control of the rest of the parse. In the listed interpreter there is only one 'demon' rule, one that tests whether D is a conjunction. It does this with the goal conjunction(D,Cat,Sem), which gives the syntactic category Cat for the conjunction D, and the semantic item Sem for a new modifier node to be constructed for the right conjunct. The lexicon contains 'conjunction' entries as assertions. null For understanding what the conjunction demon does, it is best to look at an example, as it would be parsed for the grammar in the Appendix. We will use the specific notation (for variables, etc.) given in the demon rule, and the reader should refer to that rule in the Appendix. It should be borne in mind that Prolog is non-deterministic; we will only state what happens on the successful path through the choices made.</Paragraph>
    <Paragraph position="64"> The example is John saw and Mary heard the train.</Paragraph>
    <Paragraph position="65"> When the demon for 'and' is called, the current body list is BL= \[comps(\[obj-Y\])\[.</Paragraph>
    <Paragraph position="66"> The non-terminal comps(Comps) looks for a list Comps of complements, and in this case there is to be one complement, an object noun phrase. The MS tree constructed so far is</Paragraph>
    <Paragraph position="68"> Here the entry \[ Mods in the last daughter position for the verb phrase indicates further modifiers on that level to be put in the unbound variable Mods. (This is explicitly the same variable 'Mods' used in the demon rule.) Similarly, I Mods2 represents the remaining modifiers for 'sent' node. The variable Mods2 does not appear in the 'demon' rule, but will be referred to below.</Paragraph>
    <Paragraph position="69"> The parent stack Par available to the demon has two levels, and the two body lists are \[verbph(X)\], \[sent\].</Paragraph>
    <Paragraph position="70"> (Recall that we are describing the state of affairs in the successful path through the search space.) The recursive procedure 'backup' is called, which can look any number of levels through the parent stack. It goes to the second level, where the body list is \[sent\]. (Choosing the first level with \[verbph(X)\] would be appropriate for the sentence &amp;quot;John saw and barely heard the train&amp;quot;.) In passing up a level, 'backup' requires that the body list skipped over must be 'satisfied', which means that any pending goals in the body list (members of its tail) are satisfiable by trivial American Journal of Computational Linguistics, Volume 9, Number 2, April-June 1983 75 Veronica Dahl and Michael C. McCord Treating Coordination in Logic Grammars rules. When 'backup' does pass up a level, the modifier list for that level is closed off. Thus Mods in the tree displayed above will be bound to the empty list.</Paragraph>
    <Paragraph position="71"> (There are no more modifiers for that 'verbph' node.) As a single remaining daughter for the level backed up to, a new 'syn' node for the right conjunct is attached by the demon. This means binding the variable Mods2 in the above tree to the list consisting of this node. Now our tree looks like</Paragraph>
    <Paragraph position="73"> The variable Mods0 is to contain the list of modifiers for the conjunction node. This list will turn out to have a single element, a new 'sent' node for the remainder of the sentence, &amp;quot;Mary heard the train&amp;quot;. Backing up to the \[sent\] level makes the non-terminal NT=sent available to the demon, and the parent stack Parl at the \[sent\] level. The demon then continues the parse by calling 'prs' with body list \[NT\]=\[sent\], but with information pushed onto the merge stack. The main item stored on the merge stack is the body list BL=\[comps(\[obj-Y\])\], which was pending at the time of interruption by the conjunction.</Paragraph>
    <Paragraph position="74"> The items Parl, Ext, and of course the old merge stack Mer are also pushed on.</Paragraph>
    <Paragraph position="75"> So now we continue parsing &amp;quot;Mary heard the train&amp;quot;, but with another kind of demon lurking, the interrupted goal BL. The second rule for 'prs' notices this demon. When we are parsing and come to a goal that can be unified with BL, then we can try merging.</Paragraph>
    <Paragraph position="76"> This happens when we are looking for the complements of &amp;quot;heard&amp;quot;. This unification includes the unification of the object variable Y of &amp;quot;saw&amp;quot; with the object variable of &amp;quot;heard&amp;quot;, so that &amp;quot;the train&amp;quot; will logically be the object of &amp;quot;saw&amp;quot; as well as &amp;quot;heard&amp;quot;. The procedure 'cutoff' called by the second 'prs' rule requires that no new unsatisfied goals have developed in parsing the right conjunct (aside from the goal BL to be merged) and also closes off modifier lists in the local parent stack Par for the right conjunct.</Paragraph>
    <Paragraph position="77"> Then the merged parse is continued by a call to 'prs', with BL as goal and with the parent stack, merge stack, and extraposition list popped from the merge stack. When this is completed, our MS tree is as shown in Figure 3.</Paragraph>
    <Paragraph position="78"> The meanings of the semantic items used in this MS tree, and their use in producing the logical form, will be explained in the next section; but it is worth stating now what the resulting logical form is: def (Y,train(Y),saw(john,Y) &amp;heard(mary,Y)).</Paragraph>
    <Paragraph position="79"> The reader may examine the analyses produced for other examples listed in the Appendix.</Paragraph>
    <Paragraph position="81"> The overall idea of the semantic interpretation component was given in the Introduction. The rule system is listed completely in the Appendix. This system is taken essentially from McCord (1981), with some rules deleted (rules dealing with focus), and some rules added for coordination.</Paragraph>
    <Paragraph position="82"> For a discussion of MS tree reshaping as a means of handling scoping of modifiers, we refer to McCord (1982, 1981). Also, the reader may examine the examples of reshaped trees given in the Appendix.</Paragraph>
    <Paragraph position="83"> We will, however, review the second stage of semantic interpretation, because the new rules for coordination are added here and because it is more central for understanding modifier structure. In this stage, the reshaped MS tree is translated to logical form, and the top-level procedure for this is 'translate'. This procedure actually works only with the semantic-item components of MS tree nodes. (Reshaping uses the first, syntactic components.) One semantic item can combine with (or modify) a second semantic item to produce a third semantic item.</Paragraph>
    <Paragraph position="84"> 'translate' uses these combining operations in a straightforward recursive fashion to produce the logical form of an MS tree. The ancillary procedure ('transmod') that actually does the recursion produces complete semantic items as translations, not just logical forms. For the top-level result, the operator component is thrown away. 'transmod' works simply as follows: The daughters (modifiers) of a tree node N are translated recursively (to semantic items) and these items cumulatively modify the semantic item of N, the leftmost acting as the outermost modifier, etc.</Paragraph>
    <Paragraph position="85"> So the heart of the translation process is in the rules that say how semantic items can combine with 76 American Journal of Computational Linguistics, Volume 9, Number 2, April-June 1983 Veronica Dahl and Michael C. McCord Treating Coordination in Logic Grammars other semantic items. These are rules for the procedure null trans(Sem0,Seml,Sem2) which says that Sere0 combines with (modifies) Seml to produce Sem2. In the typical case, this combination depends only on the Operator component of Sem0; but there are exceptional cases where it depends as well on the operator in Seml. Furthermore, 'trans' is free to create a new operator for the result, Sem2, which can affect later operations. This happens with coordinate modifiers. We often speak of Sem0 &amp;quot;operating on&amp;quot; Seml, but &amp;quot;combining with&amp;quot; is the more accurate term generally.</Paragraph>
    <Paragraph position="86"> The only operators appearing in the small sample grammar in the Appendix are of the form g, @P, P/Q, and P*Q. Here P and Q are variables standing for logical forms. The listing for 'trans' in the Appendix includes only rules for these operators and their auxiliaries, although larger grammars involve other operators. We will elucidate the effects of these four operators with examples. The last one, P'Q, is used for coordination.</Paragraph>
    <Paragraph position="87"> The operator 'g' is for left-conjoining. When g-man(X) operates on g-see(X,Y), the result is g-man(X)&amp;see(X,Y).</Paragraph>
    <Paragraph position="88"> The operator @P is used for substitutions in its associated logical form. When @P-not(P) operates on g-laugh(X), the result is g-not(laugh(X)).</Paragraph>
    <Paragraph position="89"> The operator P/Q is used for forms that require two substitutions. When P/Q-each(X,Q,P) operates on g-man(X), the result is @P-each(X,man(X),P), which in turn can operate by substituting for P.</Paragraph>
    <Paragraph position="90"> Notice that @p and P/Q are similar to lambda(P) and lambda(Q)lambda(P) respectively. But they also interact with other operators in the system in specific ways.</Paragraph>
    <Paragraph position="91"> To show these first three operators working together, let us look at the MS tree that would be produced for the sentence &amp;quot;Each man laughed&amp;quot;. (Reshaping leaves this tree unaltered.) We throw away the syntactic fields in the tree nodes (working only with the semantic items), and show the successive stages in producing the logical form in Figure 4. In following the steps in Figure 4, the reader should refer to the 'trans' rules in the Appendix, which are numbered for reference here. In each step of the translation, a node combines with its parent, and the 'trans' rule used to do this is indicated.</Paragraph>
    <Paragraph position="92"> The operator P*Q appears in coordinate modifiers.</Paragraph>
    <Paragraph position="93"> The first four 'trans' rules deal with it, and they create auxiliary operators. The following example will make clear how these are manipulated. The sentence is  This example is shown in the Appendix, with the initial syntactic analysis and the reshaped tree. In the reshaped tree, the 'sent' node has three daughters, the first being for the simple noun phrase &amp;quot;each man&amp;quot;, the second for the conjoined noun phrase &amp;quot;an apple and a pear&amp;quot;, and the third for the verb phrase with the object removed.</Paragraph>
    <Paragraph position="94"> If we perform all the modifications that are possible in this tree without involving the coordination operator, and if we remove the syntactic fields, then the tree looks like the following:  We have saved the modifier for &amp;quot;a pear&amp;quot; in the first argument of the 'cbasel' operator. Next, this item operates on the g-true node, by application of the second 'trans' rule, and we get the tree  Then, as the last step with coordination operators, the fourth 'trans' rule is applied to let the 'cbase2' node operate on the top node of the tree. This involves two recursive calls to 'trans', in which the two conjunct noun phrases operate on the material in the scope of the coordinate node. (In this case, the material in the scope is ate(X,Y).) This material gets duplicated, because of the double application to it. The resulting tree now is g-exists(Y,apple(Y),ate(X,Y))&amp;exists(Y,pear(Y), ate(X,Y)) @P-each(X,man(X),P) Finally, the @P node modifies the top node, and after discarding the operator (an 'g') in the resulting item, we get the logical form each(X,man(X),exists(Y,apple(Y),ate(X,Y)) &amp;exists(Y),pear(Y),ate(X,Y)) ) Near the end of the Introduction, examples were given of two syntactically similar sentences with coordination, for which the produced logical forms are quite different. For the sentence &amp;quot;Each man and each woman ate an apple&amp;quot;, the reshaping stage produces a tree that in outline looks like the following: sent nounph &amp;quot;each man&amp;quot; conj(and) nounph &amp;quot;each woman&amp;quot; nounph &amp;quot;an apple&amp;quot; verbph &amp;quot;ate&amp;quot; Then, the material for &amp;quot;ate an apple&amp;quot; will be in the scope of the conjoined noun phrase and this material gets duplicated, with the resulting logical form being each(X,man(X),exists(Y,apple(Y),ate(X,Y))) &amp;each(X,woman(X),exists(Y,apple(Y),ate(X,Y))).</Paragraph>
    <Paragraph position="95"> On the other hand, for the sentence &amp;quot;A man and a woman sat at each table&amp;quot;, reshaping moves the universally quantified noun phrase to the left of the existentially quantified conjoined noun phrase, and the tree is as follows: sent nounph &amp;quot;each table&amp;quot; nounph &amp;quot;a man&amp;quot; conj(and) nounph &amp;quot;a woman&amp;quot; verbph &amp;quot;sat at&amp;quot; Then the only material in the scope of the conjoined noun phrase is for &amp;quot;sat at&amp;quot;, and only this gets duplicated. (In fact, the scoping is like that for our earlier example, &amp;quot;Each man ate an apple and a pear&amp;quot;.) The complete logical form is each(Y,table(Y), exists(X,man(X),sat at(X,Y)) &amp; exists(X,woman(X),sat_at(X,Y)) ).</Paragraph>
    <Paragraph position="96"> Notice that the logical forms for conjoined phrases in the above analyses share variables. For instance, the same variable X is used in both man(X) and woman(X) in the last analysis. This sharing of variables arises naturally because of the unification of body lists that is performed during parsing by the 'merge' demon. It keeps things straight very nicely, because the shared variables may appear in another predication, like sat_at(X,Y) above, which occurs only once, outside the conjoined phrase, but is related logically to both conjuncts.</Paragraph>
    <Paragraph position="97"> This sharing of variables presents no problems as long as the variables are quantified over (as they are by the existential in the preceding example). But it makes proper nouns less convenient to treat. If coordination were not being considered, it would be convenient to parse proper nouns by the sort of rule listed in Figure 1 in Section 2, where the proper noun gets immediately unified with the variable X appearing in nounph(X). But if such a rule is used with the MSG parser, then a sentence as simple as &amp;quot;John and Mary laughed&amp;quot; will not parse, because the parser attempts to unify the logical subject variable with both 'john' and 'mary'.</Paragraph>
    <Paragraph position="98"> Therefore, as the semantic item for a proper noun N, we use a quantified form, specifically @P-def(X,X=N,P), and this is carried through in most of the processing. However, the procedure 'translate', after it has carried out all the modification, calls a procedure 'simplify' which simplifies the logical form. This gets rid of some unnecessary 'true's and it carries out the substitutions implicit in the proper noun forms, by doing some copying of structures and renaming of variables. 78 American Journal of Computational Linguistics, Volume 9, Number 2, April-June 1983 Veronica Dahl and Michael C. McCord Treating Coordination in Logic Grammars For example, the logical form for &amp;quot;John and Mary laughed&amp;quot; prior to simplification is essentially def(X,X= john,laughed(X)) &amp;def(X,X=mary,laughed(X)).</Paragraph>
    <Paragraph position="99"> But after simplification, it is laughed(john)&amp;laughed(mary).</Paragraph>
    <Paragraph position="100"> In the sample analyses in the Appendix, we give in some cases only the logical form and in other cases the intermediate structures also (the syntactic analysis tree and the reshaped tree). Analysis times are in milliseconds. These do not include times for I/O and conversion of character strings to word lists. Variables are printed by Prolog-10 in the form n, where n is an integer.</Paragraph>
  </Section>
  <Section position="4" start_page="0" end_page="0" type="metho">
    <SectionTitle>
5. Possible Extensions
</SectionTitle>
    <Paragraph position="0"> The main advantages of the formalism presented here are: * automating the treatment of coordination, * freeing the user of concern with structure-building, and * providing a modular treatment of semantics, based upon information given locally in each rule. While making a reasonable compromise between power and elegance on the one hand, and efficiency on the other, our present implementation could be improved in several ways. For instance, because the parsing history is kept in a stack that is regularly popped - the Parent stack - some parsing states are no longer available for backing up to, so the possibility exists for some acceptable sentences not to be recognized. null We have experimented with modifications of the MSG interpreter in which more of the parse history is saved, and have also considered compiling MSGs into Prolog and using a general 'state' predicate which returns the proof history, but we have not as yet obtained satisfactory results along these lines.</Paragraph>
    <Paragraph position="1"> Another possible improvement is to use some semantic guidance for the (at present blind) backing up through parsing states. The parser already carries along semantic information (in semantic items) to be used later on. Some of this information could perhaps also be used during parsing, in order to improve the backup. Research along these lines may well provide some more insight into the dilemma of whether syntax and semantics should be kept separate or intermingled. It would also be interesting to include collective and respective readings of coordinated noun phrases, perhaps along the lines proposed in Dahl (1981).</Paragraph>
    <Paragraph position="2"> We do not presume that our general treatment of coordination will work for all possible MSG grammars. Care is necessary in writing an MSG, as with any other formalism. What we do provide are enough elements to arrive at a grammar definition that can treat most structure-building and coordination problems in a modular and largely automated manner.</Paragraph>
    <Paragraph position="3"> We have also investigated an alternative approach to coordination, which is not metagrammatical but is nevertheless more flexible than previous approaches, and involves still another grammar formalism we believe worth studying in itself. We have named it the gapping grammar (GG) formalism, as its main feature is that it allows a grammar rule to rearrange gaps in a fairly arbitrary fashion. This will be the subject of a forthcoming article.</Paragraph>
  </Section>
class="xml-element"></Paper>