<?xml version="1.0" standalone="yes"?>
<Paper uid="P90-1023">
  <Title>Structure-Sharing Representation for Unification-Based Grammar Formalisms.&amp;quot;</Title>
  <Section position="7" start_page="185" end_page="186" type="concl">
    <SectionTitle>
CONCLUDING REMARKS
</SectionTitle>
    <Paragraph position="0"> There is another optimization possible regarding certain leaf nodes of a DAG.</Paragraph>
    <Paragraph position="1"> Depending on the application using graph unification, a subset of the leaf nodes will never be unified with other DAG's. In the TASLINK application these are nodes representing such features as third person singular. This observation can be exploited under both lazy and eager unification to reduce both copying and active node creation. See Godden (1989) for details.</Paragraph>
    <Paragraph position="2"> It has been my experience that using lazy evaluation as an optimization technique for graph unification, while elegant in the end result, is slow in development time due to the difficulties it presents for debugging. This property is intrinsic to lazy evaluation, (O'Donnell and Hall, 1988).</Paragraph>
    <Paragraph position="3">  The problem is that a DAG is no longer copied locally because the copy operation is suspended in the active nodes. When a DAG is eventually copied, that copying is performed incrementally and therefore non-locally in both time and program space. In spite of this distributed nature of the optimized process, the programmer continues to conceptualize the operation as occurring locally as it would occur in the non-optimized eager mode. As a result of this mismatch between the programmer's visualization of the operation and its actual execution, bugs are notoriously difficult to trace. The development time for a program employing lazy evaluation is, therefore, much longer than would be expected. Hence, this technique should only be employed when the possible efficiency gains are expected to be large, as they are in the case of graph unification. O'Donnell and Hall present an excellent discussion of these and other problems and offer insight into how tools may be built to alleviate some of them.</Paragraph>
  </Section>
class="xml-element"></Paper>