<?xml version="1.0" standalone="yes"?>
<Paper uid="W97-1510">
  <Title>References</Title>
  <Section position="4" start_page="73" end_page="74" type="metho">
    <SectionTitle>
3 Sample parses
</SectionTitle>
    <Paragraph position="0"> To complete the sample grammar given in the previous section we will give some examples of the results given when parsing some sentences with the given definitions. These examples also show how parsing queries are made to the EFLUF unifier.</Paragraph>
    <Paragraph position="2"> As can be seen by these examples a unification query to EFLUF is made by calling the Prolog procedure uf. This procedure takes three arguments; the first two are the expressions to be unified while the third is the result of the unification. To parse a sentence the procedure is called with a sentence as first argument. To force the system to parse this as a sentence instead of unifying it as a list the sentence is typed as belonging to the class rule. The second argument is used to say that we want something that matches c(_) as result. The reason for this is to prevent the unifier from being too lazy and just return the given sentence as result.</Paragraph>
    <Paragraph position="3"> As can be seen by the given examples the first two sentences give the expected structures as result of the parsing while the third does not give any result due to the difference in agreement within john and eat.</Paragraph>
  </Section>
  <Section position="5" start_page="74" end_page="74" type="metho">
    <SectionTitle>
4 Experience from EFLUF
</SectionTitle>
    <Paragraph position="0"> The current implementation of EFLUF has only been used for toy examples. Even so, working with this system gives ideas on how a better environment should be built and we will conclude this paper by discussing some of these ideas. First we will discuss some general problems and give suggestions for how these can be solved. We will then look more specificly into the problems of modularization and efficiency. In particular we will suggest how this kind of system can be used as a help when building a new application.</Paragraph>
    <Paragraph position="1"> EFLUF has been designed to be flexible in the sense that the user should be able to decide as much as possible of the formalism. This also means that the basic constructions provided by EFLUF are rather simple and that it is the definitions made by the user that actually set out the constructions provided in a particular application. This has been a main goal when designing EFLUF but there is at least two major drawbacks with this idea when thinking about building an environment for larger applications. The first drawback is that a general formalism often becomes computationally less efficient than a more specialized one and the second is that it requires more knowledge of the user than using a more specialized one.</Paragraph>
    <Paragraph position="2"> We believe that it is possible to avoid this by designing a future version of EFLUF as a large library of various standard definitions. Here we could achieve better efficiency by providing efficient external unifiers and other processes for the modules of this library. Since the user could start with these predefined modules the system would also be much more easy to use. This idea of providing a library of external procedures has previously been investigated in (Erbach et al., 1993).</Paragraph>
    <Paragraph position="3"> This kind of library of definitions could be built using the possibility to structure definitions into separate files. However, the only thing in the EFLUF formalism that actually supports this division into modules is the inheritance hierarchy.</Paragraph>
    <Paragraph position="4"> Even if EFLUF definitions are structured into a library there is still need to support the user in managing this hierarchy. One interesting point here is how the typing works. In EFLUF we have adopted an idea similar to (Carpenter, 1992) which in EFLUF means that the system should be able to judge the type of an expression by only knowing its functor and number of arguments. When considering building large applications it might be better to use the type hierarchy for distinguishing various definitions. This means that it should be possible to use the same name for different constructors in different modules and that the system uses the typing as a help to distinguish which of these the user means, similar to module constructions used in many programming languages.</Paragraph>
    <Paragraph position="5"> As said above one major drawback with a general formalism is that it gets less efficient. In EFLUF we have tried to improve this by providing ways for the user to affect the behavior of the unification algorithm. This can be done in three ways. First the user can specify if equations should be used only for induction or for narrowing. Secondly he can get the unifier to avoid some classes by specifying weights.</Paragraph>
    <Paragraph position="6"> At last he can also provide his own more specialized and efficient algorithms. Other formalisms allow similar ways of affecting the unification algorithms, for instance RGR (Erbach et al., 1993) and TDL (Krieger and Sch~fer, 1994).</Paragraph>
    <Paragraph position="7"> An interesting use of a system like EFLUF is as a tool for supporting the development of a linguistic application with both grammar and specialized unification algorithms. This can be done in the following way. First, the EFLUF system can be used to compare how well different constructions are suited to describe some subparts of the linguistic input.</Paragraph>
    <Paragraph position="8"> When the user has decided that some construction is relevant to his application, the performance of the EFLUF system can be improved by defining specialized unifiers and syntax macros for this construction if they were not already provided by EFLUF. The EFLUF system can then be used for defining and testing grammars and lexicons. Further syntax macros can then be defined to provide a syntax that is the same as the syntax required for the final grammar. In parallel with the development of grammar and lexicon the work on developing a more efficient implementation can be started. While developing an implementation much of the code for the syntax macros and specialized unifiers can be reused.</Paragraph>
  </Section>
  <Section position="6" start_page="74" end_page="75" type="metho">
    <SectionTitle>
5 Comparison with other systems
</SectionTitle>
    <Paragraph position="0"> Finally we want to pinpoint the most important features within EFLUF and give some comments on how these relates to other formalisms.</Paragraph>
    <Paragraph position="1">  The major idea when defining EFLUF was to let the user himself define all the constructions he needs. The work on EFLUF shows that it is possible to provide a formalism where the user is allowed to define almost everything. This is a difference to most other unification-based formalisms which sees the possibility to define the constructions as an extension to the formalism and not as a basic concept.</Paragraph>
    <Paragraph position="2"> The design of EFLUF can be seen as having the possibility of defining own constructions as a kernel and then the typing system is built on top of these. This is also the case for CUF and TFS while, for instance ALE, is designed with typing as the most basic concept and the possibility to define constructions as an add-on. It seems that formalisms designed with the possibility to define own constructions as a basic concept instead of as an add-on achieve a higher level of flexibility since the new datatypes defined are better integrated into the formalism. null As for the typing system in EFLUF, variants of typing have been investigated and employed.</Paragraph>
    <Paragraph position="3"> EFLUF can handle both open- and closed-world reasoning, maximal and nonmaximal typing and provides two different kinds of typing through constructor and requirement definitions. Most other systems do not provide this rich variety of typing strategies. One important way of achieving a better overall performance of EFLUF is to allow the user to affect the behaviour of the unification algorithm. In EFLUF only two such possibilities have been implemented. Other formalisms, especially CUF and TDL, offer other possibilities that can be incorporated in future versions of EFLUF.</Paragraph>
    <Paragraph position="4"> The idea of allowing a general constraint solver to call more efficient specialized unifiers is the most promising way of achieving high efficiency within a general constraint solver. Other formalisms also have this feature, for instance, being able to use external constraint solvers in ALEP. However, EFLUF combine the external constraint solver with a general possibility for the user to define new datastructures within the system.</Paragraph>
    <Paragraph position="5"> An interesting question is how EFLUF relates to the GATE system. In GATE it is possible to combine modules working on a text into a system by defining in which order they should process the text.</Paragraph>
    <Paragraph position="6"> EFLUF is orthogonal to this since it provides a way for putting together submodules into a larger module defining for instance the behaviour of a parser. An interesting line for future work would be to investigate if this could be done in a similar and as simple way as it is done in GATE and if it would be possible to integrate the two systems.</Paragraph>
  </Section>
class="xml-element"></Paper>