<?xml version="1.0" standalone="yes"?>
<Paper uid="C94-1064">
  <Title>PARSING AS TREE TRAVERSAL</Title>
  <Section position="4" start_page="0" end_page="396" type="metho">
    <SectionTitle>
TREE TRAVERSAL
PRO G RAM S
</SectionTitle>
    <Paragraph position="0"> Following O'Keefe \[8\], we can implement i)reorder, postorder and inorder tree tra.versals as I)CCs, which will then 1)e converted directly into top-down \])otl.om-u 1) and heft-corner l)arsers, respectively. The general schema is: x ._o r d e r('\]'t'ee) --* (x_ordered node labels in Tree).</Paragraph>
    <Paragraph position="1"> Note tha.t in this case, since we are most likely to call x_order with the Tree va.riable instantiated, we are using the DCG in generation mode rather tha.n as a parser. When used as a parser  on the stringlS , the procedure will return all trees whose x_order traw~rsal produces S. The three, instantiations of this procedure are as \['ollows:</Paragraph>
    <Paragraph position="3"> in(Right).</Paragraph>
  </Section>
  <Section position="5" start_page="396" end_page="397" type="metho">
    <SectionTitle>
2.1 DIRECT ENCODING OF
PARSING STRATEGIES
</SectionTitle>
    <Paragraph position="0"> Analogous to these three tl'aversal programs, there are three parsing stragegies, which differ from the tree traversal programs in only two respects. First, the base case for a parser should be to parse a lexical item rathe,: than to parse an empty string. And second, in the recursive clauses, the mother care.gory fits into the parse tree and is licensed by the auxiliary predicate rule/3 but it does not figure into the string that is parsed.</Paragraph>
    <Paragraph position="1"> As was the case for the three tree traversal programs, the three parsers differ from each other only with respect to the right hand side order. \])'or simplicity, I assume that phrase structure rules are binary branching, though the approach can easily be generalized to non-bi uary branching. 1</Paragraph>
    <Paragraph position="3"> ic (Right).</Paragraph>
    <Paragraph position="4"> iks seen here the on\]y difference between the t\]lree strategies concerns |,he. choice of when to select a phrase structure rule. 2 Do you start with a. rule and then try to satisfy it as iu the top-down apl~roa.ch , or do you parse the (laught(ers of a. rule. first before selecting the rule as in the bottom-up approach, or do you l,al(e an inte,'mediate strategy as in the left-corner al)l)roach.</Paragraph>
    <Paragraph position="5"> lq'he only ln'oblematic ease is for left corner since the corresponding tre.e traw~'rsal inorder is normally defined only for bina,'y trees. But inorder is easily extended to non-binary trees as follows: i. visit the left daughter in inorder, ii. visit the mot, her, iii. visit the rest; of the. daughters in inorder.</Paragraph>
    <Paragraph position="6"> eAs opposed to, say, ~t choice of whether to use operations of expanding and matching or operations of shifting and reducing.</Paragraph>
  </Section>
  <Section position="6" start_page="397" end_page="397" type="metho">
    <SectionTitle>
GREIBACH NORMAL
FORM PARSERS
</SectionTitle>
    <Paragraph position="0"> While this approach reflects the logic of the top-down, bottom-up and left-corner parsers in a clear way, the resulting programs are not all usable in Prolog since the bottom-up and the left-corner parsers are left-recursive. There exists, however, a general technique for removal of left-recursion, namely, conversion to Oreibach normal form. The standard Oreibach normal form conversion, however, does not allow for I)CG type rules, but we can easily take care of the Prolog arguments by a technique suggested by Problem 3.118 of Pereira &amp; Shieber \[9\] to produce what I will call Extended Greibach Normal Form (ECINF). 3 Pereira &amp; Shieber's idea has been more formally presented in the Generalized Greibaeh Normal Form of Dymetman (\[1\] \[2\]), however, the simplicity of the parsers here does not justify the extra complication in Dymetman's procedure. Using this transformation, the bottom-up parser then becomes as follows: 4 aEGNF is similar to normal GNF except that the arguments attached to non-terminals must be manipulated so that the original instantiations are preserved. For specific grammars, it is pretty e~y to see that such a manipulation is possiMe. It is nmch more diftlcult (and beyond the scope of this paper) to show that there is a general rule tbr such manipulations.</Paragraph>
    <Paragraph position="1">  one auxiliary predicate, which (following IIopcroft &amp; Ulhnan \[4\]) I have called b. Of course, the GNF conversion also does not tell us what to do with the auxiliary procedures in curly brackets. What I've done here is silnply to put these auxiliary procedures in the transformed grammar in positions corresponding to where they occurred in the original grammar. It's not clear that one can always find such a &amp;quot;corresponding&amp;quot; position, though in the case of the bottom-up and left-corner parsers such a position is easy to identify.</Paragraph>
    <Paragraph position="3"> b(node(Mother,L,R),Node).</Paragraph>
    <Paragraph position="4"> This, however is not very ef\[icient since the two clauses of both bu and b differ only in whether or not there is a final call to b. ~Ve can reduce l.he a.mount of backtracking by encoding this optiolmlity in the b procedure itself.</Paragraph>
  </Section>
  <Section position="7" start_page="397" end_page="397" type="metho">
    <SectionTitle>
4 PARTIAL EXECUTION
</SectionTitle>
    <Paragraph position="0"> The improved ECNF bottom-np altd left-corner parsers (lilIhr now only in the position of the auxiliary l)redicate in curly brackets. If this auxiliary predicate is partially executed out with respect to a particular gramlnar, the two pltrsers will become identical. For example, if we have a rule of the \['orl)l: s(tree(s,NP,VP)) --&gt; np(RP), vp(VP).</Paragraph>
    <Paragraph position="1"> For either parser, this will result in one b clause of the form: b(np(NP),Node) --&gt; lc(vp(VP)), b(node(s(tree(s,NP,VP)), np(RP),vp(VP)),Node).</Paragraph>
    <Paragraph position="2"> This is essentially eqtfivalent to the kind of rules produced by Matsumoto et al. (\[6\] \[7\])in their &amp;quot;bottom-up&amp;quot; l)arser BUI). s As seen here, Mal, sumo(.o et al were not wrong to call their parser bottom-ui) , but they could have just as well called it left-corner.</Paragraph>
  </Section>
class="xml-element"></Paper>