<?xml version="1.0" standalone="yes"?>
<Paper uid="C90-1012">
  <Title>The Generalized LR Parser/Compiler V8-4: A Software Package for Practical NL Projects</Title>
  <Section position="2" start_page="0" end_page="0" type="metho">
    <SectionTitle>
2. Top-Level Functions
</SectionTitle>
    <Paragraph position="0"> There are three top-level functions:  ; to compile a grammar (compgra grammar-file-name) ; to load a compiled grammar (loadgra grammar-file-name) ; to parse a sentence string (p sentence) 3. Pseudo Equations  This section describes pseudo equations for the</Paragraph>
    <Paragraph position="2"> Get a value from path, unify it with val, and assign the unified value back to path. If the unification fails, this equation fails. If the value of path is undefined, this equation behaves like a simple assignment. If path has a value, then this equation behaves like a test statement.</Paragraph>
    <Paragraph position="3"> path I = path2 Get values from path1 and path2, unify them, and assign the unified value back to path1 and path2. If the unification fails, this equation fails. If both path1 and path2 have a value, then this equation behaves like a test statement. If the value of path1 is not defined, this equation behaves like a simple  assignment.</Paragraph>
    <Paragraph position="4"> 3.2= Overwrite Assignment, &lt;= path &lt;= val Assign val to the slot path. If path1 is already defined,  the old value is simply overwritten.</Paragraph>
    <Paragraph position="5"> path I &lt;= path2 Get a value from path2, and assign the value to path 1. If path1 i.,{ already defined, the old value is simply overwritten.</Paragraph>
    <Paragraph position="6"> path &lt;= lisp-function-call Evaluate lisp-function-call, and assign the returned value to path. If path1 is already defined, the old value is simply overwritten, lisp-function-call can be an arbitrary lisp code, as long as all functions called in lisp-function-call are defined. A path can be used as a special function that returns a value of the slot. 3.3. Removal Assignment, == path I == path2 Get a value from path2, assign the value to path I, and remove the value of path2 (assign nil to path2). If a value already exists in path1, then the new value is unified with the old value. If the unification fails, then this equation fails.</Paragraph>
    <Paragraph position="7"> 3.4. Append Multiple Value, &gt; path I &gt; path2 Get a value from path2, and assign the value to path 1. If a value already exists in path1, the new value is appended to the old value. The resulting value of path1 is a multiple value.</Paragraph>
    <Paragraph position="8"> 3.5. Pop Multiple Value, &lt; path 1 &lt; path2 The value of path2 should be a multiple value. The first element of the multiple value is popped off, and assign the value to path1. If path1 already has a value, unify the new value with the old value. If path2  is undefined, this equation fails.</Paragraph>
    <Paragraph position="9"> 3.6. *DEFINED* and *UNDEFINED* path= *DEFINED* Check if the value of path is defined. If undefined, then this equation fails. If defined, do nothing. 3.7. Constraint Equations, =c  is an inclusive OR, as oppose to exclusive OR; Even if one of the lists of equations is evaluated successfully, the rest of lists will be also evaluated anyway. 3.13. Recurslve Evaluation of Equations,</Paragraph>
    <Paragraph position="11"> The *INTERPRET* statement first gets a value from path. The value of path must be a valid list of equations. Those equations are then recursively evaluated. This *INTERPRET* statement resembles the &amp;quot;eval&amp;quot; function in Lisp.</Paragraph>
    <Paragraph position="12">  \]his is the same as disjunctive equations *OR*, except an exclusive OR is used. That is, as soon as one of the element is evaluated successfully, the rest of elements will be ignored.</Paragraph>
    <Paragraph position="14"> \]he *CASE* statement first gets the value in path.</Paragraph>
    <Paragraph position="15"> \]he value is then compared with Key1, Key2 ...... and as soon as the value is eq to some key, its rest of equations are evaluated.</Paragraph>
    <Paragraph position="16"> 3.12. Test with an User-defined LISP Function, *TEST* (*TEST* lisp-function-carl) \]he lisp.function-call is evaluated, and if the function returns nil, it falls. If the function returns a non-nil value, do nothing. A path can be used as special function that returns a value of the slot.</Paragraph>
    <Paragraph position="17">  unified with a value, each element is unified with a value. For example, (unify ' (*MULTIPLE* a b  c d b d e f) &amp;quot;d) is (*MULTIPLE* d d). 3.17. User Defined special Values,</Paragraph>
    <Paragraph position="19"> The user can define his own special values. An unification function with the name UNIFY*user-defined* must be defined. The function should take two arguments, and returns a new value or *FAIL* if the unification fails.</Paragraph>
  </Section>
  <Section position="3" start_page="0" end_page="0" type="metho">
    <SectionTitle>
4. Standard Unification Mode
</SectionTitle>
    <Paragraph position="0"> The pseudo equations described in the previous section are different from what functional grammarians call &amp;quot;unification&amp;quot;. The user can, however, select &amp;quot;full (standard) unification mode&amp;quot; by setting the global variable *UNIFICATION-NODE* from PSEUDO to 3 61 FULL. In the full unification mode, equations are interpreted as standard equations in a standard functional unification grammar \[5\], although some of the features such as user-defined function calls cannot be used. However, most users of the parser/compiler find it more convenient to use PSEUDO unification than FULL unification, bot only because it is more efficient, but also because it has more practical features including user-defined function calls and user-defined special values. Those practical features are crucial to handle low-level non-linguistic phenomena such as time and date expressions \[8\] and/or to incorporate semantic and pragmatic processing of the user's choice. More discussions on  The user has a choice to make his grammar &amp;quot;character basis&amp;quot; or standard &amp;quot;word basis&amp;quot;. When &amp;quot;character basis mode&amp;quot; is chosen, terminal symbols in the grammar are characters, not words. There are at least two possible reasons to make it character basis: 1. Some languages, such as Japanese, do not have a space between words. If a grammar is written in character basis, the user does not have to worry about word segmentation of unsegmented sentences.</Paragraph>
    <Paragraph position="1">  In pseudo unification mode, the user can use a wild card character &amp;quot;%&amp;quot; in his grammar to match any character (if character basis) or any word (if word basis). This feature is especially useful to handle proper nouns and/or unknown words.</Paragraph>
    <Section position="1" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
5.3. Grammar Debugging Tools
</SectionTitle>
      <Paragraph position="0"> The Generalized LR Parser/Compiler V8-4 includes some debugging functions. They include: * dmode --- debugging mode; to show a trace of rule applications by the parser'.</Paragraph>
      <Paragraph position="1"> * trace --- to trace a particular rule.</Paragraph>
      <Paragraph position="2"> * disp-trees, disp-nodes, etc. --to display parlial trees or values of nodes in a tree.</Paragraph>
      <Paragraph position="3"> All of the debugging tools do not use any fancy graphic interface for the sake of system portability.</Paragraph>
    </Section>
  </Section>
  <Section position="4" start_page="0" end_page="0" type="metho">
    <SectionTitle>
5.4. Interpretive Parser
</SectionTitle>
    <Paragraph position="0"> The Generalized LR Parser/Compiler V8-4. includes another parser based on chart parsing which can parse a sentence without ever compiling a grammar: ; to load a grammar (i-loadgra grammar-file-name) ; to run the interpretive parser (i-p sentence) While its run time speed is significantly slower than that of the GLR parser, many users find it useful for debugging because grammar does not need to be compiled each time a small change is made.</Paragraph>
    <Section position="1" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
5.5. Grammar Macros
</SectionTitle>
      <Paragraph position="0"> The user can define and use macros in a grammar.</Paragraph>
      <Paragraph position="1"> This is especially useful In case there are many similar rules in the grammar. A macro can be defined in the same way as CommonLisp macros. Those macros are expanded before the grammar is compiled.</Paragraph>
    </Section>
  </Section>
  <Section position="5" start_page="0" end_page="0" type="metho">
    <SectionTitle>
6. Concluding Remarks
</SectionTitle>
    <Paragraph position="0"> Some of the important features of the Generalized LR Parser/Compiler have been highlighted. More detailed descriptions can be found in its user's manual \[9\]. Unlike most other available software \[1,2, 4\], the Generalized LR Parser/Compiler v8-4 is designed specifically to be used in practical natural language systems, sacrificing perhaps some of the linguistic and theoretical elegancy. The system has been thoroughly tested and heavily used by many users in many projects inside and outside CMU last three 62 4 years. Center for Machine Translation of CMU has \[8\] developed rather extensive grammars for English and Japanese for their translation projects, and some experimental grammars for French, Spanish, Turkish and Chinese. We also find the system very suitable to \[9\] write and parse task-dependent semantic grammars.</Paragraph>
    <Paragraph position="1"> Finally, a project is going on at CMU to integrate the parser/compiler with a speech recognition system</Paragraph>
  </Section>
class="xml-element"></Paper>