File Information
File: 05-lr/acl_arc_1_sum/cleansed_text/xml_by_section/metho/81/j81-4003_metho.xml
Size: 41,047 bytes
Last Modified: 2025-10-06 14:11:22
<?xml version="1.0" standalone="yes"?> <Paper uid="J81-4003"> <Title>Extraposition Grammars</Title> <Section position="3" start_page="0" end_page="0" type="metho"> <SectionTitle> 2. Grammars in Logic </SectionTitle> <Paragraph position="0"> This section summarises the concepts of definite clause grammars (DCGs), and of the underlying system of logic, definite clauses, needed for the rest of the paper. A fuller discussion can be found elsewhere \[6\].</Paragraph> <Paragraph position="1"> A definite clause has either the form P:-QI,&quot;',Qn&quot; to be read as &quot;P is true if Q 1 ..... Qn are true&quot;, or the form P.</Paragraph> <Paragraph position="2"> to be read as &quot;P is true&quot;. P is the head of the clause, Q1 ..... Qn are goals, forming the body of the clause. The symbols P, Q 1 ..... Qn stand for literals. A literal has a predicate symbol, and possibly some arguments (in parentheses, separated by commas), e.g.</Paragraph> <Paragraph position="3"> father(X,Y) false number(O) A literal is to be interpreted as denoting a relation between its arguments; e.g. &quot;father(X,Y)&quot; denotes the relation 'father' between X and Y.</Paragraph> <Paragraph position="4"> Arguments are terms, standing for partially specified objects. Terms may be * variables, denoting unspecified objects (variable names are capitalised):</Paragraph> </Section> <Section position="4" start_page="0" end_page="0" type="metho"> <SectionTitle> X Case Agreement </SectionTitle> <Paragraph position="0"> * atomic symbols, denoting specific objects: plural \[ \] 3 * compound terms, denoting complex objects: s(NP,VP) succ(succ(O)) A compound term has a functor and some arguments, which are terms. Compound terms are best seen as Copyright 1981 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. A particular type of term, the list, has a simplified notation. The binary functor ' ' makes up non-empty lists, and the atom '\[ \]' denotes the empty list.</Paragraph> <Paragraph position="1"> In the special list notation,</Paragraph> <Paragraph position="3"> Putting these concepts together, the clause grandfather(X,Z) :- father(X,Y), parent(Y,Z).</Paragraph> <Paragraph position="4"> may be read as &quot;X is grandfather of Z if X is father of Y and Y is a parent of Z&quot;; the clause father(john ,mary).</Paragraph> <Paragraph position="5"> may be read as &quot;John is father of Mary&quot; (note the use of lower case for the constants in the clause).</Paragraph> <Paragraph position="6"> A set of definite clauses forms a program. A program defines the relations denoted by the predicates appearing on the head of clauses. When using a definite clause interpreter, such as PROLOG \[9\], a goal statement ?-19 .</Paragraph> <Paragraph position="7"> specifies that the relation instances that match P are required.</Paragraph> <Paragraph position="8"> Now, any context-free rule, such as sentence --> noun_phrase, verb_phrase.</Paragraph> <Paragraph position="9"> (I use ',' for concatenation, and '.' to terminate a rule) may be translated into a definite clause</Paragraph> <Paragraph position="11"> which says: &quot;there is a sentence between points SO and S in a string if there is a noun phrase between points SO and S1, and a verb phrase between points S1 and S&quot;. A context-free rule like determiner--> \[the\].</Paragraph> <Paragraph position="12"> (where the square brackets mark a terminal) can be translated into determiner(SO,S) :- connects(SO,the,S).</Paragraph> <Paragraph position="13"> which may be read as &quot;there is a determiner between points SO and S in a string if SO is joined to S by the word 'the'&quot;. The predicate 'connects' is used to relate terms denoting points in a string to the words which join those points. Depending on the application, different definitions of 'connects' might be used. In particular, if a point in a string is represented by the list of words after that point, 'connects' has the very simple definition connects(\[Word I 53,Word,S).</Paragraph> <Paragraph position="14"> which may be read as &quot;a string point represented by a list of words with first element Word and rest S is connected by the word Word to the string point represented by list S.&quot; DCGs are the natural extension of context-free grammars (CFGs) obtained through the translation into definite clauses outlined above. A DCG non-terminal may have arguments, of the same form as those of a predicate, and a terminal may be any term. For instance, the rule sentence(s(NP,VP)) --> noun_phrase(NP,N), verb_phrase(VP,N).</Paragraph> <Paragraph position="15"> states: &quot;A sentence with structure</Paragraph> <Paragraph position="17"> is made of a noun phrase with structure NP and number N (which can be either 'singular' or 'plural'), followed by a verb phrase with structure VP agreeing with the number N&quot;. A DCG rule is just &quot;syntactic sugar&quot; for a definite clause. The clause for the example above is sentence(s(NP,VP),SO,S) :noun phrase(NP,N,SO,S1), verb_phrase(VP,N,Sl ,S).</Paragraph> <Paragraph position="18"> In general, a DCG non-terminal with n arguments is translated into a predicate of n+2 arguments, the last two of which are the string points, as in the translation of context-free rules into definite clauses.</Paragraph> <Paragraph position="19"> The main idea of DCGs is then that grammar symbols can be general logic terms rather than just atomic symbols. This makes DCGs a general-purpose grammar formalism, capable of describing any type-0 language. The first grammar formalism with logic terms as grammar symbols was Colmerauer's metamorphosis grammars \[2\]. Where a DCG is a CFG with logic terms for grammar symbols, a MG is a somewhat restricted type-0 grammar with logic terms for grammar symbols. However, the very simple translation of DCGs into definite clauses presented above does not carry over directly to MGs.</Paragraph> </Section> <Section position="5" start_page="0" end_page="0" type="metho"> <SectionTitle> 3. Left Extraposition </SectionTitle> <Paragraph position="0"> Roughly speaking, left extraposition occurs in a natural language sentence when a subconstituent of some constituent is missing, and some other constituent, to the left of the incomplete one, represents the missing constituent in some way. It is useful to think that an empty constituent, the trace, occupies the &quot;hole&quot; left by the missing constituent, and that the constituent to the left, which represents the missing part, is a marker, indicating that a constituent to its right contains a trace \[1\]. One can then say that the constituent in whose place the trace stands has been extraposed to the left, and, in its new position, is rep-</Paragraph> <Section position="1" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 244 American Journal of Computational Linguistics, Volume 7, Number 4, October-December 1981 Fernando Pereira Extraposition Grammars </SectionTitle> <Paragraph position="0"> sentence --> noun_phrase, verb phrase.</Paragraph> <Paragraph position="1"> noun_phrase --> proper_noun.</Paragraph> <Paragraph position="2"> noun_phrase --> determiner, noun, relative. noun_phrase --> determiner, noun, prep_phrase. noun_phrase --> trace.</Paragraph> <Paragraph position="3"> trace --> \[ \].</Paragraph> <Paragraph position="4"> verb_phrase --> verb, noun_phrase.</Paragraph> <Paragraph position="5"> verb_phrase --> verb.</Paragraph> <Paragraph position="6"> relative --> \[ \].</Paragraph> <Paragraph position="7"> relative --> rel_pronoun, sentence. prep_phrase --> preposition, noun_phrase. Figure 4.1. CFG for relative clauses.</Paragraph> <Paragraph position="9"> resented by the marker. For instance, relative clauses are formed by a marker, which in the simpler cases is just a relative pronoun, followed by a sentence where some noun phrase has been replaced by a trace. This is represented in the following annotated surface structure: null The man that/ \[sdohn met t i\] is a grammarian.</Paragraph> <Paragraph position="10"> In this example, t stands for the trace, 'that' is the surface form of the marker, and the connection between the two is indicated by the common index i.</Paragraph> <Paragraph position="11"> The concept of left extraposition plays an essential role, directly or indirectly, in many formal descriptions of relative and interrogative clauses. Related to this concept, there are several &quot;global constraints&quot;, the &quot;island constraints&quot;, that have been introduced to restrict the situations in which left extraposition can be applied. For instance, the Ross complex-NP constraint \[8\], implies that any relative pronoun occurring outside a given noun phrase cannot be bound to a trace occurring inside a relative clause which is a sub-constituent of the noun phrase. This means that it is not possible to have a configuration like Xl &quot;&quot; \[np &quot;'&quot; \[rel X2 \[s &quot;'&quot; t2 &quot;'&quot; tl &quot;'&quot; 3\] &quot;'&quot; \] Note that here I use the concept of left extraposition in a loose sense, without relating it to transformations as in transformational grammar. In XGs, and also in other formalisms for describing languages (for instance the context-free rule schemas of Gazdar \[5\]), the notion of transformation is not used, but a conceptual operation of some kind is required for instance to relate a relative pronoun to a &quot;hole&quot; in the structural representation of the constituent following the pronoun. null</Paragraph> </Section> </Section> <Section position="6" start_page="0" end_page="0" type="metho"> <SectionTitle> 4. Limitations of Other Formalisms </SectionTitle> <Paragraph position="0"> To describe a fragment of language where left extraposition occurs, one might start with a CFG which gives a rough approximation of the fragment. The grammar may then be refined by adding arguments to full sentence --> sentence(nil).</Paragraph> <Paragraph position="2"> determiner, noun, relative.</Paragraph> <Paragraph position="3"> noun_phrase(HoleO,Hole) --> determiner, noun, prep_phrase(HoleO,Hole).</Paragraph> <Paragraph position="5"> preposition, noun_phrase(HoleO,Hole).</Paragraph> <Paragraph position="6"> Figure 4.2. DCG for relative clauses.</Paragraph> <Paragraph position="7"> (2) non-terminals, to carry extraposed constituents across phrases. This method is analogous to the introduction of &quot;derived&quot; rules by Gazdar \[5\]. Take for example the CFG in Figure 4.1. In this grammar it is possible to use rule (1) to expand a noun phrase into a trace, even outside a relative clause. To prevent this, I will add arguments to all non-terminals from ~vhich a noun phrase might be extraposed. The modified grammar, now a DCG, is given in Figure 4.2. A variable 'Hole...' will have the value 'trace' if an extraposed noun phrase occurs somewhere to the right, 'nil' otherwise. The parse tree of Figure 4.3 shows the variable values when the grammar of Figure 4.2 is used to analyse the noun phrase &quot;the man that John met&quot;. Intuitively, we either can see noun phrases moving to the left, leaving traces behind, or traces appearing from markers and moving to the right. In a phrase &quot;noun phrase(Holel,Hole2)&quot;, Holel will have the value 'trace' when a trace occurs somewhere to the right of the left end of the phrase. In that case, Hole2 will be 'nil' if the noun phrase contains the trace, 'trace' if the trace appears to the right of the right end of this noun phrase. Thus, rule (2) in Figure 4.2 specifies that a noun phrase expands into a trace if a trace appears from the left, and as this trace is now placed, it will not be found further to the right.</Paragraph> <Paragraph position="8"> The non-terminal 'relative' has no arguments, because the complex-NP constraint prevents noun phrases from moving out of a relative clause. However, that constraint does not apply to prepositional phrases, so 'prepphrase' has arguments. The non-terminal 'sentence' (and consequently 'verb phrase') has a single argument, because in a relative clause the trace must occur in the sentence immediately to the right of the relative pronoun.</Paragraph> <Paragraph position="9"> It is obvious that in a more extensive grammar, many non-terminals would need extraposition arguments, and the increased complication would make the grammar larger and less readable.</Paragraph> <Paragraph position="10"> Colmerauer's MG formalism allows an alternative way to express left extraposition. It involves the use of rules whose left-hand side is a non-terminal followed by a string of &quot;dummy&quot; terminal symbols which do not occur in the input vocabulary. An example of such a rule is: rel_marker, \[t\] --> rel_pronoun.</Paragraph> <Paragraph position="11"> Its meaning is that 'rel pronoun' can be analysed as a 'rel marker' provided that the terminal 't' is added to the front of the input remaining after the rule application. Subsequent rule applications will have to cope explicitly with such dummy terminals. This method has been used in several published grammars \[2, 4, 7\], but in a large grammar it has the same (if not worse) problems of size and clarity as the previous method.</Paragraph> <Paragraph position="12"> It also suffers from a theoretical problem: in general, the language defined by such a grammar will contain extra sentences involving the dummy terminals. For parsing, however, no problem arises, because the input sentences are not supposed to contain dummy terminals. These inadequacies of MGs were the main motivation for the development of XGs.</Paragraph> </Section> <Section position="7" start_page="0" end_page="0" type="metho"> <SectionTitle> 5. Informal Description of XGs </SectionTitle> <Paragraph position="0"> To describe left extraposition, we need to relate non-contiguous parts of a sentence. But neither DCGs nor MGs have means of representing such a relationship by specific grammar rules. Rather; the relationship can only be described implicitly, by adding extra information to many unrelated rules in the grammar.</Paragraph> <Paragraph position="1"> That is, one cannot look at a grammar and find a set of rules specific to the constructions which involve left extraposition.</Paragraph> <Paragraph position="2"> With extraposition grammars, I attempt to provide a formalism in which such rules can be written.</Paragraph> <Paragraph position="3"> In this informal introduction to the XG formalism, I will avoid the extra complications of non-terminal arguments. So, in the discussion that follows, we may look at XGs as an extension of CFGs.</Paragraph> <Paragraph position="4"> Sometimes it is easier to look at grammar rules in the left-to-right, or synthesis, direction. I will say then that a rule is being used to expand or rewrite a string. In other cases, it is easier to look at a rule in the rightto-left, or analysis, direction. I will say then that the rule is being used to analyse a string.</Paragraph> <Paragraph position="5"> Let us first look at the following XG fragment: sentence --> noun_phrase, verb_phrase.</Paragraph> <Paragraph position="6"> noun phrase --> determiner, noun, relative.</Paragraph> <Paragraph position="7"> noun_phrase --> trace.</Paragraph> <Paragraph position="8"> relative --> \[ \].</Paragraph> <Paragraph position="9"> relative --> rel marker, sentence.</Paragraph> <Paragraph position="10"> rel_marker ... trace --> rel_pronoun.</Paragraph> <Paragraph position="11"> All rules but the last are context-free. The last rule ~xpresses the extraposition in simple relative clauses. It states that a relative pronoun is to be analysed as a marker, followed by some unknown constituents (denoted by '...'), followed by a trace. This is shown in Figure 5.1. As in the DCG example of the previous section, the extraposed noun phrase is expanded into a trace. However, instead of the trace being rewritten into the empty string, the trace is used as part of the analysis of 'rel marker'.</Paragraph> <Paragraph position="12"> The difference between XG rules and DCG rules is then that the left-hand side of an XG rule may contain several symbols. Where a DCG rule is seen as expressing the expansion of a single non-terminal into a string, an XG rule is seen as expanding together several non-contiguous symbols into a string. More precisely, an XG rule has the general form s 1 ...s 2 etc. Sk_ 1 ...s k --> r. (3) Here each segment s i (separated from other segments by '...') is a sequence of terminals and non-terminals (written in DCG notation, with ',' for concatenation). The first symbol in s 1, the leading symbol, is restricted to be a non-terminal. The right-hand side r is as in a DCG rule.</Paragraph> <Paragraph position="13"> Leaving aside the constraints discussed in the next section, the meaning of a rule like (3) is that any sequence of symbols of the form SlXqS2X 2 etc. sk_qXk_lS k with arbitrary xi's, can be rewritten into rxqx2...x k_ 1. Thinking procedurally, one can say that a non-terminal may be expanded by matching it to the leading symbol on the left-hand side of a rule, and the rest of the left-hand side is &quot;put aside&quot; to wait for the derivation of symbols which match each of its symbols in sequence. This sequence of symbols can be interrupted by arbitrary strings, paired to the occurrences of '...' on the left-hand side of the rule.</Paragraph> </Section> <Section position="8" start_page="0" end_page="0" type="metho"> <SectionTitle> 6. XG Derivations </SectionTitle> <Paragraph position="0"> When several XG rules are involved, the derivation of a surface string becomes more complicated than in the single rule example of the previous section, because rule applications interact in the way now to be described.</Paragraph> <Paragraph position="1"> To represent the intermediate stages in an XG derivation, I will use bracketed strings, made up of A bracketed string is balanced if the brackets in it balance in the usual way.</Paragraph> <Paragraph position="2"> Now, an XG rule u 1 ...u 2. .. etc .... u n --> v.</Paragraph> <Paragraph position="3"> can be applied to bracketed string s if s = xOUlXlU 2 etc. Xn_qUnX n and each of the gaps x 1 ..... Xn-1 is balanced. The substring of s between x 0 and x n is the span of the rule application. The application rewrites s into new string t, replacing Ul by v followed by n-1 open brackets, and replacing each of u 2 ..... u n by a close bracket; in short, s is replaced by x0v<< ... <x 1>x2> ... Xn_ l>x n The relation between the original string s and the derived string t is abbreviated as s => t. In the new string t, the substring between x 0 and x n is the result of the application. In particular, the application of a rule with a single segment in its left-hand side is no different from what it would be in a type-0 grammar. Taking again the rule rel_marker ... trace --> rel_pronoun.</Paragraph> <Paragraph position="4"> its application to rel marker John likes trace produces rel_pronoun < John likes > After this rule application, it is not possible to apply any rule with a segment matching inside a bracketed portion and another segment matching outside it. The use of the above rule has divided the string into two isolated portions, each of which must be independently expanded.</Paragraph> <Paragraph position="5"> Given an XG with initial symbol s, a sentence t is in the language defined by the XG if there is a se- null quence of rule applications that transforms s into a string from which t can be obtained by deleting all brackets.</Paragraph> <Paragraph position="6"> I shall refer to the restrictions on XG rule application which I have just described as the bracketing constraint. The effect of the bracketing constraint is independent of the order of application of rules, because if two rules are used in a derivation, the brackets introduced by each of them must be compatible in the way described above. As brackets are added and never deleted, it is clear that the order of application is irrelevant. For similar reasons, any two applications in a derivation where the rules involved have more than one segment in their left-hand sides, one and only one of the two following situations arises: * the span of neither application intersects the result of the other; * the result of one of the applications is contained entirely in a gap of the other application - the applications are nested.</Paragraph> <Paragraph position="7"> If one follows to the letter the definitions in this section, then checking, in a parsing procedure, whether an XG rule may be applied, would require a scan of the whole intermediate string. However, we will see in Section 10 that this check may be done &quot;on the fly&quot; as brackets are introduced, with a cost independent of the length of the current intermediate string in the derivation.</Paragraph> <Paragraph position="8"> 7. Derivation Graphs In the same way as parse trees are used to visualise context-free derivations, I use derivation graphs to represent XG derivations.</Paragraph> <Paragraph position="9"> In a derivation graph, as in a parse tree, each node corresponds to a rule application or to a terminal symbol in the derived sentence, and the edges leaving a node correspond to the symbols in the right-hand side of that node's rule. In a derivation graph, however, a node can have more than one incoming edge - in fact, one such edge for each of the symbols on the left-</Paragraph> <Section position="1" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 248 American Journal of Computational Linguistics, Volume 7, Number 4, October-December 1981 Fernando Pereira Extraposition Grammars </SectionTitle> <Paragraph position="0"> hand side of the rule corresponding to that node. Of these edges, only the one corresponding to the leading symbol is used to define the left-to-right order of the symbols in the sentence whose derivation is represented by the graph. If one deletes from a derivation graph all except the first of the incoming edges to every node, the result is a tree analogous to a parse tree.</Paragraph> <Paragraph position="1"> For example, Figure 7.1 shows the derivation graph for the string &quot;aabbcc&quot; according to the XG: S --> as, bs, cs.</Paragraph> <Paragraph position="2"> as --> \[ \].</Paragraph> <Paragraph position="3"> as ... xb --> \[a\], as.</Paragraph> <Paragraph position="4"> bs --> \[ \].</Paragraph> <Paragraph position="5"> bs ... xc --> xb, \[b\], bs.</Paragraph> <Paragraph position="6"> cs --> \[ \].</Paragraph> <Paragraph position="7"> CS --> XC, \[C\], CS.</Paragraph> <Paragraph position="8"> This XG defines the language formed by the set of all strings anbncn for n_> 0.</Paragraph> <Paragraph position="9"> The example shows, incidentally, that XGs, even without arguments, are strictly more powerful than CFGs, since the language described is not context-free. The topology of derivation graphs reflects clearly the bracketing constraint. Assume the following two conventions for the drawing of a derivation graph, which are followed in all the graphs shown here: * the edges entering a node are ordered clockwise following the sequence of the corresponding symbols in the left-hand side of the rule for that node; * the edges issuing from a node are ordered counterclockwise following the sequence of the corresponding symbols in the right-hand side of the rule for the node.</Paragraph> <Paragraph position="10"> Then the derivation graph obeys the bracketing constraint if and only if it can be drawn, following the conventions, without any edges crossing. 1 The example of Figure 7.2 shows this clearly. In this figure, the closed path formed by edges 1, 2, 3, and 4 has the same effect as a matching pair of brackets in a bracketed string.</Paragraph> <Paragraph position="11"> It is also worth noting that nested rule applications appear in a derivation graph as a configuration like the one depicted in Figure 7.3.</Paragraph> <Paragraph position="12"> 8. XGs and Left Extraposition We saw in Figure 4.2 a DCG for (some) relative clauses. The XG of Figure 8.1 describes essentially the same language fragment, showing how easy it is to describe left extraposition in an XG. In that grammar, The mouse that the cat chased squeaks.</Paragraph> <Paragraph position="13"> has the derivation graph shown in Figure 8.2. The left extraposition implicit in the structure of the sentence is represented in the derivation graph by the applica-</Paragraph> <Paragraph position="15"> tion of the rule for 'rel__marker', at the node marked (*) in the figure. One can say that the left extraposition has been &quot;reversed&quot; in the derivation by the use of this rule, which may be looked at as repositioning 'trace' to the right, thus &quot;reversing&quot; the extraposition of the original sentence.</Paragraph> <Paragraph position="16"> In the rest of this paper, I often refer to a constituent being repositioned into a bracketed string (or into a fragment of derivation graph), to mean that a rule having that constituent as a non-leading symbol in the left-hand side has been applied, and the symbol matches some symbol in the string (or corresponds to some edge in the fragment). For example, in Figure 8.2 the trace 't' is repositioned into the subgraph with root 's'.</Paragraph> <Paragraph position="17"> 9. Using the Bracketing Constraint In the example of Figure 8.2, there is only one application of a non-DCG rule, at the place marked (*). However, we have seen that when a derivation contains several applications of such rules, the applications must obey the bracketing constraint. The use of the constraint in a grammar is better explained with an example. From the sentences The mouse squeaks.</Paragraph> <Paragraph position="18"> The cat likes fish.</Paragraph> <Paragraph position="19"> The cat chased the mouse.</Paragraph> <Paragraph position="20"> the grammar of Figure 8.1 can derive the following string, which violates the complex-NP constraint: * The mouse that the cat that chased likes fish squeaks. The derivation of this ungrammatical string can be better understood if we compare it with a sentence outside the fragment: The mouse, that the cat which chased it likes fish, squeaks.</Paragraph> <Paragraph position="21"> where the pronoun 'it' takes the place of the incorrect trace.</Paragraph> <Paragraph position="22"> The derivation graph for that un-English string is shown in Figure 9.1. In the graph, (*) and (**) mark two nested applications of the rule for 'rel marker'. The string is un-English because the higher 'relative' (marked (+) in the graph) binds a trace occurring inside a sentence which is part of the subordinated 'noun___.phrase' (+ +).</Paragraph> <Paragraph position="23"> Now, using the bracketing constraint one can neatly express the complex-NP constraint. It is only necessary to change the second rule for 'relative' in Figure</Paragraph> </Section> <Section position="2" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 8.1 to </SectionTitle> <Paragraph position="0"> relative --> open, rel_marker, sentence, close. (5) and add the rule open ... close --> \[ \]. (6) With this modified grammar, it is no longer possible to violate the complex-NP constraint, because no constituent can be repositioned from outside into the gap created by the application of rule (6) to the result of applying the rule for relatives (5).</Paragraph> <Paragraph position="1"> The non-terminals 'open' and 'close' bracket a sub-derivation null ... open X close ... => < X > ...</Paragraph> <Paragraph position="2"> preventing any constituent from being repositioned from outside that subderivation into it. Figure 9.2 shows the use of rule (6) in the derivation of the sentence null The mouse that the cat that likes fish chased squeaks. This is based on the same three simple sentences as the ungrammatical string of Figure 9.1, which the reader can now try to derive in the modified grammar, to see how the bracketing constraint prevents the derivation. null 10. XGs as Logic Programs In the previous sections, I avoided the complication of non-terminal arguments. Although it would be possible to describe fully the operation of XGs in terms of derivations on bracketed strings, it is much simpler to complete the explanation of XGs using the translation of XG rules into definite clauses. In fact, a rigorous definition of XGs independently of definite clauses would require a formal apparatus very similar to the one needed to formalise definite clause programs in the first place, and so it would fall outside the scope of the present paper. The interested reader will find a full discussion of those issues in two articles by Colmerauer \[2,3\].</Paragraph> <Paragraph position="3"> Like a DCG, a general XG is no more than a convenient notation for a set of definite clauses. An XG non-terminal of arity n corresponds to an n+4 place predicate (with the same name). Of the extra four arguments, two are used to represent string positions as in DCGs, and the other two are used to represent positions in an extraposition list, which carries symbols to be repositioned.</Paragraph> <Paragraph position="4"> Each element of the extraposition list represents a symbol being repositioned as a 4-tuple x(context, type, symbol, xlist) where context is either 'gap', if the symbol was preceded by '...' in the rule where it originated, or 'nogap', if the symbol was preceded by ','; type may be 'terminal' or 'nonterminal', with the obvious meaning; symbol is the symbol proper; xlist is the remainder of the extraposition list (an empty list being represented by '\[ \]').</Paragraph> </Section> <Section position="3" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 252 American Journal of Computational Linguistics, Volume 7, Number 4, October-December 1981 Fernando Pereira Extraposition Grammars </SectionTitle> <Paragraph position="0"> An XG rule is translated into a clause for the predicate corresponding to the leading symbol of the rule.</Paragraph> <Paragraph position="1"> In the case where the XG rule has just a single symbol on the left-hand side, the translation is very similar to that of DCG rules. For example, the rule sentence --> noun_phrase, verbphrase.</Paragraph> <Paragraph position="2"> translates into</Paragraph> <Paragraph position="4"> verb_phrase(S1 ,S,Xl ,X).</Paragraph> <Paragraph position="5"> A terminal t in the right-hand side of a rule translates into a call to the predicate 'terminal', defined below, whose role is analogous to that of 'connects' in DCGs. For example, the rule rel_pronoun --> \[that\] .</Paragraph> <Paragraph position="6"> translates into re\]_pronoun (S0,S,X0,X) :terminal (that ,SO ,S ,XO ,X ).</Paragraph> <Paragraph position="7"> The translation of a rule with more than one symbol in the left-hand side is a bit more complicated. Informally, each symbol after the first is made into a 4-tuple as described above, and fronted to the extraposition list. Thus, for example, the rule rel_marker ... trace --> rel_pronoun.</Paragraph> <Paragraph position="8"> translates into rel_marker(SO,S,XO,x(gap,nonterminal ,trace,X)) :rel_pronoun ( SO, S, XO, X ).</Paragraph> <Paragraph position="9"> Furthermore, for each distinct non-leading non-terminal nt (with arity n) in the left-hand side of a rule of the XG, the translation includes the clause n/(Vl ..... Vn,S,S,XO,X) :virtual (n/(Vl ..... Vn) ,XO,X).</Paragraph> <Paragraph position="10"> where 'virtual(C,X0,X)', defined later, can be read as &quot;C is the constituent between X0 and X in the extraposition list&quot;, and the variables Vi transfer the arguments of the symbol in the extraposition list to the predicate which translates that symbol.</Paragraph> <Paragraph position="11"> For example, the rule marker(Var), \[the\] ... \[of.whom\], trace(Var) --> \[whose\].</Paragraph> <Paragraph position="12"> which can be used in a more complex grammar of relative clauses to transform &quot;whose X&quot; into &quot;the X of whom&quot;, corresponds to the clauses: marker(Var,SO,S,XO, x ( nogap, terminal, the, x(gap,terminal ,of, x(nogap ,terminal ,whom, x(nogap,nonterminal ,trace(Var),</Paragraph> <Paragraph position="14"> termi hal (whose ,SO, S ,XO, X ).</Paragraph> <Paragraph position="15"> trace(Var,S,S,XO,X) :- virtual(trace(Var),XO,X). Finally, the two auxiliary predicates 'virtual' and 'terminal' are defined as follows:virtual(NT, x(C,nonterminal,NT,X), X).</Paragraph> <Paragraph position="16"> terminal(T, SO, S, X, X) :gap(X), connects(SO, T, S).</Paragraph> <Paragraph position="17"> terminal(T, S, S, x(C,terminal,T,X), X).</Paragraph> <Paragraph position="18"> gap(x(gap,T,S,X)).</Paragraph> <Paragraph position="19"> gap(\[ \]).</Paragraph> <Paragraph position="20"> where 'connects' is as for DCOs.</Paragraph> <Paragraph position="21"> These definitions need some comment. The first clause for 'terminal' says that, provided the current extraposition list allows a gap to appear in the derivation, terminal symbol T may be taken from the position SO in the source string, where T connects SO to some new position S. The second clause for 'terminal' says that if the next symbol in the current extraposition list is a terminal T, then this symbol can be taken as if it occurred at S in the source string. The clause for 'virtual' allows a non-terminal to be &quot;read off from&quot; the extraposition list.</Paragraph> <Paragraph position="22"> rules into definite clauses. Points on the sentence are labelled as follows: American Journal of Computational Linguistics, Volume 7, Number 4, October-December 1981 253</Paragraph> </Section> <Section position="4" start_page="0" end_page="0" type="sub_section"> <SectionTitle> Fernando Pereira Extraposition Grammars </SectionTitle> <Paragraph position="0"> the mouse that the cat that likes fish chased squeaks I 2 3 4 5 6 7 8 9 10 11 The nodes of the analysis fragment, for the relative clause &quot;that likes fish&quot;, are represented by the corresponding goals, indented in proportion to their distance from the root of the graph. The following conventions are used to simplify the figure: * The leaves (terminals) of the graph are listed directly; * the values of the extraposition arguments are explictly represented only for those goals that add or delete something to the extraposition list; for the other goals, the two identical values are represented by the variable 'X'; * the goals for 'terminal' and 'virtual' are left out as they can be easily reconstructed from the other goals and the definitions above; * 'nonterminal' is abbreviated as 'nt'.</Paragraph> <Paragraph position="1"> The definite clause program corresponding to the grammar for this example is listed in Appendix II. The example shows clearly how the bracketing constraint works. Symbols are placed in the extraposition list by rules with more than one symbol in the left-hand side, and removed by calls to 'virtual', on a first-in-last-out basis; that is, the extraposition list is a stack. But this property of the extraposition list is exactly what is needed to balance &quot;on the fly&quot; the auxiliary brackets in the intermediate steps of a derivation. null Being no more than a logic program, an XG can be used for analysis and for synthesis in the same way as a DCG. For instance, to determine whether a string s with initial point initial and final point final is in the language defined by the XG of Figure 8.1, one tries to prove the goal statement ?-sentence(initial, final,\[ 3,\[ 3).</Paragraph> <Paragraph position="2"> As for DCGs, the string s can be represented in several ways. If it is represented as a list, the above goal would be written ?-sentence(s,\[ \],\[ \],\[ \]).</Paragraph> <Paragraph position="3"> The last two arguments of the goal are '\[ \]' to mean that the overall extraposition list goes from '\[ \]' to '\[ \]'; i.e., it is the empty list. Thus, no constituent can be repositioned into or out of the top level 'sentence'. 11. Conclusions and Further Work In this paper I have proposed an extension of DCGs. The motivation for this extension was to provide a simple formal device to describe the structure of such important natural language constructions as relative clauses and interrogative sentences. In transformational grammar, these constructions have usually been analysed in terms of left extraposition, together with global constraints, such as the complex-NP constraint, which restrict the range of the extraposition. Global constraints are not explicit in the grammar rules, but are given externally to be enforced across rule applications. These external global constraints cause theoretical difficulties, because the formal properties of the resulting systems are far from evident, and practical difficulties, because they lead to obscure grammars and prevent the use of any reasonable parsing algorithm. null DCGs, although they provide the basic machinery for a clear description of languages and their structures, lack a mechanism to describe simply left extraposition and the associated restrictions. MGs can express the rewrite of several symbols in a single rule, but the symbols must be contiguous, as in a type-0 grammar rule. This is still not enough to describe left extraposition without complicating the rest of the grammar. XGs are an answer to those limitations.</Paragraph> <Paragraph position="4"> An XG has the same fundamental property as a DCG, that it is no more than a convenient notation for the clauses of an ordinary logic program. XGs and their translation into definite clauses have been designed to meet three requirements: (i) to be a principled extension of DCGs, which can be interpreted as a grammar formalism independently of its translation into definite clauses; (ii) to provide for simple description of left extraposition and related restrictions; (iii) to be comparable in efficiency with DCGS when executed by PROLOG. It turns out that these requirements are not contradictory, and that the resulting design is extremely simple. The restrictions on extraposition are naturally expressed in terms of scope, and scope is expressed in the formalism by &quot;bracketing out&quot; sub-derivations corresponding to balanced strings. The notion of bracketed string derivation is introduced in order to describe extraposition and bracketing independently of the translation of XGs into logic programs. null Some questions about XGs have not been tackled in this paper. First, from a theoretical point of view it would be necessary to complete the independent characterisation of XGs in terms of bracketed strings, and show rigorously that the translation of XGs into logic programs correctly renders this independent characterisation of the semantics of XGs. As pointed out before, this formalisation does not offer any substantial problems.</Paragraph> <Paragraph position="5"> Next, it is not clear whether XGs are as general as they could be. For instance, it might be possible to extend them to handle right extraposition of constituents, which, although less common than left extraposition, can be used to describe quite frequent English constructions, such as the gap between head noun and relative clause in: What files are there that were created today?</Paragraph> </Section> <Section position="5" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 254 American Journal of Computational Linguistics, Volume 7, Number 4, October-December 1981 Fernando Pereira Extraposition Grammars </SectionTitle> <Paragraph position="0"> It may however be possible to describe such situations in terms of left extraposition of some other constituent (e.g. the verb phrase &quot;are there&quot; in the example above).</Paragraph> <Paragraph position="1"> Finally, I have been looking at what transformations should be applied to an XG developed as a clear description of a language, so that the resulting grammar could be used more efficiently in parsing. In particular, I have been trying to generalise results on deterministic parsing of context-free languages into appropriate principles of transformation.</Paragraph> </Section> </Section> class="xml-element"></Paper>