<?xml version="1.0" standalone="yes"?>
<Paper uid="J90-1004">
  <Title>SEMANTIC-HEAD-DRIVEN GENERATION</Title>
  <Section position="3" start_page="0" end_page="0" type="intro">
    <SectionTitle>
1.2 PRELIMINARIES
</SectionTitle>
    <Paragraph position="0"> Despite the general applicability of the algorithm, we will, for the sake of concreteness, describe it and other generation algorithms in terms of their implementation for definite-clause grammars (DCG). For ease of exposition, the encoding will be a bit more cumbersome than is typically found in Prolog DCG interpreters. The standard DCG encoding in Prolog uses the notation (cat o) --&gt; (cat I ) ..... (cat,).</Paragraph>
    <Paragraph position="1"> where the (cat i) are terms representing the grammatical category of an expression and its subconstituents. Terminal symbols are introduced into rules by enclosing them in list brackets, for example sbar/S --&gt; \[that\], s/S.</Paragraph>
    <Paragraph position="2"> Such rules can be translated into Prolog directly using a difference list encoding of string positions; we assume readers are familiar with this technique (Pereira and Shieber, 1985).</Paragraph>
    <Paragraph position="3"> Because we concentrate on the relationship between expressions in a language and their logical forms, we will assume that the category terms have both a syntactic and a semantic component. In particular, the infix function symbol / will be used to form categories of the form Syn/Sem where Syn is the syntactic category of the expression and Sere is an encoding of its semantics as a logical form; the previous rule uses this notation, for example. From a DCG perspective, all the rules involve the single nonterminal/, with the given intended interpretation. Furthermore, the representation of grammars that we will postulate includes the threading of string positions explicitly, so that a node description will be of the form node (Syn/Sem, PO-P).</Paragraph>
    <Paragraph position="4"> The first argument of the node functor is the category, divided into its syntactic and semantic components; the second argument is the difference list encoding of the substring it covers. In summary, a DCG grammar rule will be encoded as the clause</Paragraph>
    <Paragraph position="6"> We use the functor '---&gt;' to distinguish this node encoding from the standard one. The right-hand-side elements are kept as a Prolog list for easier manipulation by the interpreters we will build.</Paragraph>
    <Paragraph position="7"> We turn now to the issue of terminal symbols on the right-hand sides of rules in the node encoding. During the compilation process from the standard encoding to the node encoding, the right-hand side of a rule is converted from a list of categories and terminal strings to a list of nodes connected together by the difference-list threading technique used for standard DCG compilation. At that point, terminal strings can be introduced into the string threading and need never be considered further. For instance, the previous rule becomes node(sbar/S, \[that\[P0\]-P) ---&gt; node(s/S, P0-P).</Paragraph>
    <Paragraph position="8"> Throughout, we will alternate between the two encodings, using the standard one for readability and the node encoding as the actual data for grammar interpretation. As the latter, more cumbersome, representation is algorithmically generable from the former, no loss of generality ensues from using both.</Paragraph>
  </Section>
class="xml-element"></Paper>