A User Friendly A T N Programming Environment (APE) 
tIans Haugeneder, Manfred Gehrke 
Siemens AG, ZT ZTI INF 
W. Germany 
APE is a workbench to develop ATN grammars based on an active chart parser. 
It represents the networks graphically and supports the grammar writer by win- 
(tow- and menu-based debugging techniques. 
1. ATNs - Attractive, but .... 
Augmented Transition Network Grammars are one of 
the frameworks for developing natural language par- 
sers that has been used sueessfully in a large number of 
natural language systems for many languages since its 
introduction in the early seventies by Woods \[WOO 701. 
Three aspects of ATNs, namely applicability in various 
types of natural language systems, suitability for dif- 
ferent languages and the availability of efficient proces- 
sing methods make ATNs an adequate framework for 
practically oriented development of natural language 
parsers. 
Since the time of its introduction the core of the ATN 
formalism has proved to be astonishingly stable and the 
exposition and specification of ATNs given in \[BAT 78\] 
turned out to become a quasi-standard. 
One of the five claims stated there, namely perspicuity, 
deserves some comments, because to us it doesn't seem 
justified strongly. On the contrary we feel that con- 
cerning perspicuity and descriptiveness ATN grammars 
do have some shortcomings. These come into play if you 
use the ATN formalism to develop a grammar for a non- 
trivial subset of a natural language. 
The main reason for this insufficient perspicuity clearly 
lies in the possiblities ATNs offer with respect to local 
and global register setting and testing. These facilities, 
though practically very useful, give an ATN grammar a 
somewhat procedural character, the grammar writer has 
to cope with. In this sense ATNs can be seen as a 
programming language for writing nondeterministic 
programs (grammars). Thus for the development of any 
larger grammars (programs) some sort of programming 
environment for ATNs not only is necessary but also 
compensates the lack of perspicuity and it makes the 
development of ATN grammars a practicable task. 
2. Design Considerations for an ATN Environment 
Examining various ATN environments as \[KEH 80\], 
\[GNE 82\] and \[CHR 831 for example we developed our 
ATN programming environment (APE) along following 
design principles. 
1) The various tools the environment offers must be in- 
tegrated allowing simultaneous grammar editing and 
testing. 
2) The grarmnar editor has to represent the network 
structures graphically allowing the user to access the 
grammar via the contextfree skeleton of the various 
networks. 
3) The desigu of the system should make use of techni- 
ques like multi-windowing, menue- and mouse-based 
interaction facilities, in order to make the system 
usable in an easy manner. 
With this desiderata concerning the design of such a 
system, certain requirements concerning the hardware 
and software fi)r such an implementation are necessary. 
We have chosen Interlisp-D (Trademark of XEROX) as 
basis of APE, which due to its comprehensive display- 
and interaction facilitie:i~ proved to be an adequate 
starting point for the realisa-tion of our ideas. 
3. Active Chart Parsing as a Framework for an 
ATN Environment 
Active Chart parsing (\[KAP 73\]) is a highly general fra- 
mework to implement parsers. The two main ideas of 
this approach are to represent the parser's control struc- 
ture explicitly allowing high flexibility in scheduling the 
various paths to be followed and to prevent the parser 
from doing the same thing twice using a comprehensive 
bookkeeping mechanism. The interaction of these 
components is shown schematically in figure 1. 
PARSER 
Figure 1 
The possibilities of a flexible scheduling is achieved by 
means of an agenda, which at any state of the parser 
contains all the tasks that are induced by the grammar 
and not processed so far. The ordering of the agenda 
thereby determines the way, the search space is 
traversed. With this agenda-based scheduling facility 
the parser can apply various control structures like 
depth-first, breadth-first or heuristic scheduling, even 
changing it during one parse. 
Such facilities are of interest for "tuning" the parser's 
behaviour in an intended way. Agenda-based task sche- 
duling also offers the operational facilities for pruning 
parts of the search space which amounts to switching off 
certain parts of a grammar during a parse. 
The second central concept in active chart parsing, the 
chart, is a graph structure, which does not only do the 
bookkeeping of the parsed constituents (the inactive 
edges). It also records each of the partial intermediate 
steps (the active edges), thus logically representing all 
the paths in work and all constituents parsed so far 
offering the possibility to inspect the uptothen parsing 
process. 
But more important, e.g. for perspicuity, the chart (i.e. 
its graphical representation) also can be seen as a des- 
criptive representation of the parser's state from a naive 
399 
grammar writers' point of view. It is a conceptually 
simple representation, whose atomic constructs, the 
graph's nodes, the active and inactive edges, have clear 
counterparts to the conceptual entities a grammar wri- 
ter has a naive understanding of, namely the positions in 
the sentence to parse (i.e. the nodes), the partial parses 
spawning between two nodes (i.e. the active edges) and 
already analysed constituents (i.e. the inactive edges 
spawning the sequence of words between two nodes). 
Thus a graphical representation of the chart growing as 
the parser proceeds makes the parsing process easily 
perspicuable for the user. 
4. Description of the Environment 
4.1. The Grammar-Editor 
The user interface to the ATN grammar is built on top of 
an active graph-like representation of the single net- 
works, which is initiated by the user in a menu-based 
manner. This bird's eye view gives the user an overall 
first impression of the global structure of the whole 
grammar with the type of the ,arc (PUSH, POP, CAT, 
JUMP) and the specification of categorial" information 
with CAT- and PUSH-arcs. 
Thus the user is not beaten with an unnatural, artificial- 
ly linearized (for example lispish) way to represent the 
basic graph-like concepts of ATNs. The benefits of such 
network-based grammar specification facilities have 
been pointed out by Grimes \[GR175\]. 
The networks, displayed in the way described above, 
additionally offers the user a number of operational 
facilities, such as getting:more specific information on a 
certain arc as for example its actions or additional tests. 
The user can activate the displayed network's arc and 
nodes respectively by clicking the mouse. 
Activating an arc hereby pops a menu with the follo- 
wing possibilities: 
- info: Gives a detailed printout of the arc, including 
its status (broken vs. unbroken). 
- delete: Deletes the arc from the network, causing a 
new graphical layout of the network. 
- edit: Edits the complete arc in a mouse- and menu- 
oriented editor with all necessary facilities to 
modify various parts of the arc, such as tests, 
actions and forms as well as its weight. Lea- 
ving the editor several checks are performed, 
putting the user back into the edit mode, if the 
modified arc structure is incorrect (e.g. if it 
contains too many items or items of an incor- 
rect type at the wrong place). 
- break: Puts a break on the arc taking the user into the 
break mode with interactive facilities (as des- 
cribed below) after the broken arc's actions are 
performed. 
- unbreak: Removes a break from the arc. 
Activating a node in the network offers the following facilities: 
- info: 
- insert: 
Gives a detailed printout of all the arcs star- 
ting at that node. 
Allows the user to insert an arc starting at the 
node activated, the arc's ending node (except 
POP-arcs) being determined via the mouse. To 
introduce additional new nodes the user is 
prompted by the system for subsequent arcs 
until he specifies a POP-arc or an already 
existing node as ending node of the last 
prompted arc. 
400 
- merge: A new node N1 is inserted after node N with 
the leaving arcs of N now beginning at N1 and 
a new arc between N and N1. 
4.2. Grammar-Debugger 
The user can specify in advance certain constructions he 
wants to be parsed, thus having the possiblitiy to test 
certain NP-constructions for example without the over- 
head of parsing a whole sentence. 
These debugging facilities can be involved in three ways: 
primarily while the parser is working in a stepper-mode 
oy means of a user interaction, secondly during the 
parser's run by means of a break put on an grammar arc 
and thirdly system-initiated at the end of the parse 
giving the user the possibility to restart. 
In the stepper-mode the user can cause a break while 
watching the chart growing as the parser processes one 
task after another in the following way. During the 
single steps of creating of the chart graphically the 
system is interruptable to give the user the opportunity 
to put APE's stepper into the break-mode ~oy mouse- 
clicking the relevant menu's item). 
In the break-mode the user is offered a number of 
operational facilities which can be accessed activating 
the chart nodes and edges with the mouse. When selec- 
ting an edge the user can get more detailled info~ana- 
tion as for example its weight, its register environment 
and its history, consisting of the path through the gram- 
mar each arc being augmented with additional informa- 
tion as its current inputword, its register environment 
and the number of the task being responsible for 
processing that arc, which directly reflects the way the 
scheduling is performed. But more importantly the 
~.ammar tester can also modify the edges in various 
dimensions, including the following options: 
- registers: 
- weight: 
- ending edge: 
The user can change registers by emplo- 
ying the same language he is used to as 
a grammar writer, i.e. in terms of 
actions defined in the ATN formalism as 
for example SETRs, ADDRs or form to 
be evaluated such as BUILDQs. 
Allows to change of the weight of an 
edge, affecting the order of further 
processing. 
With this option an edge can be modified 
with respect to the part of the input 
being spanned by it. 
This last option together with the possibilities of regi- 
ster modifying renders for example the simple simu- 
lation of the parser's behaviour under the assumption of 
a (effectively missing or due to not matching tests 
blocked) grammar arc by enlarging the span of an edge. 
Another more powerful possibility in testing a grammar 
is the introduction of additional (in)active edges, con- 
necting two arbitrary nodes, which can be achieved via 
an activation of the starting arc. This allows the speci- 
fication of partial parses or parsed constituents, which - 
though missing due to some defect in the grammar - the 
user wants the to make use of in further parsing process. 
Parallel to all the options presented so far the user can 
edit the grammar on the fly, thus being able to modify 
the grammar just when he recognises certain bugs. 
Additionally APE gives the user the possibilitiy to mani- 
pulate the agenda offering him various actions to be 
performed on the single tasks l!ke freezing and killing a 
task, or changing its weight, this facility provides an 
advanced grammar writer with very effective means to 
focus the parser on things that are interesting for him in 
a certain situation, abondoning with irrelevcnt paths or 
postponing them. 
Finally, when the user has done all the things that 
seemed useful to him at this break point he can continue 
the parsing process leaving the stepper options as they 
are or changing them appropriately. 
At the end of the parsing process the user again gets in a 
break mode giving him the opportunuity of inserting 
new edges with the facility to restart the parsing process 
with this new information. Thus adding a new inactive 
edge and restarting for example amounts to asking the 
parser "what would yours results have been with an 
additional constituent ci from word wj to word Wk?". 
With the facilities described above the user also can 
easily analyse a configuration when the parser did not 
succeed in parsing a certain construction• 
This description, though sketchy, should give an impres- 
sion of the ~acilitities of APE and the ideas behind it. An 
illustration of APE's environment is shown in the appen- 
dix. 
5. Outlook 
The described ATN programming environment gives 
substantial support to the user in building up a working 
grammar, but some of APE's aspects aren't completely 
sattsfymg. ~o a lot of polishing the user interface as well 
as improving the functionality is still to be done. 
Appendix 
Snapshot of the system in the breakmode. 
Primarily we are currently working on an user friendly 
lexicon handling. Another augmentation will be the 
easier global specification of very flne-grained breaks. 
We'd like to thank U. Hochgesand, C. Maienborn and L. 
Simon for implementing parts of the environment and 
the colleagues of our lab fbr many fruitful discussions. 
7. Literature 
\[BAT 78\] Bates, M., "The Theory and Practice of Augmented 
Transition Network Gramnmrs', in: Bole, L. (ed), "Natu- 
ral Language Communication with Computers", Berlin 
1978 
\[CHR 831 Christaller, T., "An ATN Prgramming Environment", 
in: Bolc, L. (ed), '~Phe Design of Interpreters, Compilers, 
and Editors for Augmented Transition Networks", 
Berlin 1983 
\[GNE 82\] Gnefkow, W., "Studien zu einer Programmierumgebung 
ffir Augmented Transition Networks", Memo ANS-3, 
Universitat fIamburg, 1982 
\[Gill 75\] Grimes, J. (ed) "Network Grammars", Summer 
Institute of Linguistics, University of Oklahoma, 1975 
\[KAP 73\] 
Kaplan, R. M., "A General Syntactic Processor", in: 
Rustin, R. (ed), "Natural Language Processing", New 
York 1973 
\[KEH 80\] 
Kehler, T.P., Woods, R.C., "ATN Grammar Modelling in 
Applied Linguistics", Proc. 19th ACL Meeting, 1980 
\[WOO 701 Woods, W.A., '~rransition Network Grammars for Natu- 
ral Language Analysis", Comm.of the ACM 13(10), 1970 
I 
401 
A LANGUAGE FOR TRANSCRIPTIONS 
paper submitted for 
COLING 86 
Bonn 
by 
Yves LEPAGE 
GETA, BP 68 
dntversit~ Sclentirtque et M6dicale de Grenoble 
38402 Salnt-Martln-d'H~res, FRANCE 
(Final draft, April 1986) 
ABSTRACT 
To deal with specific alphabets is a necessity tn 
natural language processing. In Grenoble, thls problem 
is solved with held of transcriptions. Here we present 
a language (LT) designed to the rapid writing of 
passage from one transcription to another (transducers) 
and give some examples of its use. 
KEY-WORDS 
Transcriptions, transducers, multi-alphabet text 
processing, logical and physical processing of texts. 
INTRODUCTION 
In the general framework or natural language 
processing, the possibilities of interfaces provtded by 
the current devices are rather poor, when censtder|ng~ 
for example, the number of alphabets to be used. The 
problem of uppercase/lowercase letters, that of 
non-latin alphabets, not mentioning ideograms, is 
UsUally solved by the use of transcriptions in computer 
science circle dealing wlth natural languages 
<BOITET83>. 
Our idea is to provide a rather simple device 
allowing rapid writing of programs performing the 
passage from one transcription to another (transducers, 
<KAIN72>), with help of a language (LT or Language for 
Transcriptions) based on an abstract automaton. The 
definition and the implementation of this language were 
initiated during an engineering school project 
<MENGAB4>. The work on this Speclallsed Language for 
Linguistic Programming (SLLP) has led to a First 
version <LT85> in the context o£ a GETA/USMG project. 
It has then been extended in the frame of EUROTRA 
contract ETS-5 <ETS5>. 
This paper presents: 
the semantics of LT in automata theory; 
the syntax of LT briefly described; 
Indications on the Implementation; 
some appllcatlons. 
I. SEMANTICS OF I_T IN AUTOMATA THEORY 
input tape ... a <str x> ... a <str x> 
READING HEAD ....... ~ .................. l ........ 
..... I ....... I 
state E q I --> ! q' I 
---t ...... I--- 
writing head ~ 
output tape <str z> <str z> b ..................................... 
Given a state and a character read, the transducer 
goes Into another state and determines which character 
to write onto the output tape (transition). 
Tile most simple transducer is deterministic and 
r~la~r. : 
it has only one input tape and only one output 
tape; 
there is only one way for reading and writing 
(rlghtwards); 
It reads only one symbol at a time; it writes 
only one symbol for one symbol read; 
there are no other objects such as stacks or 
balloons. 
2, THE ABSTRACT AUTOMATON OF LT 
Tile "basic" automaton is extended in LT into three 
directions 
1. availability of the right context by means of two 
reading heads. The transition is function of the 
head ("forward" or "current") used in the reading 
of the input tape. A special transition performs 
the return of the "forward" head onto the 
position of the "current" one. This permits to 
simulates the readlng of the empty string and 
places the abstract automaton or LT in the class 
of tile "sequential transducers" as defined in 
<KAIN72>; 
2. use of the notions of attributes in the states. 
A state Is an etiquette with attributes. The 
values of some attributes are tested before a 
transition (condition) and the values of some 
attributes are changed after (actions). This 
theoretically increases the non-determinism of 
the automaton; 
3. work on strings and not only on characters, which 
sets deflnitlveiy the automaton In the class of 
"sequential transducers". 
1. "BASIC" TRAN~JCER 
Transductlon may be regarded as a simultaneous 
operation of reading and writing, writing being a 
function of reading <AHO,UL?2>, <CHAUCHE74>. A 
transducer Is a machine with an input tape and an 
output tape. 
• .. <str x> <str y> ... <str x'> <str y'> 
...... T ....... I ............. | ........ f ........ 
I ~ ! I 
I I 
I q t --> I q' I 
IAl=ai I I AI =ai ' 1 
.... I ....... I--- 
<sir z> 
...................... <str z'> ....................... 
402 
The bower of the LT automaton 1!; restrained to a 
transducer wlth the following characteristics: 
one input tape and one output tape; 
determinism; 
states defined by etiquettes and attributes; 
two reading heads. 
The abstract LT transducer may b(~ under-used as a 
deterministic ftnlte-state machine. So the class of 
languages which carl be analysed by LT comprises tl~e 
class of regular languages. 
On the contrary to what we wrote in <ETS5>, LF can 
be used to define an accepter of tile famous 
context-dependent language anbncn. It Is the 
semi-regularity which perlnlts to slmul~Lte stacks. This 
means that \[tie class of languages analysed by the 
abstract LT transducer comprises some of the 
cent ex t-dependent languages. 
Using the Chomsl{y hierarchy we say that I_T can 
analyse 
all the languages of class L3; 
some of the languages of class L~; to know If all 
laeguagl.~s In 1_2 can be analysed by LT Is an open 
pr ob 1 em; 
some of the languages of class I_1; 
II. SYNTAX OF. LT 
SUMMARY 
After" a presentation of the synta;~ of the strlngs, 
we introduce the definition of conditions and actions 
based on the attributes. 
With these three objects (strings, conditions and 
actions) we define the rules which serve to write the 
bundles. 
Finally, we sketch the general structure of a I.T 
program. Incidentally, the concrete syntax of LT has 
taken its Inspiration from tllat of Artane--78 <DSEI>. 
J-. ZHB_ _S_! R_I NG$_ 
A string Is a concatenation of simple strings. A 
simple strlng may be a string el characters or 
hexadecimal codes or special symbols for the end of the 
line and tile end of the file. 
Any strlng of a certain length may be read wtth help 
of a speclal designator. 
There exist three other conventions for the output 
tape to des I~nate the same string as read in input , or 
wlth letters only in UDDer-case or lll lower-case. 
2._ THE OON\[!\[TIONS AND~IO~S 
A cgnd l__t _l on Is a first order predicate on the 
attributes, expressed in the usual syntax (logical 
connectors: no, and, or; parentheses allowed). The 
attributes belong to one of the three classes: scalar, 
set or arithmetic (inferior to an upper bound). 
An acU_oP_ can be an assignment of a value to a 
variable, a l~st of actions carried out conditionally, 
or, a block containing a llst of actions. 
Thls notion is extended to three predeflned actions. 
The first has no impact at all oil the semantics of the 
transductton (displaying a message on an auxiliary 
file); the two others, on the contrary, are significant 
for the transduction (displaying a return code on the 
error file and stopping the transductlon; moving the 
"forward" head back to the position of the "current" 
head (seml-regularlty)). 
A rule describes a (;lass of transitions of the 
shape : 
input string / condition == output string / actions . 
the symbol ? at the head of the rule signifies that the 
inpqt string is to be read under the "forward 't head. 
The philosophy of LT |s to put together the possible 
passages from one etlquetto to another into a bundle of 
tile shape: 
de <etlquettel> a <etiquette2> via 
rlllel rule2 . . . ruleN 
4. GENERAL STRUC.TU, RE_OF A _T PROGRAM 
A LT prograln Is divided into sections. 
One mLISt give the lnitlal stair of the automaton. 
Others give the definition of att r!butes and 
their lelttallsatlon. 
Other optional sections define c~n~l~lons, 
a£t.JQDs and LUleA which can be referred to by 
their names in the bundles. 
The other sectlons glve the bundles expltcltely. 
III~_IM@LEMENTAjION 
In order- to facl 11 late prograrrlYH ng in LT, an 
environment for this language was written tn 
Prolog-Cr I ss <PROLOG85> : 
The manager allows the manipulation of LT 
programs. The usua~ functions of an interactive 
environment (PROI_OG, APL) are defined: loading, 
saving, editing, ltsttng .... 
The compiler was Implemented with use of a 
generator Of aoa lyser s inspired from METAL 
<METAL82>, but less powerful. 
The Interpreter Is a mock-up in Prolog which 
works on the abstract trees resulting from 
com#t lat ion. 
The user must specify the files wbtch will be 
the input and output tapes, and the LT program to 
be interpreted. Interactive traces are possible. 
The design of a Pascal version of the 
Interpreter in order to increase the rate of 
execution is currently in work. 
IV. APPLICATIONS 
!~EX~MPL# OF. EBO~BA~ 
To Illustrate the syntax of LT, we glve a blece of 
the program for the analysis Of AnBnCn on the next 
page. 
403 
+ ....................................................... 
I 
letat initial <read_AB> . I 
lvariables 
! lastchar : (A, B, C, EOL) . -- last character read ! 
I** Reading AnBn, reading alternatively A and B under 
t the current and the forward heads respectively. 
Ide <read AB> a <read AB> via 
1 'A' / lastchar = B == / \]astchar := A . 
f? 'B' / lastchar = A == / lastchar := B . 
lde <read AB> a <read BC> vla 
I? 'C' / lastchar = A == / lastchar := C . 
lde <read AB> a <fail> via 
! / ~astchar = B == '*** Rejected string.' eel . 
I -- If not A 
1? / lastchar = A == '*** Rejected string.' eol . 
I -- If neither B nor C 
I 
1,* Readlng of BnCn : same prlnclple as for AnBn. 
! ... 
! 
!~* Final section for the analysis. 
Ide <read C> a <success> via 
I'C' / lastchar = EOL == '*** Valld string.' eol . 
Ide <read C> a <fail> via 
I == '*** Character C missing.' eol . 
+ ........................................................ 
2. TRA~SCRIPTIONS_FOR DIACRITICS LETTERS 
There exists in French a lot of diacritics and 
accents. In the frame of Eurotra, a transcrlptlon for 
the diacritics was proposed. 14ere ts a text in the 
Eurotra Short Transcription and its responding form In 
the actual French orthograph. The passage between the 
two forms was performed by a LT program. 
+ ....................................................... 
! Un certain Moptflory (1533), puts l'Imprlmeur 
I Etienne OGler (out Pubila en 1540 De la Punctuation 
! de la Langue FranclSoyse, blus des accents d'ycelie 
! ) l'employel2rent notarament pour marouer la chute 
I d'un e & l'Intellrteur d'un mot : vrall3ment, 
I patl3na, etc. 
I (Grellvtsse, Le Ben Usage) + ....................................................... 
..................................................... + 
Un certain Montflory (1533), puls l'lmprimeur I 
Etienne Dolet (qul Publla en 1540 De la Punctuation ! 
de la Langue Franooyse, plus des aeoents d'ycelle ) ! 
l'employ~rent notamment pour marquer la chute d'un I 
e & l'lnt~rieur d'un mot : vra~ment, basra, etc. I 
(Gr~vtsse, Le 8on Usage) I ........................................................ + 
3~ PHYSICAL A N_~_GICAL PROCESSING OF TEXTS_ 
The use o# the LT language is not limited to the 
transcrlbtlons; one of Its interesting features, and 
not the least one, is that physical and logical 
processing of texts coutd be. carried out with Its help. 
+ ...................................................... + 
l.sp 2 f 
l.us on f 
IAvant-dernter exemple: I + ..................................................... + 
In the previous text, the first two llnes correspond 
to formatting commands of SCRIBERE (a text formatting 
software developped at GETA and based on SCRIPT, an IBM 
text formatting software, <SCRIBERE85>) Transducers 
have been written which reflect tables o£ lnformations 
about punctuation, formatting commands and structural 
separators. Here Is the result of the application of 
the sequence of those transducers written In LT on the 
fallowlng text. 
404 
l.Sp 2 : type=format,format=paragraph,level=l,start=nol 
1.US on : tYbe=format,format=beg_underlt,level=7, t 
I start=yes,ovi=endunderll l 
IAvant 
I- : level=9,start=no,content=hyphen ! 
fdernter ! 
fexemple I 
I: : tevel=3,start=no,conteot=colon ! 
CONCLUSION 
The language LI defined and implemented as above was 
tested on various examples: 
passages from transcriptions to others (Russian, 
Thai, Greek, ...); 
- logical and physlcal processing of texts; 
analysis of the context dependent language 
AnBnCn. 
Though we Intentionally limited the syntax of LT and 
forced non-determinism In the lnterpretatlon to fit our 
purpose, the power of thls language seems to be rather 
sufficient for the applications it is sbeciallsed In. 

REFERENCES

<AHO,UL72> AHQ Alfred V., ULLMAN Jeffrey D. 
The Theor~ of Parsln~L, Translatlqn aod_C~Ul~q 
Prentice Hall series in Automatic Computation, 
1972. 

<BOITET83> BOITET Christian 
Conve0_L!pEIs de_$&ansc£j#~ toD~puE A~ sais!A et pour' 
\]La r~vlslon de textes ~LL~ Ari#De-78 
Do cu~eetattpn~_~st~m@ r usse~fran~als ver~!~ 
RUB-FRB 
Rapport DRET n ° 41, GETA, Grenoble, d~cembre 1983. 

<CHAUCHE74> CHAUCHE Jacques 
Tr~Es~uct~M~& ~oresc~e~ 
E~des e~ r6all&atlon de Sys~es~ltqu~s aux 
gr_Ammaire& trADsforma$~onnel\]~s 
Th6se d'Etat, Grenoble, d~cembre 1974. 

<DSEI> BOITET Christian, editor 
Le o1~&q_~DJ~s&r Ar laoe-~ d6~982 
(Volume 1, Partle 1 : le logtclel) avrll 1982 
Convention ADI n ° 81/423 
Cab Sogetl Logiclel - GETA-Champollion 

<ETS5> LEPAGE Yves, VAUQUOIS Phtllppe 
LO~L!#J~I a~d~.!c~Q&essir~ of texts 
Eurotra contract ETS5, Part B 
Intermediate report number 2, September 1985 

<KAIN72> KAIN Richard Y. 
~oma~L~_Theorj~: MAcllioe~and L~ 
Mac Gnaw-Hill Computer science-series 1972 

<LT85> LEPAGE Yves 
L~n lan~gAgA_~D~c\[Nc~on~a~e\]u~saleNr 
Internal document, GEFA, September 1985 

<METAL82> MELESE Bertrand 
METAL n lan a e d~p~atton Dour le syst~mA 
M# N_ZO_R 
T.S.I. vol.1, n°4, 1982, pp 275-285 

<MENGA84> MENGA Daniel 
@g_ag&~EaDsduct_jID~LT 
Rapport de trolsl~me annie ENSIMAG, Juin 1984 

<PROLOG85> CRISS-Untverstt6 II 
PR L~ES&~& ex~LeDslon CLqL lan#a~e Prolo_~q 
CRISS-UnlversIt~ II Grenoble, Julllet 1985 

<SCRIBERE85> 8ACHLIT Daniel, VERASTEGUI Nelson 
SCRIBERE 
Internal document, GETA, Aprll 1985 
