File Information
File: 05-lr/acl_arc_1_sum/cleansed_text/xml_by_section/metho/87/p87-1013_metho.xml
Size: 5,627 bytes
Last Modified: 2025-10-06 14:12:03
<?xml version="1.0" standalone="yes"?> <Paper uid="P87-1013"> <Title>Xerox PARC</Title> <Section position="4" start_page="93" end_page="93" type="metho"> <SectionTitle> 4 Modeling Relational Grammar </SectionTitle> <Paragraph position="0"> Consider the relational analyses in Figures 4 and 5.</Paragraph> <Paragraph position="1"> These analyses, taken from \[7\], have much in common with functional analyses and also with transsformational ones. The present pair of networks illustrates a kind of raising construction common in the relational literature.</Paragraph> <Paragraph position="2"> In Figure 4, there are arc labels P, I, and 2, representing &quot;predicate&quot;, &quot;subject&quot;, and &quot;object&quot; relations. The &quot;cl&quot; indicates that this analysis is at the first linguistic stratum, roughly like a transformational cycle. In Figure 5, we learn that at the second stratum, the predicate (&quot;believed&quot;) is the same as at stratum i, as is the subject. However, the object at level 2 is now &quot;John&quot;, and the phrase &quot;John killed the farmer&quot; has become a &quot;chSmeur&quot; for level 2.</Paragraph> <Paragraph position="3"> The relational network is almost itself a feature structure. To make it one, we employ the trick of introducing an arc labeled with l, standing for &quot;previous level&quot;. The conditions relating the two levels can easily be stated as path equations, as in Figure 6.</Paragraph> <Paragraph position="4"> The dotted lines in Figure 6 indicate that the nodes they connect are actually identical. We can now indicate precisely other information which might be specified in a relational grammar, such as the ordering information I < P < 2. This would apply to the &quot;top level&quot;, which for Perlmutter and Postal would be the &quot;final level&quot;, or surface level. A recursive specification would also become possible: thus l : 2 : CLAUSE A (equations in (6)) RAISE ::= This is obviously an incomplete grammar, but we think it possible to use this notation to give a complete specification of an RG and, perhaps at some stage, a computational test.</Paragraph> </Section> <Section position="5" start_page="93" end_page="93" type="metho"> <SectionTitle> 5 Undecidability </SectionTitle> <Paragraph position="0"> In this section we show that the problem of sa(is/iability - given a formula, decide if there is an f-structure satisfying it - is undecidable. We do this by building a formula which describes the computations of a given Turing machine. In fact, we show how to speak about the computations of an automaton with one stack (a pushdown automaton.) This is done for convenience; although the halting problem for one-stack automata is decidable, it will be clear from the construction that the computation of a two-stack machine could be simulated as well. This model is equivalent to a Turing machine - one stack represents the tape contents to the left of the TM head, and the other, the tape contents to the right. We need not simulate moves which read input, because we imagine the TM started with blank tape. The halting problem for such machines is still undecidable.</Paragraph> <Paragraph position="1"> We make the following conventions about our PDA.</Paragraph> <Paragraph position="2"> Moves are of two kinds: * qi : push b; go to qj ; * qi : pop stack; if a go to qj else go to qk.</Paragraph> <Paragraph position="3"> The machine has a two-character stack alphabet {a, b}.</Paragraph> <Paragraph position="4"> (In the push instruction, of course pushing &quot;a&quot; is allowed.) If the machine attempts to pop an empty stack, it cannot continue. There is one final state qf. The machine halts sucessfully in this and only this state. We reduce the halting problem for this machine to the satisfiability problem for our logic.</Paragraph> <Paragraph position="5"> Atoms: &quot;none ..... bookkeeping marker for telling what is in the stack qO, ql ..... qn--- one for each state Labels: a, b --- for describing stack contents s -- pointer to top of stack next --- value of next state p --- pointer to previous</Paragraph> </Section> <Section position="6" start_page="93" end_page="94" type="metho"> <SectionTitle> INIT0 FINAL --confi~trations </SectionTitle> <Paragraph position="0"> at start and finish QO ..... QN: property of being in one of these states The simulation proceeds as in the relational grammar example. Each configuration of the stack corresponds to a level in an RG derivation. Initially, the stack is empty. Thus we put Next, we show how configurations are updated, depending on the move rules. If qPS is push b; go to qj, then we write QI ::=nex~:qjAp:next:qiAs:a:noneAsb=ps. The last clause tells us that the current stack contents, after finding a %&quot; on top, is the same as the previous contents. The %: none&quot; clause guarantees that only a %&quot; is found on the DG representing the stack. The second clause enforces a consistent state transition from the previous configuration, and the first clause says what the next state should be.</Paragraph> <Paragraph position="1"> If qPS is pop stack; if a go to qj else go to qk, then we write the following.</Paragraph> <Paragraph position="2"> We take QF as the &quot;distinguished predicate&quot; of our scheme.</Paragraph> <Paragraph position="3"> It should be clear that this formula, which is a big where-formula, is satisfiable if\[&quot; the machine reaches state qf.</Paragraph> </Section> class="xml-element"></Paper>