The ConTroll System as Large Grammar Development Platform 
Thilo GStz and Walt Detmar Meurers* 
SFB 340, Universit/it T/ibingen 
Kleine Wilhelmstrafle 113 
72074 T/ibingen 
Germany 
{tg, dm}@sf s. nphil, uni-t uebingen, de 
Abstract 
ConTroll is a grammar development sys- 
tem which supports the implementation 
of current constraint-based theories. It 
uses strongly typed feature structures as its 
principal data structure and offers definite 
relations, universal constraints, and lexical 
rules to express grammar constraints. The 
aspects of ConTroll of relevance to the de- 
velopment of large grammars are discussed 
in detail. The system is fully implemented 
and has been used as workbench to develop 
and test a large HPSG grammar. 
1 Introduction 
ConTroll 1 developed out of the Troll system (Gerde- 
mann et al., 1995). Troll is a phrase structure back- 
bone system very similar to ALE (Carpenter and 
Penn, 1994), but it differs from that system in that 
it is based on the set theoretic logic: of (King, 1989, 
1994) rather than the information theoretic one of 
(Carpenter, 1992). The practical effect of this is 
that Troll implements an exhaustive typing strategy 
which provides the stronger kind of inferencing over 
descriptions (Gerdemann and King, 1993, 1994) re- 
quired by standard HPSG theories. 
We begin with a brief overview of the ConTroll 
architecture as shown in Fig. 1 before focusing on 
the aspects relevant to large scale grammar develop- 
ment. ConTroll supports two basic kinds of gram- 
mar constraints: universal implicational constraints 
*The authors are listed alphabetically. 
1ConTroll was developed in the B4 project of the SFB 
340, funded by the Deutsche Forschungsgemeinschaft 
(DFG). The following people contributed to the develop- 
ment of the system: Dale Gerdemann and Erhard Hin- 
richs (project leaders), Bj6rn Airing, Natali Alt, Carsten 
Hess, John Griffith, Stephan Kepser, Guido Minnen, 
Gerald Penn, Oliver Suhre and Andreas Zahnert. 
with complex antecedents, and definite relations. As 
an example of the first kind of constraint, consider 
the Head Feature Principle of HPSG (Pollard and 
Sag, 1994). This universal constraint can be directly 
encoded in ConTroll as follows: 
phrase, dtrs :headed_struc ==> 
synsem: loc: cat :head: X, 
head_dtr : synsem : loc : cat :head: X. 
The ConTroll system allows a direct implementa- 
tion of HPSG grammars without forcing the grammar 
writer to introduce a phrase structure backbone or 
recode the theories as logic programs. In addition, 
the availability of universal constraints in ConTroll 
also allows for a more modular encoding of tradi- 
tional grammars using a relational backbone. This 
is so since in a relational encoding all subcases need 
to be covered. The universal constraints with com- 
plex antecedents, on the other hand, generalize over 
all occurrences of some data structure and can at- 
tach the constraint to the relevant subset. Universal 
constraints are thus constraint-based in the intuitive 
sense: each structure which is not explicitly excluded 
is well-formed. Internally, the complex antecedents 
of such universal constraints and the occurrences of 
negation are eliminated, which is possible due to the 
exhaustive typing we assume. The resulting type 
constraints are then compiled into definite clauses 
using the method described in (GStz and Meurers, 
1995). 
The second kind of grammar constraints are ordi- 
nary definite clauses with feature term arguments. 
The compiler detects places in which constrained 
types can occur and integrates the type constraints 
into the code by adding calls to the relational en- 
coding of the universal constraints. As described in 
(GStz and Meurers, 1996), the universal constraints 
are integrated in a lazy fashion, i.e. only in case the 
argument of a relation is specific enough to cause 
a conflict with a universal constraint does the com- 
piler attach a call to the universal constraint. Such 
38 
~ 1 Constraints 
/ 
Complex Antecedent end Negation Elimination \[ 
Compilation into Definite Clauses \] 
C 
Grammar RuI~ 
Lcxical Definite Chases 
\] uAndidvlenlgsCleIcl::s~reint" \] 
I Lexical Rule Compiler I / 
Definite Clause Program 
Program Transformation and Code Optimization 
- inlining of deterministic goals 
- conetrelnt propagation - 
indexing 
Specific Interpretation - lazy 
interpretation 
- Earley deduction 
Coroutinlng 
Figure 1: Overview of the ConTroll system 
lazy interpretation has a significant efficiency pay- 
off, especially for large grammars, since it results in 
preferred processing of those constraints in the large 
constraint pool which are specific enough to fail. 
Special mechanisms are included to allow the 
grammar writer to specify how the universal con- 
straints and definite clauses are intended to inter- 
leave in processing (GStz and Meurers, 1997). Most 
importantly, the delay mechanism of ConTroll sup- 
ports coroutining of both universal constraints and 
definite clauses, and it offers a variety of control 
statements to fine tune the execution strategy. This 
is a prerequisite to efficient processing with con- 
straint grammars. 
For the rest of the paper, we will focus on those as- 
pects of ConTroll, which directly address large scale 
grammar development: 
• A graphical user interface: 
- data structure visualization 
- debugging and tracing tool 
• Grammar organization issues: 
- supporting a modular file organization 
- automatic macro detection 
- automatic macro generation 
• Compilation techniques: 
- special compilation of lexica with lexical 
rules for a compact and efficient lexicon 
- incremental compilation and global gram- 
mar optimization 
- arbitrary multiple indexing of constraints 
39 
ConTroll is the only system combining all of these 
features in one architecture. TFS (Emele and Zajac, 
1990) also offered type constraints and relations and 
to our knowledge was the first working typed feature 
systems. However, it had some serious drawbacks. 
TFS did not allow universal constraints with com- 
plex antecedents, but only type constraints. And 
the system did not include a delay mechanism, so 
that it was often impossible to ensure termination 
or efficient processing. 
ALE (Carpenter and Penn, 1994) provides rela- 
tions and type constraints (i.e., only types as an- 
tecedents), but their unfolding is neither lazy, nor 
can it be controlled by the user in any way. This 
can lead to severe termination problems with recur- 
sive constraints. However, the ALE type constraints 
were designed to enhance the typing system, and not 
for recursive computation. 
The definite clause part of our system is very simi- 
lar to the one of cvF (DSrre and Dorna, 1993): both 
use delay statements and preferred execution of de- 
terministic goals. CUF, however, does not offer uni- 
versal constraints. 
2 A graphical user interface 
Two practical problems arise once one tries to im- 
plement larger grammars. On the one hand, the 
complex data structures of such grammars contain 
an overwhelming number of specifications which are 
difficult to present to the user. On the other hand, 
the interaction of grammar constraints tends to get 
very complex for realistic linguistic theories. 
2.1 Data Structure Visualization 
In ConTroll, the powerful graphical user interface 
Xtroll addresses the presentation problem. The 
Xtroll GUI programmed by Carsten Hess allows the 
user to interactively view AVMs, search attributes 
or values in those representations, compare two rep- 
resentations (e.g. multiple results to a query) and 
highlight the differences, etc. Fonts and Colors can 
be freely assigned to the attributes and types. The 
displayed structures (or any part of it) can be can be 
printed or saved as postscript file. The GUI comes 
with a clean backend interface and has already been 
used as frontend for other natural language applica- 
tions, e.g., in the VER.BMOBIL project. 
A special feature of Xtroll is that it offers a mech- 
anism for displaying feature structures as trees ac- 
cording to user specified patterns. Note that dis- 
playing trees is not an obvious display routine in 
ConTroll, since the system does not impose a phrase 
structure backbone but rather allows a direct imple- 
mentation of HPSG grammars whic:h usually encode 
the constituent structure under DTRS or some similar 
attribute. Since trees are a very compact representa- 
tion allowing a good overview of the structure, Xtroll 
allows the user to specify that certain paths under 
a type are supposed to be displayed in a tree struc- 
ture. As labels for the tree nodes, Xtroll can display 
a user definable selection of the following: the fea- 
ture path to the node, the type of the structure, 
the phonology, and finally an abbreviation resulting 
from matching user specified feature structure pat- 
terns. An example for such a tree output is shown 
in Fig. 2. In this tree, the abbreviations were used 
to display category information in an X-bar fashion. 
Clicking on the labels displays the AVM associated 
with this node. In the example, we did open three 
of the nodes to show the modification going on be- 
tween the adjective sehnelles (fast) and the noun 
fahrrad (bike). Note that those attributes which are 
irrelevant to this matter were hidden by clicking on 
those attributes. 
The use of the fully user definable, sophisticated 
display possibilities of Xtroll in our experience have 
turned out to be indispensable for developing large 
typed feature based grammars. 
2.2 A graphical debugger 
The second problem is addressed with a sophisti- 
cated tracing and debugging tool which was devel- 
oped to allow stepwise inspection of the complex 
constraint resolution process. 
The debugger displays the feature structure(s) to 
be checked for grammaticality and marks the nodes 
on which constraints still have to be checked. As a 
result of the determinacy check, each such node can 
also be marked as failed, delayed or deterministic. 
Similar to standard Prolog debuggers, the user can 
step, skip, or fail a constraint on a node, or request 
all deterministic processing to be undertaken. An in- 
teresting additional possibility for non-deterministic 
goals is that the user can inspect the matching defin- 
ing clauses and chose which one the system should 
try. 
For example, in Fig. 3, the selected goal with 
tag \[\] is listed as delayed and is displayed at the 
bottom to have two matching defining clauses out of 
seven possible ones. Using the mouse, the user can 
chose to display the matching or all defining clauses 
in separate windows. 
We believe that the availability of a sophisticated 
debugger like the one implemented for the ConTroll 
system is an important prerequisite for large scale 
grammar development. 
m 
\[\] 
mmm 
m 
m 
m 
m 
m 
m 
\[\] 
m 
mm 
m 
m 
m 
m 
m 
m 
m 
m 
m 
m 
m 
m 
m 
m 
m 
m 
40 
........................................ nl ~" i  ,i  iiiiiiiiiii!!i!ii,i  ,iiii  iliiiiiii i i' i i',i  ,iii  i 
\[n~el~ple..v~rd ~'1 \[h:h~.~r~c }~" <ndmelle~,fd'rracD) 
\[ \[ \[°'*\[ o' head \[\] 
\[r,*siwpleo.~'d A\] \[h*,ei~q~lc.~'d U\] 
head ,~.~ ~ " head ~\]r~.~¢ 
I I I l ~'e~d \[\] ~" 
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: ::~::::::::::~.~. :ili .!:):: "? ::!:::)))))~):~:::~:~:~:~:!::):::?: 
Figure 2: Screen shot of a window showing user configured tree output 
3 Grammar Organization Issues 
3.1 A modular grammar file organization 
To organize grammars in a modular fashion, it is 
important to be able to distribute the grammar into 
several files to permit modification, loading, and 
testing of the different parts of a grammar sepa- 
rately. Also, only a modular file organization allows 
for distributed grammar development since such an 
organization makes it possible to coordinate the 
work on the individual files with software engineer- 
ing tools such as a revision control system. 
ConTroll supports the use of a grammar configu- 
ration file which can contain basic directory and file 
specifications, as well as a more sophisticated system 
allowing the linguist to specify the dependencies be- 
tween signature, theory and lexicon files. 
To find out which signature, theory, and lexicon 
is supposed to be used and in which directories the 
files are supposed to be found, the system looks for 
a grammar configuration file. If such a file is not 
found, default names for the signature and the the- 
ory file are used. If there is a configuration file, it can 
specify the theory, signature, and lexicon files to be 
used, as well as the relevant directories. The down- 
side of this explicit mode of specification is that each 
time one wants to load a part of the grammar, e.g. 
for testing, one needs to realize which files needed 
are needed to test this part of the grammar in or- 
der to be able to list them explicitly. While this 
might seem like a trivial task, our experience has 
shown that in a distributed grammar development 
environment such a complete specification requires 
significant insight into the entire grammar. 
ConTroll therefore provides a more intelligent way 
of specifying the files needed for a module by al- 
lowing statements which make the dependencies be- 
tween the different theory, signature, and lexicon 
files explicit. These specifications were modeled af- 
ter the makefiles used in some programming environ- 
ments. Once the dependencies are provided in the 
configuration file, selecting the parts of the grammar 
to be loaded can be done without having to being 
aware of the whole grammar organization by speci- 
fying one file for each module of the grammar needs 
to be included. The signature, theory, and lexicon 
files which are needed for the selected files are then 
automatically loaded according to the dependency 
specifications. 
3.2 Automatic macro detection 
When writing a typed feature structure based gram- 
mar one usually wants to abbreviate often used fea- 
ture paths or complex specifications. In ConTroll 
41 
this can be done using the definite clause mecha- 
nism. However, from a processing point of view, it 
is inefficient to treat macros in the same way as or- 
dinary relations. We thus implement a fast, purely 
syntactic preprocessing step that finds the relations 
that can be treated as macros, i.e., unfolded at com- 
pile time. These macro relations are then compiled 
into an internal representation during a second pre- 
processing step. When the rest of the grammar is 
parsed, any macro goal will simply be replaced by 
its internal representation. 
After the actual compilation, ConTroll closes the 
grammar under deterministic computation. This 
step must be carefully distinguished from the macro 
detection described above. A goal is determinis- 
tic in case it matches at most one defining clause, 
but a relation is a macro by virtue of its definition, 
irrespective of the instantiation of the actual call- 
ing goals. Of course, the macro detection step can 
be eliminated, since the deterministic closure will 
also unfold all macros. However, for our reference 
grammar, adding the macro detection step reduced 
compile times by a factor of 20. Thus, for large 
grammars, compilation without macros is simply not 
practical. 
Obviously, making automatic macro detection a 
property of the compiler relieves the grammar de- 
veloper from the burden of distinguishing between 
macros and relations, thereby eliminating a poten- 
tial source of errors. 
3.3 Automatic macro generation 
Since HPSG theories usually formulate constraints 
about different kind of objects, the grammar writer 
usually has to write a large number of macros to ac- 
cess the same attribute, or to make the same specifi- 
cation, namely one for each type of object which this 
macro is to apply to. For example, when formulating 
immediate dominance schemata, one wants to access 
the VFORM specification of a sign. When specify- 
ing the valence information one wants to access the 
VFORM specification of a synsem object. And when 
specifying something about non-local dependencies, 
one may want to refer to VFOI~M specifications of 
local objects. 
ConTroll provides a mechanism which automati- 
cally derives definitions of relations describing one 
type of object on the basis of relations describing 
another type of object - as long as the linguist tells 
the system which path of attributes leads from the 
first type of object to the second. 
Say we want to have abbreviations to access 
the VFOR.M of a sign, a synsem, local, cat, and a 
head object. Then we need to define a relation 
accessing the most basic object having a VFORM, 
namely head: vform_h(X-vforra) :== vforra:X. 
Second, (once per grammar) access_suffix and 
access_rule declarations for the grammar need to 
be provided. The former define a naming convention 
for the generated relations by pairing types with re- 
lation name suffixes. The latter define the rules to 
be used by the mechanism by specifying the rele- 
vant paths from one type of object to another. For 
our example the grammar should include the recipes 
shown in Fig. 4. This results in the macros shown 
in Fig. 5 to be generated. 
access_suf f ix (head, "_h" ) . 
access_suf f ix (cat, "_c" ) . 
access_suf f ix (loc, "_l" ) . 
accessnsuf f ix (synsem, ".s" ) . 
access.suf f ix (sign, "someSuff ix" ) . 
acce ss_rule (cat, head, head). 
access.rule (loc, cat ,cat). 
access_rule (synsem, loc, loc). 
access_rule (s ign, synsem, synsem) . 
Figure 4: Macro generation specification 
vform_h(X) :-- vform:X. 
vform_c (X) :-- head: vform_h (X). 
vf orm_l (X) : -- cat : vf orm_c (X). 
vf orm_y (X) : -- loc : vf orm_l (X) . 
vform_s (X) :-- synsem: vform_y (X) . 
Figure 5: Example result of macro generation 
For a large grammar, which usually specifies hun- 
dreds of macros, this mechanism can save a signifi- 
cant amount of work. It also provides a systematic 
rather than eclectic way of specifying abbreviations 
in a grammar, which is vital if several people are 
involved in grammar development. 
4 Compilation techniques for large 
scale grammars 
4.1 Lexical rules for a compact and 
efficient lexicon encoding 
Lexical rules receive a special treatment in ConTroll. 
The lexical rule compiler implements the covaria- 
tion approach to lexical rules (Meurers and Minnen, 
1995). It translates a set of HPSG lexical rules and 
their interaction into definite relations used to con- 
strain lexical entries. In HPSG, lexical rules are in- 
tended to "preserve all properties of the input not 
mentioned in the rule." (Pollard and Sag, 1987, 
p. 314). The lexical rule compiler of the ConTroll 
system to our knowledge is the only system which 
provides a computational mechanism for such lexi- 
cal rules by automatically computing the necessary 
42 
B 
frame predicates accounting for the intended preser- 
vation of properties. Since the lexical rules do not 
need to be expanded at compile time, ConTroll is 
able to handle the infinite lexica which have been 
proposed in a number of HPSG theories. 
Constraint propagation is used as program trans- 
formation techniques on the definite clause encoding 
resulting from the lexical rule compiler (Meurers and 
Minnen, 1996). The relation between parsing times 
with the expanded (EXP), the covariation (cov) and 
the constraint propagated covariation (OPT) lexicon 
for a German HPSG grammar (Hinrichs, Meurers, 
and Nakazawa, 1994) can be represented as OPT : 
EXP : COV = 0.75 : 1 : 18. Thus, the lexical rule 
compiler results not only in a compact representa- 
tion but also in more efficient processing of a lexicon 
including lexical rules. 
4.2 Incremental compilation and global 
grammar optimization 
To keep development cycles short, a fast compiler 
is essential. Particularly when developing a large 
grammar, small changes should not necessitate the 
recompilation of the whole grammar - an incremen- 
tal compiler is called for. This is relatively easy for 
systems where the compilation of individual pieces 
of code does not depend on the rest of the program. 
In ConTroll, this task is complicated for two reasons. 
1. Interaction of universal constraints. If sev- 
eral different universal constraints apply to ob- 
jects of the same type, the compiler will merge 
them together. Changing a single high-level 
constraint may thus necessitate the recompila- 
tion of large parts of the grammar. 
2. Off-line deterministic closure. Since the 
grammar is closed under deterministic compu- 
tation at compile time, a change in some re- 
lation entails recompilation of all clauses that 
have inlined a call to that relation, which in 
turn may lead to changes in yet other relations, 
and so on. Nothing less than the maintenance 
of a complete call graph for the whole grammar 
would enable the compiler to know which parts 
of the grammar need to be recompiled. 
We decided on a compromise for incremental com- 
pilation and made our compiler aware of the first 
sort of dependency, but not the second. This means 
that incremental recompilation is always done on 
the basis of the grammar before deterministic clo- 
sure. Therefore, after incremental recompilation de- 
terministic closure needs to be done for the whole 
grammar. 
4.3 Arbitrary multiple indexing of 
grammar constraints 
ConTroll allows the specification of indexing infor- 
mation for predicates individually. This is compara- 
ble to the indexing of terms in relational databases, 
e.g., the SICStus Prolog external database (Nilsson, 
1995). Figure 6 shows the definition of a two-place 
r(t) **> t. 
r(a) := b. index(r,arg0:t). 
r(a) := c. index(r,argl:t). 
r(b) := c. 
Figure 6: Indexing specification for r 
relation r including a typing declaration and two in- 
dexing instructions. Given a fully instantiated goal 
for the relation r, the run-time environment of Con- 
Troll can deterministically pick the right clause with- 
out leaving behind a choice-point. 
The indexing mechanism not only works for rela- 
tions, but also implicational constraints. Figure 7 
shows possible indexing instructions for the lexical 
index(word,phon:hd:string). 
index(word,synsem:loc:cat:head:head). 
Figure 7: Indexing for the type word 
type word, namely for the phonological form, and 
the syntactic category. 
5 Experience using the System 
Our implementation has been tested with several 
smaller and one large (> 5000 lines) grammar, a 
linearization-based grammar of a sizeable fragment 
of German. The grammar was developed in a dis- 
tributed fashion by eight people and consist of 57 
files. It provides an analysis for simple and complex 
verb-second, verb-first and verb-last sentences with 
scrambling in the Mittelfeld, extraposition phenom- 
ena, wh-movement and topicalization, integrated 
verb-first parentheticals, and an interface to an il- 
locution theory, as well as the three kinds of in- 
finitive constructions (coherent, incoherent, third- 
construction), nominal phrases, and adverbials (Hin- 
richs et al., 1997). 
With grammars this size, it is necessary to pay 
careful attention to control to achieve acceptable 
parsing times. With our Prolog based interpreter, 
parse times were around 1-5 sec. for 5 word sen- 
tences and 10-60 sec. for 12 word sentences. We 
are currently experimenting with a C based com- 
piler (Zahnert, 1997) using an abstract machine with 
a specialized set of instructions based on the WAM 
43 
(Warren, 1983; Ai-Kaci, 1991). This compiler is still 
under development, but it is reasonable to expect 
speed improvements of an order of magnitude. 
6 Summing Up 
We characterized ConTroll as a system supporting 
grammars expressed with definite :relations, impli- 
cational constraints with complex antecedents, and 
lexical rules. To achieve an efficient interpreta- 
tion, implicational constraints are applied in a lazy 
fashion, and interleaving of execution of the differ- 
ent constraints can be determined by the grammar 
writer using delays and other directives. 
We focussed on those properties of ConTroll which 
we take to be indispensable for large scale gram- 
mar development: a graphical user interface for data 
structure visualization, a sophisticated debugging 
and tracing tool, support for a modular file organi- 
zation, a special macro treatment, and finally a set 
of special compilation techniques such as an incre- 
mental compiler, a mechanism dealing with lexical 
rules in an efficient way, and a way to use multiple 
indexing of grammar constraints for efficient access 
to large constraint pools. 

References 
Ai-Kaci, Hassan. 1991. Warren's Abstract Machine. 
MIT Press. 
Carpenter, Bob. 1992. The logic of typed feature 
structures, volume 32 of Cambri~Te Tracts in The- 
oretical Computer Science. Cambridge University 
Press. 
Carpenter, Bob and Gerald Penn. 1994. ALE - The 
Attribute Logic Engine, User's Guide, Version 
2.0.1, December 1994. Technical report, Carnegie 
Mellon University. 
DSrre, Jochen and Michael Dorna. 1993. CUP 
a formalism for linguistic knowledge repre- 
sentation. In Jochen DSrre, editor, Computa- 
tional aspects of constraint based linguistic de- 
scriptions I. DYANA-2 Deliverable R1.2.A, Uni- 
versit~t Stuttgart, August, pages 1-22. 
Emele, Martin C. and R~mi Zajac. 1990. Typed 
unification grammars. In Proceedings of the 13 th 
International Conference on Computational Lin- 
guistics. 
Gerdemann, Dale, Thilo GStz, John Griffith, 
Stephan Kepser, and Frank Morawietz, 1995. 
Troll manual. Seminar fiir Sprachwissenschaft, 
Universit~t Tiibingen, draft edition, October. 
Gerdemann, Dale and Paul John King. 1993. Typed 
feature structures for expressing and computa- 
tionally implementing feature cooccurence restric- 
tions. In Proceedings of 4. Fachtagung der Sektion 
Computerlinguistik der Deutschen Gesellschaft 
fiir Sprachwissenschaft, pages 33-39. 
Gerdemann, Dale and Paul John King. 1994. The 
correct and efficient implementation of appropri- 
ateness specifications for typed feature structures. 
In Proceedings of COLING-94, Kyoto, Japan. 
GStz, Thilo and Walt Detmar Meurers. 1995. Com- 
piling HPSG type constraints into definite clause 
programs. In Proceedings of the Thrirty-Third 
Annual Meeting of the ACL, Boston. Association 
for Computational Linguistics. 
GStz, Thilo and Watt Detmar Meurers. 1996. The 
importance of being lazy - using lazy evaluation 
to process queries to HPSG grammars. In Philipe 
Blache, editor, Actes de la troisi~me confdrenee 
anuelle sur le traitment automatique du langage 
naturel. 
GStz, Thilo and Walt Detmar Meurers. 1997. In- 
terleaving universal principles and relational con- 
straints over typed feature logic. In Proceedings 
of the 35th Annual Meeting of the ACL and the 
8th Conference of the EACL, Madrid, Spain. 
Hinrichs, Erhard, Detmar Meurers, and Tsuneko 
Nakazawa. 1994. Partial-VP and Split-NP top- 
icalization in German -- An HPSG analysis and 
its implementation. Arbeitspapiere des SFB 340 
Nr. 58, Universit~t Tiibingen. 
Hinrichs, Erhard, Detmar Meurers, Frank Richter, 
Manfred Sailer, and Heike Winhart. 1997. Ein 
HPSG-Fragment des Deutschen, Teil 1: Theorie. 
Arbeitspapiere des SFB 340 Nr. 95, Universit~t 
Tiibingen. 
King, Paul John. 1989. A logical formalism for 
head-driven phrase structure grammar. Ph.D. the- 
sis, University of Manchester. 
King, Paul John. 1994. An expanded logical for- 
malism for head-driven phrase structure grammar. 
Arbeitspapiere des SFB 340 Nr. 59, Universit~t 
Tiibingen. 
Meurers, Walt Detmar and Guido Minnen. 1995. 
A computational treatment of HPSG lexical rules 
as covariation in lexical entries. In Proceedings 
of the Fifth International Workshop on Natural 
Language Understanding and Logic Programming, 
Lisbon, Portugal. 
Meurers, Walt Detmar and Guido Minnen. 1996. 
Off-line constraint propagation for efficient HPSG 
processing. In HPSG/TALN Proceedings, Mar- 
seille, France. 
Nilsson, Hans. 1995. The external storage facility in 
SICStus Prolog. Technical report R91:13, Swedish 
Institute of Computer Science• 
Pollard, Carl and Ivan A. Sag. 1987. Information- 
based Syntax and Semantics, Vol. I. Number 13 
in Lecture Notes. CSLI Publications, Stanford 
University. Distributed by University of Chicago 
Press. 
Pollard, Carl and Ivan A. Sag. 1994. Head- 
Driven Phrase Structure Grammar• University of 
Chicago Press, Chicago. 
Warren, David H. D. 1983. An abstract Prolog 
instruction set. Technical note 309, SRI Interna- 
tional. 
Zahnert, Andreas. 1997. fl2c - ein Compiler fiir 
CLP(TFS). Diplomarbeit, Fakult£t fiir Infor- 
matik, Universit£t Tfibingen. 
