<?xml version="1.0" standalone="yes"?>
<Paper uid="W97-1510">
  <Title>References</Title>
  <Section position="3" start_page="70" end_page="73" type="intro">
    <SectionTitle>
2 EFLUF - an overview
</SectionTitle>
    <Paragraph position="0"> In this section we will give a short description of how EFLUF works by giving an example that demonstrates how the different features of EFLUF can be used. For this example we have chosen to use a grammar similar to an extended DCG.</Paragraph>
    <Paragraph position="1"> In (StrSmb~ck, 1996) there are examples of how EFLUF also can be used for defining other grammars. null Classes and Inheritance An EFLUF grammar is similar to an object-oriented programming language where the user can define classes for the various objects he wants to handle. Each class contains a set of objects which are defined by constructor declarations. A class inherits its objects from the ancestors in the hierarchy. Multiple inheritance is allowed in a slightly restricted form. To make it easier for the user to organize his definitions EFLUF code can be separated into different modules that can be combined in various ways. To use DCG grammars we use a basic module containing the four classes word,constraint, category and rules that represents the various DCG-ohjects we</Paragraph>
    <Paragraph position="3"/>
    <Paragraph position="5"> unifier parse indef.</Paragraph>
    <Paragraph position="6"> The class word is used for representing the word string. The definition constructor instances simply states that the class will contain the set of objects defined as words in the grammar.</Paragraph>
    <Paragraph position="7"> The classes category and constraint represent grammatical categories and general constraints. In our DCG-module there is one subclass lexconst used to represent lexical constraints. This class contains objects consisting of terms with the functor lex and one argument.</Paragraph>
    <Paragraph position="8"> The last class rules is used for representing grammatical and lexical rules. To build these rules there is a need for the constructors w(_) to mark a word and c(_) to mark a category. We also need lists to represent the right hand side of a grammar rule.</Paragraph>
    <Paragraph position="9"> Lists are here built from the two constructors nil and add_elem(_,_) and are defined from a separate class from which rules inherit.</Paragraph>
    <Paragraph position="10"> Syntax macros In basic EFLUF syntax the given definition allows defining grammar rules and lexical entries in a rather complicated syntax.</Paragraph>
    <Paragraph position="12"> To provide a more convenient syntax the user is allowed to define syntax macros. Syntax macros are defined in Emacs Lisp and are used as a preprocessor of EFLUF files. In the DCG-example above they are defined in a separate file and loaded by the include statement in the beginning of the example. The syntax macros allows the two example rules above to be written with the simplified syntax below.</Paragraph>
    <Paragraph position="13"> granurule s(...) -&gt; rip(...) vp(...); lexrule john n(...) ; In the examples syntax macros are also going to be used to allow a more convienient way for defining word strings. With syntax macros the user is allowed to write such definitions as: defword john This is a shorthand for defining a EFLUF object. The full EFLUF definition without using syntax macros would be: object john; is word.</Paragraph>
    <Paragraph position="14"> In the examples used in this articles we are also going to use syntax macros to allow for a more convienient syntax for lists and feature structures. External processes One last thing to note about the class rules defined above is the unifierstatement. This allows the user to specify an external process and in this case loads the Prolog chart-parser from (Gazdar and Mellish, 1989). The declaration indef at the end of this file means that the  parser can give more than one answer for a query. The actual code for the parser to be loaded by this definition is specified by the statement unifierfile at the top of the example.</Paragraph>
    <Paragraph position="15"> \[n the current implementation an external process could be any Prolog program that takes two EFLUF objects as input and produces a new object as output. There are several ways in which external processes can be used. The parser above uses the grammar rules defined within EFLUF for parsing.</Paragraph>
    <Paragraph position="16"> Parsing could also have been done with the general unification operation provided by EFLUF but the chart parser provides more efficient parsing.</Paragraph>
    <Paragraph position="17"> Another common use for external processes is as an alternative for writing unification rules within EFLUF. For some objects EFLUF's unification rules provides very inefficient unification or unification that seldom will terminate. In this case it is better to use an external process that provides more efficient unification for these kinds of objects. An example of this will be given when we introduce feature structures into our example later in this paper. Inheritance versus Subsumption We also want to add some linguistic knowledge into the example. To demonstrate generality we show two different representations of number and person agreement in english. In the first representation the inheritance hierarchy is used. With this representation agreement information can be correctly unified by using inheritance between classes.</Paragraph>
    <Paragraph position="18">  A second way for the user to represent this information in EFLUF is to define a subsumption order of objects. The example shows the same relations as the inheritance hierarchy but now represented as a subsumption order of atomic objects.</Paragraph>
    <Paragraph position="19">  #include &amp;quot;dcg.fluf&amp;quot; class agreement; isa constraint; constructor sg; constructor pl; constructor sgthird; constructor sgnonthird; constraint sg &gt; sgthird; constraint sg &gt; sgnonthird;  This way of defining a subsumption order by inequalities is in EFLUF called defining constraint relations. The defined constraint relations can be used with the EFLUF unifier, which uses a modification of lazy narrowing by inductive simplification, (Hanus, 1992), to unify the corresponding expressions according to the derived subsumption order. Constraint relations Constraint relations can in EFLUF be used also together with expressions containing variables. This gives the possibility to define more general relations, and in particular functions can be defined in a way similar to, for example, (Johnson and Rosner, 1989) and (Emele and Zajac, 1990). Below we give an example of how appending of lists can be defined. Note that in this example we use = instead of &gt;. This means that EFLUF will interpret the function call and its result as identical in the subsumption order.</Paragraph>
    <Paragraph position="21"> When computing the unifications the unifier uses a mixture between lazy narrowing and inductive simplification. This means that the unifier uses the given constraint relations to simplify an expression as far as it can without binding any variables. When this is not possible anymore it tries to bind variables but only if necessary for finding a solution. When doing this it must keep track of alternative bindings.</Paragraph>
    <Paragraph position="22"> The user can affect this behavior by specifying for each constraint relation that it should be used only for narrowing or simplification. In the first case we obtain a more efficient behavior but all alternatives are not considered and the function cannot be run backwards. We might also sometimes lose alternative answers to a query. In the second case simplification is not used and we get a lazy behavior of the algorithm that always investigates alternative solutions. null To concretize this discussion we will give two example queries. To start with, the query append ((a, b}, ~c, d}) =It gives the expected answer R={a,b, c, d} using lazy narrowing combined with simplification. The same  answer would in this case be received by using only simplification since it can be found without binding any variables within the arguments of append. Using only lazy narrowing would however produce the answer {al append({b}, {c,d}) } since this is the most lazy answer to this query.</Paragraph>
    <Paragraph position="23"> If we instead consider the query append (X, Y) ={a, b, c, d} both lazy narrowing and lazy narrowing together with inductive simplification will produce the expected five bindings of X and Y as results. Using simplification alone would however not find any answers since this is not possible without binding any of the variables X or Y.</Paragraph>
    <Paragraph position="24"> Adding linguistic knowledge We will now continue by exemplifying how rules for nouns and nounphrases can be entered into the grammar.</Paragraph>
    <Paragraph position="25"> Doing this there is a need to both specify the actual words, the categories and constraints to be used and also the particular grammar rules and lexical entries.  Here it can be noted that we make use of the basic classes for DCG when adding linguistic knowledge. To make it easier to separate the grammar into smaller modules we define the knowledge needed for nounphrases in new subclasses to the original classes defined for DCG.</Paragraph>
    <Paragraph position="26"> Disjunctive information Next step is to extend this small grammar with information on phrases and verbs, Doing this we would like to add verbs that are either pl or nonsgthird in our specification of agreement. To avoid duplicate entries there is a need for disjunction. One way to define this in EFLUF is by defining disjunction as a function with constraint relation.</Paragraph>
    <Paragraph position="27"> function or; result constraint; arguments constraint constraint; constraint or(X,Y)&gt;X; constraint or(X,Y)&gt;Y.</Paragraph>
    <Paragraph position="28"> An alternative more specialized way to represent this would be to add one more constructor together with constraint relations into the given definition of  Combining different datatypes To demonstrate that it is possible to mix different structures in EFLUF we are going to use feature structures for representing the arguments of a verb. To do this we add a module containing the definitions needed for representing feature structures. Note that we use an external procedure to obtain efficient unification of feature structures. We also need some syntax macros to obtain a suitable syntax for writing feature structures.</Paragraph>
    <Paragraph position="30"> Inheritance of linguistic knowledge With the given definitions verbs and phrases can be defined. As mentioned above feature structures and terms are mixed for representing the constraints needed for phrases. Another thing that can be noted is that we now make use of the inheritance hierarchy for structuring linguistic knowledge. This is done when defining various types of verbs. For the class verb there is a so called dimension declaration. This declaration is used to specify whether classes are considered to be mutual disjunctive or not. This is very similar to multidimensional inheritance as used in (Erbach, 1994).</Paragraph>
    <Paragraph position="32"> _:transitive:nonsgthrdverb)).</Paragraph>
    <Paragraph position="33"> Requirements on what information an object of a class must contain can be added by specifying a requirement definition. Requirement definitions are inherited from the parent classes in the hierarchy. In this way the user can create an inheritance hierarchy which is similar but not identical to how inheritance is used in other formalisms such as TFS (Emele and Zajac, 1990) or ALE (Carpenter, 1992). In general it can be said that the typing provided by requirements in EFLUF is a bit weaker than the typing provided in the two other formalisms. For the moment nonmonotonic inheritance is not allowed in EFLUF.</Paragraph>
    <Paragraph position="34"> There are however theoretical results on how to include this (StrSmbiick, 1995).</Paragraph>
    <Paragraph position="35"> Weighted unification Finally we want to exemplify one more possibility for the user to affect the behavior of the unification procedure. Suppose we want to use sets in our grammar, but we know that set unification will be very inefficient. Then we might want the unifier to postpone unification involving sets as far as possible. This can be done by specifying a high weight for sets which causes the unifier to postpone unifications involving sets if</Paragraph>
  </Section>
class="xml-element"></Paper>