<?xml version="1.0" standalone="yes"?>
<Paper uid="P93-1029">
  <Title>F-PATR: FUNCTIONAL CONSTRAINTS FOR UNIFICATION-BASED GRAMMARS</Title>
  <Section position="4" start_page="216" end_page="217" type="metho">
    <SectionTitle>
2. FUNCTIONAL CONSTRAINTS
</SectionTitle>
    <Paragraph position="0"> From the graph perspective, the basic vocabulary of PATR-II (Shieber 1984) consists of a set of arc labels and a set of terminal (leaf) node labels, the latter including a variable (or null) value. The graphs can have reentrancies at the leaf levels or higher up, which express identity (or unification) of structure.</Paragraph>
    <Paragraph position="1"> Following Ait-Kaci and Nasr (1989), we incorporate applicative expressions (function specification followed by zero or more argument specifications), into our constraint language. Two uses of applicative expressions in the Ait-Kaci/Nasr language Le Fun concern us here. The first allows variables to equate to an (eventual) evaluation of some applicative expression whose arguments may contain variables. For example,</Paragraph>
    <Paragraph position="3"> (Our convention will be to write applicative expressions using Lisp s-expression syntax, i.e, function name followed by zero or more arguments all enclosed in parentheses.) The second allows Le Fun clauses to be formed from arbitrary ground,decidable predicates, i.e., applicative expressions whose arguments also may start out as variables. For example, given the user-defined boolean function sw-of (south-west of), the following would be an acceptable statement: (swof X Y).</Paragraph>
    <Paragraph position="4"> The analogous PATR-II extension to the first of these allows leaf nodes to be labeled with an applicative expression. Any &amp;quot;unbound&amp;quot; arguments in these applicative expressions will point to variable nodes elsewhere in the graph. Equations such as the following example will then be allowed in the language.</Paragraph>
    <Paragraph position="5"> &lt;mother cover&gt; = (union &lt;daughtl cover&gt; &lt;daught2 cover&gt;) In F-PATR, we restrict the types of nodes represented by paths to those that may appear as leaf values, i.e., atomic, a disjunction of atoms, null (variable), or another applicative value. This restriction is significant: it does not allow for arguments in functional constraints to be of the complex attribute-value type.</Paragraph>
    <Paragraph position="6"> The second use of applicative expressions, as predicates, allows the inclusion of functional expressions into feature specifications as independent conditions on successful unification. So here the evaluation of the expression is not associated with a leaf node's value.</Paragraph>
    <Paragraph position="7"> The statement below is an example of a such a constraint on the value of a node that might be included in graph. This predicate sw-of will be taken to be a condition on successful unification.</Paragraph>
    <Paragraph position="8"> (sw-of &lt;daughtl cover&gt; &lt;daught2 cover&gt;) The two statements above taken together would then correspond to the graph shown in Figure 1, a first approximation for a rule for forming exponent expressions in a grammar of mathematical notation. The unlabeled arcs linking arguments in applicative expressions to the variable nodes are a notational convenience, indicating a forwarding pointer. The arguments to these expressions are in fact the nodes themselves.</Paragraph>
    <Paragraph position="9">  mother J ~ I cover r cdegver I _ ) ~cover ~(union J~ (sw-of ~. /') Figure 1 An F-PATR Graph  Our proposal for F-PATR feature structures begins with a vocabulary of the following types suitable for  interpretive, functionally oriented programming languages such as Lisp.</Paragraph>
    <Paragraph position="10"> Atom Symbol or number Fun-exp Function, i.e, symbol pointing to a function, or lambda expression interpretable as a function, of type Atom X Atom x ... Atom ---&gt; Atom or else Atom x Atom X ... Atom ---&gt; List-of-atoms (where List-of-atoms will be interpreted as a logical disjunction of atomic values) S-expression Any complete evaluatable expression without internal references to F-PATR nodes The following then is a BNF grammar for F-PATR equations representing feature structures:  We will assume the existence of a familiar equivalent notation for these feature equations, in which graph reentrancies (or path equivalences) are expressed by a matrix with integers used for shared reference. Predicates will follow the core attribute- null value matrix. For example, \[a: 1\[\] b: 2(foo &lt;1&gt;)\] (fie &lt;1&gt; &lt;2&gt;) is equivalent to &lt;b&gt; = (foo &lt;a&gt;) (fie &lt;a&gt; &lt;b&gt;).</Paragraph>
    <Paragraph position="11">  In addition to functional values and constraints, we augment the original PATR-II notation with atomic disjunction (interpreted as exclusive OR) as a possible value of leaf nodes. Such values are written with curly braces surrounding two or more atoms. Atomic disjunction is one of the most basic extensions to the PATR-II unification language and is in common use. If atomic values are considered to be singleton sets, unification of atomic disjunctions with other disjunctions or atoms can be operationally treated as set intersection. In F-PATR, atomic disjunctions may appear not only independently but also as arguments and values of applicative expressions.</Paragraph>
  </Section>
  <Section position="5" start_page="217" end_page="218" type="metho">
    <SectionTitle>
3. DATA TYPES
</SectionTitle>
    <Paragraph position="0"> In Ait-Kaci and Nasr (1989), functional expressions in feature structures are evaluated as soon as their arguments become bound. Otherwise, data structures will become residuated, a state representing incompletion with respect to determining constraints on unification. Ait-Kaci and Nasfs algorithms thus delay the resolution of functionally-specified values or predicates until all variables are bound, but then resolve them as early as possible once bindings occur.</Paragraph>
    <Paragraph position="1"> Here we follow this same general approach for predicates only, but not for applicative values, which are checked for readiness to evaluate only when dereferenced. Further, we expand the routines to deal with atomic disjunction.</Paragraph>
    <Paragraph position="2"> We assume the following data types for nodes in a feature structure graph: :Arc-list a set of attribute labels and associated values, the latter of which may be of any type :null the uninstantiated &amp;quot;variable&amp;quot; type :atomic a singleton set of one symbol or number :disjunct a set of 2 or more atomic values :appl an applicative expression :res-var a residuated variable, i.e., a :null type that appears as an argument in at least one predicate :res-disjunct a residuated disjunction, i.e., a :disjunct type that appears as an argument in at least one predicate The node types that may acquire residuations include :null, :disjunct, and :appl (a type for which we do not distinguish residuated from nonresiduated subtypes). There are two kinds ofresiduations: predicates not ready for evaluation and delayed unifications associated with the :appl type. Predicate residuations arise when a predicate contains any arguments of type :null or :appl, or else when a predicate has more than one argument of type :disjunct. During unification, any such arguments mutate to a residuated type (if they are urtresidutated to start with), and the predicate is pushed onto their residuation list.</Paragraph>
    <Paragraph position="3"> The second kind of residuation arises when unification is called for between a node of type :appl that is not ready for evaluation and any other non-:null type. The unification call itself must be delayed until such time as the function is ready for evaluation, and so a form that will provoke the unification is pushed onto the residuation list of the :appl node.</Paragraph>
  </Section>
  <Section position="6" start_page="218" end_page="218" type="metho">
    <SectionTitle>
4. DEREFERENCING
</SectionTitle>
    <Paragraph position="0"> The notion of dereferencing a data structure representing a feature value (or node) is common to most unification implementations. A field in the data structure indicates whether the value is to be found locally or else by following pointers to other data structures that may have been introduced through prior unification. Introducing residuations into the data structures adds the wrinkle that, during dereferencing, applicative expressions will be evaluated if they are ready. In F-Patr, dereferencing an :appl type node is in fact the only point at which to evaluate an applicative expression. This is a change from Le Fun--there arguments in applicative expressions may acquire applicative expressions as residuations that can be evaluated as argument terms become grounded during unification.</Paragraph>
    <Paragraph position="1"> This design change will be motivated in Section 6.</Paragraph>
    <Paragraph position="2"> For each node type, the dereference function follows pointers in the usual way until no pointers remain. In addition, if the resulting node is of :appl type, we check to see if all its arguments are atomic or else lisp s-expressions, an indication that the function is ready to be evaluated. If the function evaluates to a non-nil atom or a disjunctive list of atoms, then any residuations (delayed unifications) on the node are also called. Note then that dereferencing can itself fail as a result of provoking unifications that fail, which the top-level unification routines need to take account of.</Paragraph>
  </Section>
  <Section position="7" start_page="218" end_page="218" type="metho">
    <SectionTitle>
5. UNIFICATION
</SectionTitle>
    <Paragraph position="0"> The types associated with successful unifications of dereferenced leaf node types are shown in Table 1.</Paragraph>
    <Paragraph position="1"> Some cells contain more than one type since residuations and disjunctions may or may not be reduced in the result term. Note that an :appl type unified with any other type always yields another :appl type. This is a bit misleading, however, since the table does not take into account the effects of dereferencing, which, as we have just described, can provoke a chain of delayed unifications involving any types.</Paragraph>
    <Paragraph position="2"> During unification, the evaluation of functions used in predicates and :appl nodes each may produce disjunctive values, but in different ways. Predicates can be evaluated when there is at most one disjunctive argument node, in which case we map the predicate Over each of the disjunctions in the disjunctive argument, and collect successful results. If there is more than one successful result, then the result is a disjunction. Alternatively, for functions appearing in :appl nodes only, the function itself may produce a disjunctive value as directed by the internal definition of the function. But note that functions used in F-PATR graphs do not themselves take disjunctive arguments directly, as indicated in the discussion of data types above.</Paragraph>
    <Paragraph position="3">  There are a number of pairings in Table 1 that are capable of producing either residuated disjunctions, disjunctions, or atoms. These all involve a residuated predicate appearing in at least one of the leaf node arguments. If the initial intersection of the node's contents (independently from residuations) yields a value that still does not provoke evaluation of the predicate, then the result is a residuated disjunction. If the predicate is evaluated, then the unification process may yield an atomic value or a disjunctive value, as explained in the previous paragraph.</Paragraph>
    <Paragraph position="4"> Space precludes us from further discussion of the unification algorithms here. With refej-ence to Ait-Kaci and Nasr (1989) and Table 1, however, the details should emerge. See also the examples in the Appendix, which are taken from program output.</Paragraph>
  </Section>
  <Section position="8" start_page="218" end_page="220" type="metho">
    <SectionTitle>
6. APPLICATION TO PARSING
</SectionTitle>
    <Paragraph position="0"> The two significant design changes that we have introduced were motivated by our application of F-PATR to parsing of relational set grammars for graphical languages, which is discussed in detail in WWT.</Paragraph>
    <Paragraph position="1"> Initial experiments adopted the Ait-Kaci/Nasr  approach of evaluating the functions of :appl nodes as soon as possible, which meant residuating the argument nodes of these functions. However, this approach led to difficulties in our chart parsing algorithm, which needed to cache the feature structures of active edges before any of the destructive effects of unification involving what we call expander functions took place. The root of the issue is that with the Ait-Kaci/Nasr approach, the control of function evaluation is within unification rather than with some external algorithm. In our approach, it was most natural to use external co n~0 |to implement chart parsing. This point may be c.larified by considering an example, for which we need to summarize F-PATR relational set grammars. (See also Wittenburg (1992a 1992b).) The feature structures for grammatical constituents include the primary attributes cover, syntax, and semantics. The attribute cover takes as value a reference to a subset of input objects. This scheme is analogous to HPSG feature structures, where the stringvalued phonology attribute is replaced by the set-valued cover attribute. Rules have the form \[mother: \[cover: \[\] syntax: \[\] semantics: \[\]\] daughtl: \[cover: \[\] syntax: \[\] semantics: \[\]\] daughtn: \[cover: \[\] syntax: \[\] semantics: \[\]\]\] with the condition that for the daughter elements of a rule D1...Dn, there must exist at least one expander relation between covers of each daughter Di, 2 &lt; i &lt; n, and a cover of daughter Dj where j &lt; i.</Paragraph>
    <Paragraph position="2"> The expander relations are a subclass of relational constraints among sets of input objects used to define the combinatory possibilities of rules. For parsing, the constraints are expressed as functions from cover-sets to cover-sets and appear as a functional value of cover attributes.</Paragraph>
    <Paragraph position="3"> \[mother: \[syntax: Exp cover: (union-covers &lt;2&gt; &lt;3&gt; &lt;4&gt;) semantics: (divide &lt;6&gt; &lt;7&gt;)\] daughtl: \[syntax: horizontal-line cover: 2\[\]\] daught2: \[syntax: Exp cover: 3(what-is-above &lt;2&gt;) semantics: &lt;6&gt;\] daught3: \[syntax: Exp cover: 4(what-is-below &lt;2&gt;) semantics: &lt;7&gt;\]\] (contains-in-x &lt;2&gt; &lt;4&gt;) (contains-in-x &lt;2&gt; &lt;3&gt;) The example above is the rule for vertical infixation for fractions, used in a grammar of mathematical notation. null Let us consider now what the feature structure for an active chart-parsing edge for the fraction rule would look like after the first daughter had been unified in. The cover attribute would acquire a set-reference value (we will use a number in binary suggestive of the use of bit vectors to represent subsets).</Paragraph>
    <Paragraph position="4"> Active edge feature structure: \[mother: \[syntax: Exp cover: (union-covers 0001 &lt;3&gt; &lt;4&gt;) semantics: (divide &lt;6&gt; &lt;7&gt;)\] daughtl: \[syntax: horizontal-line cover: 0001\] daught2: \[syntax: Exp cover: 3(what-is-above 0001) semantics: &lt;6&gt;\] daught3: \[syntax: Exp cover: 4(what-is-below 0001) semantics: &lt;7&gt;\]\] (contains-in-x 0001 &lt;4&gt;) (contains-in-x 0001 &lt;3&gt;) At this point the Ait-Kaci/Nasr algorithm for unification would provoke the evaluation of the what-is-above and what-is-below functions, since their arguments are now &amp;quot;grounded&amp;quot;. However, this is not what we want for a chart parser since the features of the active edge graph shown here must be kept independent from each of its future advancements. That is, we want to evaluate these two functions at separate cycles in the parsing algorithm at the points when we are ready to extend this edge with the daughters in question. The more conservative approach to derefencing and evaluation of :appl nodes and also the extension of disjunctions as possible values of expander functions provides an elegant solution. ! The functions what-is-above and what-is-below will be evaluated in independent expand steps of the WWT algorithm. In either case, the function is capable of returning a disjunction of values. But any such values must also meet the constraints of the predicate contains-in-x, the application of which may have the effect of reducing the set of val1. Hassan Ait-Kaci (personal communication) has pointed out that a solution to the control problem is available in the Le Fun/LIFE framework. An extra unbound argument could be added to expander functions such as what-is-above so that evaluation would not be provoked at undesired times. A binding for this extra variable could later be offered when evaluation was wanted.  ues and perhaps eliminating all of them, leading to a unification failure. All this happens as it should with the approach to unification outlined above.</Paragraph>
  </Section>
class="xml-element"></Paper>