We designed a system to study parsing. Our aim was not to implement only one parsing algorithm, but as many as possible, in such a way that we could compare their performances. We wanted to study parsers' behavior rather than using them to exploit their parses. Furthermore, we wanted a system opened to new developments, impossible to predict at the time we began our project.

We achieved these aims by defining a modular architecture that gives us in addition code sharing between alternative implementations.

Our system, called APOC-II, implements more than 60 different parsing algorithms for Context-Free Grammars, Tree-Adjoining Grammars, and Definite-Clause Grammars. The different gener­ated parsers are comparable, because they are im­plemented in the same way, with common data structures. Experimental comparison can involve more than 20 parsers for a given grammar and give results independent from the implementa­tion.

Furthermore, adding new modules multiplies the number of parsing algorithm. APOC-II is open to new parsing techniques to such an extent that it can be seen as a library of tools for parsing, including constraint solvers, look-ahead, parsing strategies and control strategies. These tools make prototyping of parsing algorithms eas­ier and quicker.

The system is based on a general framework that divides parsing matters in three different tasks. First, the compilation that translates a grammar into a push-down automaton describ­ing how a parse-tree is built. The automaton can be non-deterministic if several trees have to be considered when parsing a string. Second, the interpretation of the push-down automaton that has to deal with non-determinism. Third, the constraint solving, used by both compilation and interpretation to perform operations related to constraints.

Several algorithms can perform each of these three tasks: the compiler can generate either top-down or bottom-up automata, the interpreter can make use of backtracking or of tabulation and the solver has to deal with différent kinds of con­straints (first-order terms, features, .. . ).

Our architecture allows different combinations of three components (one for each basic task) re­sulting into a specific parsing system. We use the Alcool-90 programming language to implement our modules. This language's type system allows the definition of alternative implementations of a component and ensures the safety of module combination, i.e. each module provides what is needed by other modules and receives what it re­quires.

The same kind of modularity is used to split the main components (compiler, interpreter, solver) into independent sub-modules. Some of these sub-modules can be shared by several different implementations. For instance the computation of look-ahead is the same for LL(k) and LR(k) techniques.

The next section defines the class of grammar we consider. Then, a general framework for pars­ing and the sort of modularity it requires are pre­sented. Section 4 is devoted to the Alcool-90 lan­guage that provides a convenient module system. Section 5 is the detailed description of the APOC-

II system that implements the general framework using Alcool-90.

The notion of Constraint-Based Grammar ap­peared in computational linguistic. It is a useful abstraction of several classes of grammars, includ­ing the most commonly used to describe Natural Language in view of computer processing.

We give our own definition of constraint-based grammars that may slightly differ from other def­initions.

Definition 1 Constraint-13used Grammar A constraint-hased grammar is a 7-tuple.

• A^f is a set of symbols called non-terminals

• T is a set of symbols called terminals

• a is a function from Nt U T to the. natural integers called the arity of the symbols

• V is an infinite set of variables

• Ax is an element of Nt called the axiom

• CL is a constramt language (see definition be­low) liaving V as variable set and being closed under renaming and conjunction

• R is a finite set of rules of the. form:

a0(Xa)^c,st(Xl),...,sn(Xn).

such that s0 G Nt, .s, eJViU T for 0 < i < n, c G CL, Xi arc tuples of «(.s-;) distinct, vari­ables, and the same, variable cannot appear in two différent tuples.

In this definition, we use the notion of con­straint language to define the syntax and the se­mantics of the constraints used by the grammars. We refer to the definition given by Hofeld and Smolka in [HS88]. This definition is especially suitable for constraints used in NLP (unrestricted syntax, multiplicity of interpretation domains). The closure under renaming property has also been defined by Höfeid and Smolka. It ensures that constraints are independent from the vari­able names. This grounds the systematic renam­ing of grammar rules to avoid variable conflicts.

Definition 2 Constraint Language A constraint Language is a ^-tuple (V,C,v,I) such

• C is a decidable. set. whose, elements arc called constraints

» v is function that associates a finite set of variables to each constraint• 1 is a non-empty set of interpretations

For hick ofspa.ee we do not recall in detail wha t an interpretation and the "closure under renam­ing" property are, and refer to [IIS88].

The semantics of Constraint-Based Grammars is defined by the semantics of the constraint lan­guage and the notion of syntax tree. A syntax tree is a tree which has a grammar rule (renamed with fresh variables) as label of each node. A constraint is associated to a parse tree: it is the conjunction of all the constraints of the labels and the equalities between the tuple of variables from the non-terminal of the left-hand side of a label and the tuple of the relevant symbol of the right-hand side of the label of its parent.

An important point about parse trees is that the order of terminal symbols of the; input string and the order of the symbols in right-hand sides of rules are significant.

A Context-Free Grammar is obtained just by removing tuples and constraints from the grammar rules. Most parsing techniques for Constraint-Based Grammars use the underlying context-free structure to guide parsing. This al­lows the reuse of context-free parsing techniques.

The grammars we have just defined encom­pass several classes of grammars used in NLP, including logic grammars (Definite Clause Gram­mars and variants), Unification Grammars, Tree Adjoining Grammars' and, at least partially, Lexical-Functional Grammars and Head Phrase Structure Grammars. Of course, there are syn­tactical differences between these classes and Constraint-Based Grammars. A simple transla­tion from one syntax to the other is necessary.

:s A General Framework vor Parsing

This section is devoted to a general framework for parsing in which most of the parsing methods, including all the most common ones, are express­ible. It is an extension of a context-free frame­work [La.n74]. It is based on an explicit separation between the parsing strategy that describes how

'TACs have an underlying context-free structure, al­though this is not obvious in their formal definition. See for instance [LanfJl],

syntax trees are built (e.g. top-down, bottom-up), and the control strategy that deals with the non-determinism of the parsing (e.g. backtrack­ing, tabulation).

Alcool-90 is an experimental extension of the functional language ML with run-time overload­ing [RouOO]. Overloading is used as a tool for seamless integration of abstract data types in the ML type system, retaining strong typing, and type inference properties. Abstract data types (encapsulating a data structure represen­tation and its constructors and interpretive func­tions) provide values for overloaded symbols, as classes provide methods for messages in object-oriented terminology. However, strong typing means that the compiler guarantees that errors of kind "method not found" never happen.

Abstract programs are programs referring to overloaded symbols, which values will be deter­mined at run-time, consistently with the calling environment. By grouping abstract programs, we obtain parameterized abstract data types (or functors), the calling environment being here a particular instantiation of the parameterized adt. Thus, we obtain an environment equivalent to a module system, each module being an adt, even­tually parameterized.

For instance, in APOC-II, compilers have an abstract data type parameterized by a solver.

Alcool-90 also proposes an innovative environ­ment where we exploit ambiguities due to over­loading for semi-automated program configura­tion : the type inference computes interfaces of "missing" components to complete a program, ac­cording to the; use of overloaded symbols in the program. A search algorithm finds components satisfying those interfaces, eventually by find­ing suitable parameters for parameterized compo­nents. Naturally, instantiation of parameterized components is also type-safe : actual parameters must have interfaces matching formal parameters (schematically : the actual parameter must pro­vide at least the functions required by the inter­face of the formal parameter).

For instance, only the solvers providing Shieber's restriction can be used as the actual pa­rameter of Farley with restriction compiler. But these solvers can also be used by all the compilers that do not use the restriction.

Simple module systems have severe limita­tions when several implementations of compo­nents with similar interfaces coexist in a system, or when some component may be employed in dif­ferent contexts. Ada generics provided a first stop to module parameterization, though at the cost of heavy declarations and difficulties with type equivalence. SML proposes a very powerful mod­ule system with parameterization, but lacks sepa­rate compilation and still requires a large amount of user declarations to define and use functors. Object-oriented languages lack the type security that Alcool-90 guarantees.

APOC-II is a system written in Alcool-90, imple­menting numerous parsing techniques within the framework described in section 3. The user can choose between these techniques to build a parser. By adding new modules written in Alcool-90 to the library, new techniques can freely be added to the system.

APOC-II has two levels of modularity: the first one is that of the three main components distin­guished above, compiler, interpreter and solver. Each of these components is implemented by sev­eral alternative modules, that are cornbinable us­ing Alcool-90 discipline.

The second level of modularity consist in split­ting each of the three main components into sev­eral modules. This makes the sharing of common parts of different implementations possible.

We give now examples of splitting APOC-II uses at the moment, in order to give an idea of this second level of modularity. This splitting has proved convenient so far, but it is not fixed and imposed to further developments: a new imple­mentation can be added even if it uses a com­pletely different internal structure.

A solver is made of:

• a modide for variables, variable generation and renaming,

• a parser for constraints,

• a pretty-printer for constraints,

• a constraint builder (creation of abstract syn­tax trees for constraints, e.g. building con­straints expressing equality of variables),

• a solver in the restrictive meaning, in charge of constraint reduction,

• an interface that encapsulate all the other modules.

A compiler includes:

• a grammar parser (that uses the constraint parser given by the solver),

• a module for look-ahead (for computation of look-ahead sets by static analysis of the gram­mar),

• a module for EPDA representation and han­dling,

• a transition generator which translates gram­mar rules into EPDA transitions therefore de­termining the parsing strategy (cf. figure 1),

• Control code, using previous modules, defin­ing the "compile" function, the only one ex­ported.

The two interpreters implemented so far have very different structures. The first one uses backtracking and the second one uses tabulation. They share some modules however, such as a module handling transitions and a lexer of input strings.

The interest of the modular architecture is in the combinatorial effect of module composition. It leads to many different parsing algorithms. The figure 1 summarizes the different aspects of the parsing algorithms that can vary more or less independently.

For example;, the built-in parsing method of Prolog for DCCJ.s is obtained by combining the; solver for DCGs, the top-down strategy, 0 sym­bol of look-ahead and a backtracking interpreter (and other modules not mentioneel in figure 1 be;-cause they elo not change the algorithm, but at most its implementation).

Some remarks about figure 1:

• we e:all Earley parsing strategy the way Earley deduction [PW83] builds a tree, not the con­trol method it uses. It differs from top-down by the way constraints are taken into account.

• the difference between Earley-like tabulation and graph-structure stacks is the data struc­ture used for item storage. Several variants are possible, that actually change the parser's behavior.

APOC-II has several advantages. First of all, it provides comparable implementations of the most common parsing algorithms. Their efficiency can be abstractly measured, for instance by counting the number of computation step (EPDA transi­tion application) performed to compute a tree or a complete forest of parse trees. We call this kind of measurements abstract because it does not rely neither on the implementation nor on the machine that runs the parser. Other compar­isons could be done statically, on the automaton or on the parse forest (e.g. number of transitions, amount of determinism, size of the forest, amount of structure sharing).

Otherwise, APOC-II can be used as a toolkit that provides a library of modules useful to imple­ment quickly new parser generators. For instance, one has only to write a solver to obtain up to 22 parsing algorithms (perhaps less if the solver pro­vides only basic operations). The library contains tools to deal with some constraints, look-ahead, lexing, tabulation, etc. Reusing these tools when­ever it is possible saves a lot of work.

The limitations of APOC-II arc that it is mainly convenient for parsing strategies that are some­how static, i.e. statically determined at com­pile time. Also, abstraction (full independence between compilers and interpreters) cannot be achieved for some optimized algorithms. For in­stance, Nederhof presents in [Ned93] a parsing strategy called ELR for which tabular execution can be optimized. To implement this algorithm in our system, one would have to write a new interpreter dedicated to ELR- EPDAs.

We think that our experiment shows the in­terest of a flexible modularity for studies about parsing. We believe that the same technique can fruitfully apply on other domains of Natural Lan­guage Processing.

The authors are grateful to Gabriel Pereira Lopes for his help.