<?xml version="1.0" standalone="yes"?>
<Paper uid="E91-1011">
  <Title>Processing Language with Logical Types and Active Constraints</Title>
  <Section position="2" start_page="0" end_page="0" type="metho">
    <SectionTitle>
6. A Constraint Logic Programming
</SectionTitle>
    <Paragraph position="0"> interpretation of the 'pending' constraint The pending constraint is interpreted within the Constraint Logic programming framework (Colmerauer 90, Jaffar and Lassez 87) in a very simple way. The constraint solving approach of the CLP corresponds better to programming practice and to programming language design. Constraints directly state properties on objects of the domain being dealt with which have to be always true, in contrast to coding them by means of terms. The CLP framework offers a global rule-based framework to handle and to reason about constraints.</Paragraph>
    <Paragraph position="1"> The domain of objects on which constraints of a CLP interpretation of Dislog operate is a domain of types. Let us first consider a simple translation example of a Dislog clause into a CLP clause. A Dislog clause like: {a,b} where a and b are type construction (TC) specifications, is translated as follows in CLP:  a :- pending(a, \[b\]).</Paragraph>
    <Paragraph position="2"> b :- pending(b, \[a\]).</Paragraph>
    <Paragraph position="3"> The constraint pending(A,B) states here that the TC A is at the origin of the pending TC B. The general case is interpreted as follows. Let us consider the Dislog clause: {A.B ..... N}.</Paragraph>
    <Paragraph position="4"> it is translated into a set of CLP clauses as follows: A :- pending(A, \[B ..... N\] ).</Paragraph>
    <Paragraph position="5"> B :- pending(B, \[A ..... N\] ).</Paragraph>
    <Paragraph position="6">  N :- pending(N, \[A, B .... \] ).</Paragraph>
    <Paragraph position="7"> The constraint resolution procedure associated to pending consists in a simplification rule for the elimination of pending TCs when the co-occurence contraint is satisfied. This simplification rule is written as follows for the simple example given above in section 2: pendlng(A,B)A pending(B,A) --&gt; O .</Paragraph>
    <Paragraph position="8"> Notice that we have a symmetric treatment for A and B. The general simplification rule is the following, where LA, LB and LC are lists of pending TCs: (pending(A, LA), pending(B, LB) --&gt; pending(A, LC) ) :mb(A, LB), mb(13, LA), Withdraw(B, LA, LC).</Paragraph>
    <Paragraph position="9"> LC is the resulting pending list equal to LA minus B.</Paragraph>
    <Paragraph position="10"> This constraint resolution mechanism can be further extended quite straightforwardly to handle linear precedence restrictions and modalities. Linear precedence constraints.are dealt with independently from each other. The Dislog clause:</Paragraph>
    <Paragraph position="12"> is translated into a CLP clause as follows: Z &lt;&gt; pending(X, \[A, B .... , .... Y .... , N\]) ^ not (pending(Y,\[A, B ..... X ........ , N\])).</Paragraph>
    <Paragraph position="13"> The coherence control is the following: pending(X, LA)^not(pendlng(X, LA)) --&gt; failure.</Paragraph>
    <Paragraph position="14"> the simplification rule is: not (pending(Y, \[A, B ..... X .... , ..., N\] )) --&gt; O or, more simply, since all negations are withdrawn at each stage: not (pending(_,_) --&gt; O.</Paragraph>
    <Paragraph position="15"> 7. Specific features of our approach Our approach can be contrasted mainly with the usual systems based on unification grammar (UG) formalisms. The first major difference is that the unification and rewriting mechanisms usually associated with UG are replaced by a more constraining operation, type construction, which always proceeds by sucessive restrictions (or monotone increasing specialisation) each time a type is further expanded. From that point of view, our approach also substancially differs from (Emele &amp; Zajac 90) who propose a powerful and semantically clear mechanism for typed unification associated to type inheritance.</Paragraph>
    <Paragraph position="16"> Next, we have a single operation: type construction; we do not have on the one hand grammar rules and on the other hand, associated to each rule, a set of equations to deal with feature values and constraints. The constraints we have associated with our types are not of the same nature and cannot be compared to the equations of UGs.</Paragraph>
    <Paragraph position="17"> They are moreover a part of the type.</Paragraph>
    <Paragraph position="18"> Constraints added to types are interpreted within the CLP framework, this permits us to have a more expressive and powerful constraint system, which is also more efficient and simpler to write. Constraint satisfaction is not indeed guaranteed at the level they are given, but throughout the whole type construction process.</Paragraph>
    <Paragraph position="19"> Our approach is compatible with the current principled-based approaches to describing languages. This is exemplified in section 4 by the constraints on role and case assignments. In a more general way, the description language we have presented here is particularly appropriate for highly abstract descriptions of language, which corresponds to several current trends in computational linguistics. Our description language is, in the same time, well-adapted to deal with lexical-based approaches to language processing (those approaches like lexicon grammars where the lexicon plays a central role) and to describe representations developed within lexical semantics.</Paragraph>
    <Paragraph position="20"> Finally, a constraint like pending generalises the notion of long-distance dependency to several other kinds of dependencies. This generalization is in particular a consequence of the fact that type structures do not have any ordering on subtypes and they cannot, thus, directly express the difference between remote and close constituents.</Paragraph>
    <Paragraph position="21"> The abstract machine we have described gives a clear procedural semantics to the system. A similar machine can be defined for natural language generation. Our description language has now being fully implemented in Prolog on a SUN workstation following the abstract machine description given above. The first version is an interpreter; a compiler is under development. Experiments with GB theory descriptions (Saint-Dizier 90) have been successfully carried out. It is however important to notice that our formalism is not specifically designed for GB theory and that it can express with the same accuracy other approaches such as HPSGs and lexicon grammars.</Paragraph>
  </Section>
  <Section position="3" start_page="0" end_page="0" type="metho">
    <SectionTitle>
Acknowledgements
</SectionTitle>
    <Paragraph position="0"> This work owes much to discussions with Nabil Hathout.This work was supported by the French</Paragraph>
  </Section>
class="xml-element"></Paper>