SCSI_ : a linguistic specification language for MT 
paper presented for 
COLING-86 
Bonn, 25-29 August 1986 
by 
R@mi ZAOAC 
GETA, BP 68 
Unlverstt6 de Grenoble 
38402 Sa4nt-Martin-d'H~res, FRANCE 
ABSTRACT Nowadays, Mr systems grow to such a stze that a 
first specification step is necessary if we 
want to be able to master their developement 
and maintenance, for the software part as well 
for the linguistic part ("lingwares"). 
Advocating for a clean separation between 
linguistic tasks and programming tasks, we 
first introduce a specification/ 
implementation/ validation framework for NLP 
then SCSL, a language for the specification of 
analysis and generation modules. 
KEY-WORDS Machine Translation, Natural Language 
Processing, Specification Language. 
I. INTRODUCTION 
In most Nt_P and second generation MT systems, the 
information computed during the process is generally 
represented as abstract trees, very common description 
tools used in linguistics. The modules implementing the 
Various steps are written in Specialized Languages for 
Linguistic Programming (SLLP) (see for example 
<Vauquots85a>, <NakamureB4>, <S\]ocum84>, <Masse4>). 
In spite of the expressive power of SLLP compared to 
tradltionnal programming languages such as LISP, the 
conception and the maintenance of programs become more 
and more difficult as the complexity of "ltngwares" 
grows. 
To take up this challenge, we introduce in the field 
of computational linguistics the specification/ 
Implementation/ validation framework which has been 
proved valuable in tradttionnal programming. This leads 
to the intoductton of new tools and new working methods. 
The expected benefits for computational linguists are 
allowing them to facilitate the conception of the 
linguistic parts of NLP systems, tO increase the speed of 
realisatton, to trnprove the reliability of the final 
system and to facilitate the maintenance. 
Writing an analysis program with a SLLP, the 
computational linguist must define the set of strings to 
be analysed, the structural descriptor corresponding to 
an input string, the strategies used for the computation 
of the descriptor, the heuristics used for ambiguity 
choices and the treatment of wrong Inputs (errors). He 
generally writes a more or less precise and comprehensive 
document on those problems and begin programming from 
scratch. This method is highly unfeasible with large 
lingwares, We advocate for the use of a more stringent 
methodology which consist of : 
I. Specify formally (Ile. using a formal language) the 
valid inputs and the corresponding outputs : the 
specification must be comprehensive and neutral 
with respect to the choices of implementation. At 
this stage, the computational linguist is concerned 
only with linguistic problems, not with 
programming. An interpreter for the specification 
language should be used to write and debug the 
specification. 
2. Specify the implementation choices for data 
structures and control (decompostton into modules, 
strategies and heuristics) and the treatement of 
errors. This specification depends on the 
Input/output specification and may partially depend 
on the ktnd of SLLP to he used for implementation. 
It should be as formal as possible, at least a 
strictly normalized document. 
3. Implement the module specified using a particular 
SLLP. 
4. Validate the implemerltatton : the interpreter of 
the specification language should be used to 
prepare a set of valid inputs/outputs; the results 
of the execution of the module to be validated on 
the input set is compared to ti~e output set. 
An Integrated software environement offering the 
developement tools and Insuring the coherence between the 
developement steps should be provided to facilitate the 
use of the methodology. 
As a first step toward this direction, we introduce a 
linguistic specification language fop which an 
interpreter is being Implemented. Those tools are used 
in the first and fourth steps as defined below and are 
being Integrated in a specialized envlronement based on 
the specification language <Yam86>. 
II. LINGUISTIC SPECIFICATION 
1. A SPECIFICATION FORMALISM 
Before presenting the specification language itself, 
atrial1 consider wllat properties that such a language we 
should have. 
Most problems in NLP systems are found in the analysis 
stage (and some in the transfer stage in MT systems). 
The major gain should be to clarify the analysis stage 
using the proposed framework. Thus, a linguistic 
specification language should : 
define the set of valid input strings; 
define the correspending ouputs (structural 
descriptors of strings); 
define the mapping between those two sets. 
Analysis and synthesis ar'e two complementary views of 
a language defined by a formal grammar. We should 
reasonably expect that a linguistic specification 
language should be equally Llsed for the specification of 
analysis and synthesis modules <KeyS4>. 
Formal grammars define formal languages, and formal 
grammars does not make arly reference tO the situation 
(the global context in which sentences are produced), 
thus formal languages used to describe natural language 
sub-sets must allow the expression of ambiguities and 
paraphrases. An element of the mapping should be a 
couple (string, tree) where many trees are generally 
associated to one string and conversely, many strings are 
associated to one tree. 
The advantage of modularity is admitted and the 
description of the mapping should be done piece by piece, 
each piece describing a partial mapping and the total 
393 
mapping is then obtained by the composition of partial 
mappings (e,g. unification as In FUGs <Kay84>). 
An Important feature of such a language Is that a 
linguistic specification should be wrttten by linguists 
who have no a priori knowledge In computer science : a 
linguist must be able to concentrate only on \]tguisttc 
problems and not on computer sctence problems. The 
formalism should be clean of all computer science 
impurities, the mechanism of composition should be clear 
and simple. 
Within this framework, a graphic formalism for the 
specification of procedural analysis or generation 
grammars, the "Static Grammars" (SG) formalism has been 
developped at GETA under the direction of Pr.B.Vauquois 
<Vauquois85b>. This formalism is now used tn the French 
MT National Project to specify the grammars of an 
lndustrla| English-French system. Up to now, SGs were 
hand-written and cannot be edited on computer because of 
the use of graphs. This formalism has been modified tn 
order to realize a software onvlronement based on SG 
(structural editor, interpreter, graphic outputs .... ). 
It ts called "Structural Correspondence Specification 
Language" (SCSL). A grammar written in SCSL tS called 
"Structural Correspondance Specification Grammar" (SCSG). 
SCSI_ (sect. III) allows one to write the grammar of any 
interesting formal language such as programming languages 
or sub-sets of natural languages. This formalism is quite 
general and does not depend on a particular linguistic 
theory. GETA, under the direction of Pr.B.Vauquois, has 
elaborated its own linguistic framework and methodology 
from which this work directly descends, but it is 
nevertheless perfectly possible to write grammars within 
different linguistic frameworks. We emphasize this point 
because the distinction between the formalism properties 
and the linguistic theory properties ts not always clear. 
Moreover, tt may be tempting to wire the properties of 
some linguistic theory within a particular formalism, and 
this ts sometimes done, leading to confusion. 
2. IMPLEMENTATION AND VALIDATION OF LINGUISTIC MODULES 
As mentioned earlier, a SCSG Is used for the 
specification of analysis or generation modules written 
in one of the SLLP of the ARIANE system. Defining a 
mapping, a SCSG Is neutral with respect to implementation 
choices whicl3 are essentially algorithmic In nature 
(organteation in modules, control, etc) and with respect 
to intrinsic ambiguity choices which are essentially 
heuristic in nature. 
The same SCSG may be used to specify the lnputs/ouputs 
of different procedural grammars, each of which 
implementing different strategies and heuristics for 
comparative purposes • the result must nevertheless 
correspond to the same specification. 
The interpreter (not yet fully implemented) ts used 
for debugging a SCSG (tests, traces .... ) and for the 
empirical validation of procedural grammars for analysis 
or generation: the function computed by a procedural 
grammar must be included tn the mapplng defined by the 
SCSG spectfiying the procedural grammar. 
The interpreter may compute the trees corresponding to 
an input string (analysis) or the strings corresponding 
to an input tree (generation). A chart identifier may 
define an entry point for the interpreter. 
Before en execution, one can type in different trace 
commands. At the end of an execution, the trace and the 
derivation may be printed. 
Qne can trace for different charts (step-by-step or 
otherwise) a tentative application of a chart, a sucess, 
a failure or e combination of these parameters. In the 
step-by-step mode, the interpreter stops on each traced 
trial/sucess/failure and it is possible to type In new 
commands (trace, untraoe, stop) and chose the next chart 
to be applied. 
An output trace element have the following general 
pattern (several levels of details are avaible) : 
<chart td>, <tree_ocourence>, <string_occurence>. 
I I I. THE LANGUAGE 
To give a flavour of the specification language, we 
introduce e simplified version. Unnecessary (but 
essential for practical use) constructs of the language 
are removed. A more abstract view has been studied tn 
<ZehartnB6>. 
A SCSG describe simultaneously : 
the set of strings of the language; 
the set of structural descriptors of the language: 
the mapping between those two sets. 
A SCSG ts composed of "charts". The mapping between 
the string language and the tree language Is decrtbed in 
parts : a chart decrfbes a partial mapping (set of valid 
sub-strings <-> set of valid sub-trees), the total 
mapptng is obtained by the composition of partial 
mappings (sect. IV). 
SCSL Is a language using key-words : every important 
syntactic unit begins with a key-word (e.g. CHART). 
Identifiers begin with at least one letter, designators 
begins with at least one digit. Designators are preceded 
by a prefix indicating their type, 
A SCSG begins with the declaration of labels and 
decorations, and then followed by the charts. Charts 
consist of a tree part and a forest part describing 
respectively a tree pattern and a forest pattern. We 
then have the contexts part and lastly the constraints 
part (sect. III.2). 
SCSL do not have the concept of asstgnement : a chart 
defines correspondence between a tree end a forest 
constrained by a boolean expression on the patterns of 
the chart. 
The basic construct of the language is a labeled and 
decorated tree pattern : each node of the described 
trees is a couple (label, decoration). The label have 
tile string basic type, the decoration have a hierarchical 
definition which use the SCALAR and SET constructors. A 
constraint Is a boolean expression on the labels and 
decorations of tbe nodes of the patterns. 
i. LABEL~ DECORATION AND TREE PATTERNS 
Most of SLLP use trees as basic data structure, Some 
associate to a tree or to a node attributes, essentially 
a set of variable/value pairs which may be manipulated 
with a few operators. To offer a more powerful 
description tool, a SCSL node tree tsa couple (label, 
decoration) where the decoration is a hierarchical 
attribute structure. This ts intended to Facilitate the 
manipulation of complex sets of attributes through a 
unified view. 
t.t. Label 
The label Is traditionally a non-terminal of a 
grammar, but tt may be viewed as a particular attribute 
of a tree. The type definition of labels ts expressed 
with a regular expression. The operation on this type ts 
equality. 
Exem~ : 
LABEL lbl = ( "b".("a")* )+ + "S" + "A" + "B" 
1.2. Decoration 
The decoration is interpreted as an oriented 
non-ordered tree where attribute identifiers (SCALAR or 
SET type) are the labels of the nodes and the values of 
the attributes are the forests that they dominate (in the 
394 
actual verston of SCSL, attributes may have the STRING or 
INTEGER types with the associated operators)• 
For the SCALAR type, the operation is equality, For 
the SET type, the operations are union, Intersection and 
set difference, Relational operators are equality, 
menbership and inclusion. 
The operations are defined on a hierarchical set 
structure : one must indicate on whlch level an operation 
is defined by suffixing the operator with an integer. The 
default value is the first level; "*" is used for the 
deepest level. 
Examples : 
a(b,c(e,f,g(gl,g2))) = a(c(h,f,g),b) ts true 
a a 
I I I I 
b c c b 
___1 =1 I 
I I l I I \[ 
e f g h f g 
a(b,c(e,f,g(gl,g2))) =2 a(d,c(e,g)) Is false 
a 
! I ! I 
b e d c 
I \] ! \[ \[ 
e f g e g 
I ! 
gl g2 
a(b,c(e, 
a 
I I 
b c 
I 
e f g 
gl g2 
f,g(gl,g2))) =* a(c(e,g(gl,g2),f),b) Is true : 
a 
i 
I I 
b c 
e g f 
\[ 
gl g2 
FqY~AE~of decoration for noun phrases : 
DECORATION deco : SET ( 
semantic relation : SCALAR ( 
instrument, quant|fter, qualifier), 
syntactic_function : SCALAR ( 
coordination, governor, subject), 
category : SCALAR ( 
noun : SCALAR ( 
semantic : SET (animate, measure)), 
adjective : SCALAR ( 
ordinal, cardinal, noun phrasequantifier) 
determiner : SCALAR (quantifier), 
subordlnator : SCALAR (preposition) ) 
1.3. free.pattern 
The basic notion of the language is a labeled and 
decorated tree. The types of a node, a tree, a forest are 
defined by the declaration of the labels and the 
decorations. 
A chart should be a comprehensive description of a 
linguistic fact which Bay Ilave different rea\]lsatlons : 
the decoration allow the manipulation of sets of 
attributes at different levels of detat1, the structure 
should describe a whole family of trees, 
The structure of a tree pattern is described wtth 
designators whtch are Implicitly declared. The scope of s 
designator Is reduced to a chart. A designator begins 
wtth one dtgit, 
a node designator is prefixed wtth ,.t,. The content 
of a node is accessed by means of decoration and 
label identifiers : the label of a node .1 is 
accessed by 1b1(.1) (if tile label is declared as 
"}bl"), tts decoration by deco(.1). 
a tree de!~ is prefixed with "~". The tree 
may be reduced to a single node. 
a forest designator Is prefixed with "$". The 
forest may be empty, 
A tree pattern describe a set of trees, each tree 
being completely describe in width and depth. 
E_xarqpIe_ : the pattern .0( $2, .3(.4, $5), $6 ) : 
• 0 
f I I 
$2 .3 $6 
.4 &5 
may be lnstantlated by : 
z~ "0 = a 
............. $2 = b(c,d) , e , f(g) 
I I I I .3 = h 
b e f h ,4 = i 
! I I .... &S = k(i,m) 
i f g ! ~ $6 = 
c d i k 
___l .... 
t 
I m 
tlere, }abels are for a couple (}abel, decorattot)). 
2. CHARTS 
A chart has the following pattern : 
CHART <chart id> 
<TREE> -- tree pattern, 
<FOREST> -- sequence of tree patterns, 
<I_EFT CONTEXT> -- set of cuts of the derivation tree 
<RIGIIT CONTEXT> -- containing the tree pattern. 
<CONSTRAINTS> -- boo\]ean expression on \]abels and 
-- decorations. 
2. I . Tree and forest parts 
The tree part describes a set of trees with the 
following syntax : 
TREE <treepattern> 
The forest part describes a set of sub-strings with 
the following syntax : 
FOREST <forest_pattern> 
The element of the forest pattern may be : 
a string element described direct}y; 
- a sub-string described indirectly using the 
corresponding structure (tree), defined by some 
chart. 
395 
The forest pattern is a sequence of tree patterns 
described by a regular-like notation : a tree pattern 
suffixed by "+" may be iterated, by "?" optional and by 
"*" optional or Iterated. Contrary to regular 
expressions, one can use these notations for single tree 
patterns only. 
TO have stmp\]er notations, an iterated tree pattern, 
e.g, ( .1(.2,,3) )*, w111 be written .1.(,2,.3) and the 
same convention wiil hold for "?" and "+". Such a 
pattern must be used as a whole and is interpreted as a 
list : a boolean expression on nodes of such a pattern 
is interpreted as an expression on the nodes of each tree 
of the list. 
E×amJ~_Le. : .1? , .3,($4) , .5+($6) 
the node designated by .1 may be absent; 
the tree designated by .3($4) may be absent or 
iterated; 
the tree designated by .5($6) must be present and 
may be iterated; 
2.2. Correspondance and constraints 
a~llclt corresJ3ondance between tree and forest 
To avoid the duplication of the same constraints in 
the tree part and in the forest part, we allow the 
followlng notation facility. 
The same node designators in the tree pattern and the 
forest pattern represent distinct objects related to each 
other in the followlng manner : 
if C(T.x) is tile set of constraints on a node T.x of 
the tree part and C(F.x), the set of constraints on the 
node F.x of the forest part, then node T.x verify C(T,x) 
and the constraints of C(F,x) which are not contradictory 
with those of C(T.x) (and conversely for node F.x). 
This relation may also be explicitly stated for nodes 
having different designators using the predeftned CORRES 
function. 
Some formal constraints linking the tree pattern and 
the forest pattern are verified at compile time to ensure 
decidability. 
b) Constraints 
The constraints part is a boolean expression on labels 
and decorations of chart pattern nodes. Ail classical 
boolean operators are available (and, or, exclusive or, 
not, imply, equivalent). 
Designators are prefixed by A for the tree part and F 
for the forest part. An expression using non-prefixed 
designators is interpreted as an expression on the 
designators of the tree part and of tile forest part. The 
designators of context patterns Bust be different from 
the tree part end forest part designators. 
CONSTRAINTS CORRES(T.1, F.4) 
& degre(T.O)=degre(F.4) 
& ( (degre(T.3)~=degreO & degre(F.l)=degre(F.3)) 
V (degre(T.3)=degreO & degre(.1)=degre(.4)) ) 
A tree pattern of the context pattern i8 a member of a 
cut of the derivation tree of the context-free skeleton ; 
a context pattern describes a set of cuts in the 
derivation tree (sect. IV.2). 
A context pattern is a forest pattern where each tree 
pattern may be prefixed by the "not" boolean operator 
("^"), indicating the mandatory absence of the tree 
pattern. Context designators must not be used in other 
parts of the chart. 
Examll3Le ~ : we give some examples of right contexts and 
their interpretations. The constraint 6(.5) is written 
for a boolean expresstom on the label and decoration of 
,5. 
there exists a cut such that the first element of 
this cut verify C : 
RCTX .5($6) CONSTRAINTS C(.5) 
• he first element of each cut verifies C(.5) : 
RCTX ^.5($6) CONSTRAINTS ^C(.S*) 
there exists a cut and there exists an element of 
this cut such that 6(.5) : 
RCTX &4* , .5($6) CONSTRAINTS C(.5) 
......................................................... + 
CHART bx39 
TYPE : simple NOUN PHRASES. 
CASES : absorption of left and right adverbs. 
EXAMPLES : "some of the books", 
"at least two tables". 
TREE .0 ( .17, $5, .2, $6, .37 ) 
FOREST .1? , .0( $5, .2, $6) , .3? 
RCTX .4($7) 
CONSTRAINTS 
-- constraints on tree nodes : 
etiq(T.O)="nps" & k(T,O)=np 
& sf(T,t?)=des 
& sf(T.3?)=des 
-- constraints on forest nodes : 
& etiq(F,O)='np" & k(F.O)=np 
& etiq(F.i?)^="ago '' 
& (cat(F.t)=2 a(npmd) V cat(F.1)=2 a(npqtf)) 
& sf(F.2)=gov 
& cat(F,3?)=2 a(npmd) 
& (EXIST(F.I?) V EXIST(F.3?) ) 
-- EXIST is a predeflned boolean functiqn 
-- testing the existence of an instance : 
-- there must be an instance of .1 or .3 
-- constraints on right context and forest nodes : 
& (EXIST(.3?) => 
(etlq(.4)^:"np '' V ettq(F.3)="ago")) 
FtLguPe t : Example of a simple chart for English 
2.3. Contexts 
A partial mapping described by a chart in a 
context-free manner may be subordinated to contextual 
constraints on the left or right context of the described 
set of sub-strings. This is a powerful tool to describe 
contextual constraints, co-references, wh-movements, etc. 
A context elememt is a sub-string which is described with 
a corresponding tree pattern. 
396 
Instance of tree and forest: patterns for "some of the 
books": 
,0 < .... npc".l .3? <- 
.t? <- "some".2 $5 <- "of".3 , "the".4 
.2 <- "books".5 $6 <- 
.......................................................... + 
I 
bx39 ! 
\[ 
TREE "rips".1 I 
I I 
I \[ 
f I I f l 
f I f i ! 
"some" . 2 "of". 3 "the".4 "books" . 5 1 
? 
"np(:".t : deco(k(np), cat(n) ) 1 
"sonic".2 : deco(cat(a(npqtf)), sf(des) ) l 
"of",3 : deco(cat(s(prep))), sf(reg) ) f 
"the".4 : deco(cat(d), sf(des) ) f 
"books".5 : deco( cat(n(nc)), sf(gov) ) I 
I 
l 
! 
FOREST "np".l ! 
! ! 
f I 
l 1 r ! 
"some",2 "of".3 "the".4 "books".5 ! 
i 
"np".l : deco(k(np), cat(n) ) ! 
"some".2 : deco(cat(a(npqtf)) ) \[ 
"of".3 : deco(cat(s(prep))), sf(reg) ) ! 
"the".4 ; deco( cat(d), sf(des) ) I 
"books".5 : deco(eat(n(no)), sf(gov) ) ! 
! 
F tqure 2 : Chart instance on "some of the books" 
iV. THE DERIVATION MECHANISM 
1. ELEMENT OF 1HE MAPPING 
An element of the mapping defined by a SCSG is a 
couple (string, tree) where the correapondance is defined 
for, each sub tree, 
The string is displayed as a linear graph labeled 
wtth string elements (terminals of the grammar). 
The tree is a correspondance tree : to each node is 
associated a list of paths of the string graph (the 
correspondance ts generally not projective, e.g. 
representing the "respectlvly" construct). 
of the couple for the string "some of the 
books" : 
-i .......................................................... + 
i T 
I bx39 I 
! TREE : l 
I "nps". 1 \[ 
\[ I f 
t ! ~ f \[ I 
T ~ i I ! i 
I "some".2 "of" .3 " the".4 "books" . 5 ! 
f ! 
l"npc".l : deco(k(np), cat(n) ) ; (0,4). ! 
! "some".2 : deco(cat(a(npqtf)), sf(des) ) ; (0, t). l 
I "of".3 : deco( cat(s(prep))), sf(reg) ) ; (t,2). ! 
! "the".4 : deco(cat(d), sf(des) ) ; (2,3). ! 
I "books".5 : deco(cat(n(llc)), sf(gov) ) ; (3,4). \[ 
r 
! SII~ING : I 
, i 
! O- "SOlile".2 -1= "of".3 .2 - "the".4 -3- "books".5 -4 \[ 
! "some".2 : deeo(cat(a(npqtf)) ) (0,1). I 
I "of".3 : deco( cat(s(prep))) ) (1,2). l 
l "the".4 : deco(cat(d) ) (2,3). t 
! "bool{s".5 : deoo(cat(n(llc)) ) (3,4). 1 
4 ........................................................... + 
FQ~Eure 3 : Apilcation of bx39 on "some of the books" 
2. DERIVATION IN THE CONIEXT-FREE FRAMEWORK 
In the context-free fr~,*mework, S chart may be see~l as 
a rule In the PRQLOG \]I fly, your : 
4 ......................................................... 4. 
f t 
I ClIART ( tree, string ) -> r 
! TERMINAL(nodel , sstringt ) \[ 
f <*chart , tree:!, sstrtng2> \[ 
I ! 
I EVAL(constraints) I 
! ARC(tree, string, context) ; \[ 
\[ , \[ 
I .................................................. + 
ClIART ts the chart identifier, 
~\['ee z s trln9~ is the computed couple, 
TERMINAL is a string element definition, 
- *chart ,~ vartable that will be tnstantlated with a 
chart tdenttf let, 
EVAL ts a predicate that evaluate the constra|nts 
part, 
ARC make the reduction and memorize the (:ontexts 
for future evaluation. 
The algort thm of the context-free skeleton is a 
bottom-up version of Earley's algorithm defined and used 
by Qut¢lton <Outnton80> in the KEAL speech recognition 
system. 
For the sake of clarity, the input tape and the 
factorized stack may be represented as a C-graph. 
Executing an analysts, tile Interpreter receives a \]tnear 
labeled C-graph and t~orks by adding on arcs for each 
reduced constituent. An arc Is labeled by a 
correspondance tree, the contexts to be evaluated and 
pointers to the reduced constituents. 
397 
ExamloJe of a derivation tree for the string "some of 
the books". The couple calculated Is written bestde the 
chart identifiers. 
........................................................ 
DERIVATION TREE : 
bx39 < nps(some,of,the,books) (0,4) > 
I 
1 
r I 
"some" bx38 < rips(of,the,books) 1,4) > 
I 
I 1 
"of" bx3? < nps(the,beoka (2,4) > 
I 
! 
I 1 
"the" bx5 < npe(books) (3,4) > 
I 
"books" 
STRING : 
O- "some" -I-- "of" -2- "the" -3 - "books" -4 
F~ 4 : Derivation for "some of the books" 
3. CONTEXT EVALUATION 
A context is evaluated during a traversal of the cuts 
of the derivation tree which go through the node 
containing the couple (string, tree). 
A context pattern memorized on an arc (x, y) describes 
cuts tn the derivation tree. For a C-graph with Input 
node I and output node O, these cuts are represented by 
paths from y to O (for a right context). A right context 
evaluation is thus reduced to the search of a sub-C-graph 
from y to 0. 
V. CONCLUSION 
In the study and developement of future industrial MT 
systems, the definition and Implementation of linguistic 
parts raise many problems partly due to the size of the 
systems, and we hardly need rigorous methods of 
developement. The challenge ts to theorize the line of 
activities which go from the formal specification of an 
Informal problem to the preof of correctness of the 
corresponding program, and this In the field of 
linguistic programming. 
As a first step in this direction, within the 
specification/Implementation/validation framework, a 
software envtronement Is being developed based on a 
linguistic specification language. 
Thts language allows linguists to specify analysis and 
generation modules fop natural language sub-sets and the 
interpreter allows empirical validation ef 
implementations. The language is actually used to specify 
the grammars of the French MT National Project, and for 
all new developements carried out in GETA. 
For further work, extensions are studted, specially 
the specification of transfer modules. Work is also being 
engaged to develop rigorous linguistic programming 
methods using SLLP provided with SCSG specifications. 
References

<Better85> : BOITET C., GUILLAUME P., QUEZEL-AMBRUNAZ 
M. A case atud~ tn software evolution : from ARIANE 
78,4 to ARIANE 85 Proceedlrlgs of the Conference an 
Theoretical and Methodological Issues tn Machine 
Translation of Natural Languages, Colgate University, 
14amtlton, N.-Y., U.S.A, August 14-16, 1989. 

<Kay84> : KAY M. Functtonnal Unification Grammar : a 
formalism for Machine Translation Proceedings of 
COLING-84 

<Mass84> " MAAS H.~D. The MT s stem SUS¥ presented at 
the ISSCO Tutorial on Mac'-hlne Translation, Lugano, 
Switzerland, Aprtl 2-6, 1984. 

<Nakamura84> : NAKAMURA d., TSUdI d., NAGAO M. Grammar 
Nrtttrl~~ of Mu-Machlne Trans~at~ 
Project and its caracterlsttcs Proceedings of 
COLING~84. 

<OutntonSO> : OUINTON P. Contribution A ia 
reconnaissance de la parole. Utllisatton de m~thodes 
heuristi~our \]a reconnaissance de phrases Th~se 
de Docteur as Sciences en Math&mattquea, Universlt6 
de 9ennes, 1980. 

<Slocum84> : SLOCUM d. METAL : the LRC Machine 
translation S~stem presented at the ISSCO futortal on 
Machine Translation, Lugano, S~itzerland, April 2-6, 
1984, 

<Vauquots85a> : VAUOUOIS 8., BO\[~ET C. Automated 
Translation at Grenoble Univers~t~ Computational 
Linguistics, ll/l, pp 28-36, danuary-March 1985. 

<Vauquoi s85b> : VAUQUOI S B. , CHAPPUY S. Static 
Grammars; a formal lsm for the description of 
l tnqutstic models Proceedings of the Conference on 
Theoretical and Methodol ogt ca 1 issues in Machine 
rranslatlon of Natural Languages, Colgate University, 
Itamtlton, N.-Y., U.S.A, August 14-16, 1985. 

<Yan86> : YAN Y. -F. Structural CoP re~ondance 
Stoeclfleatlon Environement ~gs of COLING-86 

<Zaharln86> : ZAI4ARIN Y. Strategies and Heuristics In 
the Analysis of a Na ~1~ L~l u~Lu~ -~a~l i~e 
~a-~on Ph.D. Thesis, Uni~ve~rssitt 5at~nsls M-a~ 
Penang, March i986. Research work under the 
GETA-USMG Cooperation (GETA document). 
