*** empty log message ***

* empty log message *
Alain Prouté
1 parent b328018b
Showing 1 changed file with 415 additions and 530 deletions Show diff stats
anubis_dev/library/syntactic_analysis/parser_maker.anubis
@@ -3,7 +3,7 @@
  
                                       The Anubis Project
  
-                                  The Anubis Parser Generator
+                                    The Anubis Parser Maker
  
                                  Copyright (c) Alain Prouté 2006.
  
@@ -11,11 +11,10 @@
  
  
  
-   This is the source file for the Anubis Parser Generator.
-
-   From a  grammar, APM  generates an Anubis  source file  containing a program  (called a
-   parser) able to recognize sentences of  the corresponding language. APM is very similar
-   to the well known UNIX tool 'YACC' (or its GNU equivalent 'BISON').
+   From  a grammar,  APM  (the 'Anubis  Parser  Maker') generates  an  Anubis source  file
+   containing  a  program  (called  a   'parser')  able  to  recognize  sentences  of  the
+   corresponding language. APM is very similar to  the well known UNIX tool 'YACC' (or its
+   GNU equivalent 'BISON').
  
  
  
@@ -60,9 +59,9 @@
       *** (5.3) States as functions. 
  
    *** (6) Putting it all together. 
+      (this is still under construction)
  
-
-               ------------------------------------
+   ---------------------------------------------------------------------------------------
  
  
  
@@ -75,10 +74,9 @@
  
       *** (1.1) In theory. 
  
-   We have two finite (and disjoint) sets of symbols: 'tokens' (also
-   called 'terminals') and 'non terminals'. Here are our notational
-   conventions (used in these explanations only, not in APM source
-   files):   
+   We have two  finite (and disjoint) sets of symbols:  'tokens' (also called 'terminals')
+   and 'non  terminals'. Here are our  notational conventions (used  in these explanations
+   only, not in APM source files):
  
      a, b, c,...  represent tokens
      A, B, C,...  represent non terminals
@@ -88,80 +86,68 @@
      e            represent the empty sequence of grammar symbols
      $            is the end marker (a special additional token)
  
-   A 'grammar rule' (or 'production') has the form: A -> u (this one
-   is called an 'A-production'). In other words, it has a non terminal
-   on the left of the arrow, and a (possibly empty) sequence of
-   grammar symbols on the right of the arrow. Its meaning is that we
-   can produce an expression 'of type' 'A', by concatenating expressions
-   of types X_1...X_k, where u = X_1...X_k. In this interpretation,
-   tokens represent themselves. 
+   A  'grammar rule'  (or 'production')  has  the form:  A ->  u  (this one  is called  an
+   'A-production'). In other words, it has a non  terminal on the left of the arrow, and a
+   (possibly empty) sequence of grammar symbols on  the right of the arrow. Its meaning is
+   that we can produce an expression  'of type' 'A', by concatenating expressions of types
+   X_1...X_k, where u = X_1...X_k. In this interpretation, tokens represent themselves.
  
-   A 'grammar' is a finite set of grammar rules, together with a
-   distinguished non terminal (denoted 'S' in these explanations),
-   called the 'axiom'. The 'language' associated to the grammar is the
-   set of all sequences of tokens which may produce 'S' (we also say
-   that they are 'instances' of 'S'). 
+   A  'grammar' is  a  finite set  of grammar  rules,  together with  a distinguished  non
+   terminal  (denoted 'S'  in  these  explanations), called  the  'axiom'. The  'language'
+   associated to the grammar  is the set of all sequences of  tokens which may produce 'S'
+   (we also say that they are 'instances' of 'S').
  
-   For our convenience, we assume that there is one and only one
-   S-production, and that it has the form: S -> A. Furthermore, S
-   cannot appear in the right hand member of a production. It is
-   trivial to replace a given grammar by a grammar fulfilling these
-   conditions, by adding a new non terminal S, and the single new rule
-   S -> A, where A is the axiom of the original grammar. This
-   operation does not change the corresponding language. It is
-   realized below by the function 'add_S_rule'. 
+   For our convenience, we assume that there is one and only one S-production, and that it
+   has the  form: S  -> A.  Furthermore, S  cannot appear in  the right  hand member  of a
+   production. It  is trivial  to replace a  given grammar  by a grammar  fulfilling these
+   conditions, by adding a new non terminal S, and  the single new rule S -> A, where A is
+   the axiom  of the original  grammar. This operation  does not change  the corresponding
+   language. It is realized below by the function 'add_S_rule'.
  
  
  
  
       *** (1.2) In APM source files. 
  
-   Of course, we need to read grammars from a source file (an APM
-   source file). The denotation for grammars in APM source files is
-   somewhat more complicated, because we must take the values of
-   grammar symbols into account. 
-
-   Indeed, in practice, terminals and non terminals may have
-   values. Hence, we have an Anubis type (the type of syntactical
-   entities) whose alternatives describe the required values (for both
-   terminals and non terminals).
-
-   When the ALG lexer returns a token, this token already has received a
-   value. When the parser reduces a sequence X_1...X_k of grammar
-   symbols, using the production A -> X_1...X_k, it computes the value
-   of A from the values of X_1...X_k. Hence, the denotation for
-   productions should allow the description of this computation. In
-   YACC and BISON, this computation is described (in the language C)
-   within so-called 'actions', which are post-fixed to grammar
-   rules. In APM it is somewhat different. 
+   Of  course, we need  to read  grammars from  a source  file (an  APM source  file). The
+   denotation for  grammars in APM source  files is somewhat more  complicated, because we
+   must take the values of grammar symbols into account.
+
+   Indeed, in  practice, terminals and  non terminals may  have values. Hence, we  have an
+   Anubis type (the type of syntactical entities) whose alternatives describe the required
+   values (for both terminals and non terminals).
+
+   When the ALG lexer  returns a token, this token already has  received a value. When the
+   parser  reduces a  sequence X_1...X_k  of grammar  symbols, using  the production  A ->
+   X_1...X_k,  it computes  the  value  of A  from  the values  of  X_1...X_k. Hence,  the
+   denotation for  productions should allow the  description of this  computation. In YACC
+   and  BISON,  this  computation  is  described  (in the  language  C)  within  so-called
+   'actions', which are post-fixed to grammar rules. In APM it is somewhat different.
  
-   Since APM grammar symbols may be also names of alternatives, they
-   may have operands, and the right hand side X_1...X_k of a
-   production, will be written for example as: 
+   Since APM  grammar symbols may be also  names of alternatives, they  may have operands,
+   and the right hand side X_1...X_k of a production, will be written for example as:
  
        X_1(x,y) X_2(z) X_3 X_4(u,v,w)
  
-   assuming in this example that the grammar symbol X_1 has two
-   operands, X_2 one operand, X_3 no operand and X_4 three operands. 
+   assuming in this example that the grammar symbol X_1 has two operands, X_2 one operand,
+   X_3 no operand and X_4 three operands.
  
-   In this denotation, x, y, z, u, v and w must be symbols. In the
-   automaton produced by APM, they will become resurgent symbols. 
+   In this denotation, x,  y, z, u, v and w must be symbols.  In the automaton produced by
+   APM, they will become resurgent symbols.
  
-   Now, the complete production A -> X_1...X_k will be denoted
-   (assuming the same example):
+   Now,  the  complete production  A  ->  X_1...X_k will  be  denoted  (assuming the  same
+   example):
  
        A(t): X_1(x,y) X_2(z) X_3 X_4(u,v,w).
  
-   where t is a term (or several terms separated by commas), which may
-   make use of the symbols x, y, z, u, v and w. Of course t will be
-   used to compute the value of A when the reduction via this
-   production will occur. The above rule is something like a case in a
-   conditional, except that A(t) which plays the role of the body of
-   case, is written on the left hand side.
+   where t  is a term (or  several terms separated by  commas), which may make  use of the
+   symbols x, y, z,  u, v and w. Of course  t will be used to compute the  value of A when
+   the reduction via this  production will occur. The above rule is  something like a case
+   in a conditional, except that A(t) which plays the role of the body of case, is written
+   on the left hand side.
  
-   Hence, an APM grammar rule is described by the following
-   self-explanatory 'meta-grammar' (the symbol between square
-   brackets is a precedence level):
+   Hence,  an   APM  grammar   rule  is  described   by  the   following  self-explanatory
+   'meta-grammar' (the symbol between square brackets is a precedence level):
  
      GrammarRule     -> Head : Body . 
                      |  Head : Body [ Symbol ] . 
@@ -178,8 +164,8 @@
      Symbols_1       -> Symbol
                      |  Symbol , Symbols_1
  
-   In a 'Head', APM does not read the 'Term', but just keeps track of
-   matching parentheses (not contained within strings). 
+   In a 'Head', APM does not read the 'Term', but just keeps track of matching parentheses
+   (not contained within strings).
  
    Now, an APM source file has the following format:
  
@@ -193,14 +179,13 @@
    postambule (Anubis text)
  
  
-   Both tokens and nonterminals should be acceptable Anubis
-   symbols. Indeed, they must also be names of alternatives in the
-   type of syntactical entities. The name of this type is formed by
-   the concatenation of 'SyntaxTree_' and the name of the
-   parser. Normally it is defined by the user in the preambule. 
+   Both tokens  and nonterminals  should be acceptable  Anubis symbols. Indeed,  they must
+   also be  names of alternatives in  the type of  syntactical entities. The name  of this
+   type  is   formed  by  the  concatenation   of  'SyntaxTree_'  and  the   name  of  the
+   parser. Normally it is defined by the user in the preambule.
  
-   Reading APM grammars is simple enough so that we do not need to use
-   neither ALG nor APM. 
+   Reading APM  grammars is simple enough  so that we do  not need to use  neither ALG nor
+   APM.
  
  
  
@@ -264,14 +249,12 @@ define List($T)
  
    *** (2) Reading APM source files. 
  
-   Below are the functions which enable APM to read source
-   files. There is also some kind of a lexer. Its state is stored into
-   a datum of type 'APM_LexerState'. This lexer keeps track of line
-   numbers, eliminates blank characters, and tokenizes the input into
-   a sequence of 'meta-tokens'.
+   Below are the functions which enable APM  to read source files. There is also some kind
+   of a lexer. Its state is stored into a datum of type 'APM_LexerState'. This lexer keeps
+   track of  line numbers,  eliminates blank  characters, and tokenizes  the input  into a
+   sequence of 'meta-tokens'.
  
-   The meta-tokens we need to recognize in APM source files are the
-   following:  
+   The meta-tokens we need to recognize in APM source files are the following:
  
        symbols
        terms                     (delimited by parentheses)
@@ -283,16 +266,14 @@ define List($T)
        premature end of file     (the legal end of file will be found by
                                   the function copying the postambule)
  
-   They are defined as the alternatives of the type 'MetaToken'. Then,
-   assembling tokens into precedence rules or grammar rules is rather
-   easy. 
+   They are defined  as the alternatives of the type  'MetaToken'. Then, assembling tokens
+   into precedence rules or grammar rules is rather easy.
  
  
  
       *** (2.1) Reading characters. 
  
-   We must read characters in an extended sens, to take the end of
-   file into account. 
+   We must read characters in an extended sens, to take the end of file into account.
  
 type ExChar:
   char(Int8),        //   normal character
@@ -307,8 +288,8 @@ type APM_LexerState:
               Maybe(Int8) unread).      // character possibly 'unread'
  
  
-   Here is how we read a character (returning both the new state of
-   the lexer and the extended character).
+   Here is  how we read  a character (returning  both the new state  of the lexer  and the
+   extended character).
  
 define (APM_LexerState,ExChar)
   read_char
@@ -345,16 +326,15 @@ define (APM_LexerState,ExChar)
          char(c))
     }. 
  
-   Note: 'unreading' a character is done 'by hand' by functions which
-   need to do that. They can do it because they hold the lexer state. 
+   Note:  'unreading'  a character  is  done  'by hand'  by  functions  which  need to  do
+   that. They can do it because they hold the lexer state.
  
  
  
  
       *** (2.2) Reading meta-tokens. 
  
-   While reading grammar rules, we need to recognize several kinds of
-   meta-tokens:
+   While reading grammar rules, we need to recognize several kinds of meta-tokens:
  
 type MetaToken:
   symbol(String),          //    a regular Anubis symbol
@@ -366,12 +346,11 @@ type MetaToken:
   error(Int8),             //    any misplaced character
   premature_end_of_file.   //    self explanatory
  
-   Note: (t), (x,y), (z), etc... are seen as 'term(String)'
-   meta-tokens. This is why parentheses do not appear in the above
-   definition of meta-tokens. 
+   Note:  (t), (x,y),  (z), etc...  are seen  as 'term(String)'  meta-tokens. This  is why
+   parentheses do not appear in the above definition of meta-tokens.
  
  
-   Here is a simple useful test for detecting the beginning of a symbol. 
+   Here is a simple useful test for detecting the beginning of a symbol.
  
 define Bool
   may_begin_symbol
@@ -412,8 +391,8 @@ define Bool
   false. 
  
  
-   The function below reads a symbol whose first characters (at least
-   one) have already been read, and are given in reverse order.
+   The function  below reads a symbol whose  first characters (at least  one) have already
+   been read, and are given in reverse order.
  
 define (APM_LexerState,MetaToken)
   read_symbol
@@ -437,14 +416,12 @@ define (APM_LexerState,MetaToken)
     }. 
  
  
-   The function 'read_string_within_term' is called while reading a
-   string within a term (itself delimited by parentheses). The
-   beginning of the term has already been read. We need to declare
-   'read_term', because the two functions are mutually recursive. In
-   fact 'read_term' calls (terminally) 'read_string_in_term' when the
-   beginning of a string is detected. Similarly, 'read_string_in_term'
-   calls (terminally) 'read_term' when the end of that string is
-   found.
+   The function 'read_string_within_term'  is called while reading a  string within a term
+   (itself delimited by parentheses). The beginning  of the term has already been read. We
+   need to declare 'read_term', because the  two functions are mutually recursive. In fact
+   'read_term' calls (terminally) 'read_string_in_term' when  the beginning of a string is
+   detected. Similarly, 'read_string_in_term' calls  (terminally) 'read_term' when the end
+   of that string is found.
  
 define (APM_LexerState,MetaToken)
   read_term
@@ -486,8 +463,8 @@ define (APM_LexerState,MetaToken)
     }.
  
  
-   The function below reads anything placed between balanced parentheses. The
-   opening parenthese has already been read. 
+   The  function below  reads anything  placed between  balanced parentheses.  The opening
+   parenthese has already been read.
  
 define (APM_LexerState,MetaToken)
   read_term
@@ -582,8 +559,8 @@ define (APM_LexerState,MetaToken)
  
  
  
-   The next function reads the next meta-token from the source file,
-   whatever this meta-token is. 
+   The  next function  reads  the next  meta-token  from the  source  file, whatever  this
+   meta-token is.
  
 define (APM_LexerState,MetaToken)
   read_meta_token
@@ -617,9 +594,8 @@ define (APM_LexerState,MetaToken)
  
       *** (2.3) Reading precedence and association rules. 
  
-   Each token may be assigned a precedence level. A precedence level
-   is an integer, but it is implicit in the APM source file. Only the
-   order of declarations makes sens. 
+   Each token may be assigned a precedence level. A precedence level is an integer, but it
+   is implicit in the APM source file. Only the order of declarations makes sens.
  
    Each declaration has one of the forms:
  
@@ -643,8 +619,7 @@ type ReadPrecRuleResult:
   premature_end_of_file. 
  
  
-   The next function reads (maybe) a sequence of symbols, right
-   delimited by a dot.   
+   The next function reads (maybe) a sequence of symbols, right delimited by a dot.
  
 define (APM_LexerState,Maybe(List(String)))
   read_symbols
@@ -660,9 +635,8 @@ define (APM_LexerState,Maybe(List(String)))
    Note: names are stored in reverse order, but it does'nt matter. 
  
  
-   Now, we read a precedence rule whose keyword has already been
-   successfully read and recognized (and replaced by the corresponding
-   constructor for type 'PrecRule'). 
+   Now, we  read a precedence  rule whose keyword  has already been successfully  read and
+   recognized (and replaced by the corresponding constructor for type 'PrecRule').
  
 define (APM_LexerState,ReadPrecRuleResult)
   read_prec_names
@@ -680,8 +654,8 @@ define (APM_LexerState,ReadPrecRuleResult)
     }.
  
  
-   Here, we read a precedence rule, whose keyword has been read but
-   not yet recognized (it is only a character string at that point). 
+   Here, we read a precedence rule, whose keyword has been read but not yet recognized (it
+   is only a character string at that point).
  
 define (APM_LexerState,ReadPrecRuleResult)
   read_after_prec_keyword
@@ -716,9 +690,8 @@ define (APM_LexerState,ReadPrecRuleResult)
     }. 
  
  
-   Now, we must be able to read a sequence of precedence rules. This
-   is achieved by the following function, which reads precedence rules
-   until a separator (#) is found. 
+   Now, we must  be able to read a  sequence of precedence rules. This is  achieved by the
+   following function, which reads precedence rules until a separator (#) is found.
  
 type ReadPrecRulesResult:
   ok(List(PrecRule)),
@@ -743,10 +716,9 @@ define (APM_LexerState,ReadPrecRulesResult)
     }. 
  
  
-   Now, we can construct precedence tables. The first one gives the
-   precedence level for each token name. The second one gives the
-   association mode for each precedence level. They are lists of
-   the following respective types:
+   Now, we can  construct precedence tables. The first one gives  the precedence level for
+   each  token  name. The  second  one  gives the  association  mode  for each  precedence
+   level. They are lists of the following respective types:
  
         List((String,Int32))
         List((Int32,AssocMode))
@@ -757,8 +729,8 @@ type AssocMode:
   non_assoc. 
  
  
-   The next function constructs the table of association modes from
-   the list of precedence rules. 
+   The next function constructs the table of association modes from the list of precedence
+   rules.
  
 define List((Int32,AssocMode))
   make_assoc_table
@@ -786,8 +758,8 @@ define List((Int32,AssocMode))
   make_assoc_table(l,0). 
  
  
-   The next function constructs the list of entries in the precedence
-   table for just one level. 
+   The next function constructs  the list of entries in the precedence  table for just one
+   level.
  
 define List((String,Int32))
   make_precedence_entries
@@ -803,8 +775,8 @@ define List((String,Int32))
     }. 
  
  
-   The next function constructs the table of precedence levels from
-   the list of precedence rules. 
+   The next function constructs the table of precedence levels from the list of precedence
+   rules.
  
 define List((String,Int32))
   make_precedence_table
@@ -822,8 +794,8 @@ define List((String,Int32))
     }. 
  
  
-   The next function gives the mode for a given precedence level
-   (using the association table). 
+   The next  function gives the mode for  a given precedence level  (using the association
+   table).
  
 define AssocMode
   mode
@@ -843,10 +815,9 @@ define AssocMode
     }. 
  
  
-   The next function checks the precedence table. It consists in
-   verifying that the same name is not present two times, and that no
-   non terminal has an entry in the table (we will see later how to
-   construct the list of names of non terminals). 
+   The next function  checks the precedence table. It consists in  verifying that the same
+   name is not present  two times, and that no non terminal has an  entry in the table (we
+   will see later how to construct the list of names of non terminals).
  
 type CheckPrecResult:
   ok,
@@ -890,8 +861,7 @@ define CheckPrecResult
     }. 
  
  
-   The next function gives the precedence level (if it exists) for a given
-   token name. 
+   The next function gives the precedence level (if it exists) for a given token name.
  
 define Maybe(Int32)
   prec
@@ -911,7 +881,7 @@ define Maybe(Int32)
     }.
  
  
-   The same one, but for a possibly missing name. 
+   The same one, but for a possibly missing name.
  
 define Maybe(Int32)
   prec
@@ -946,9 +916,8 @@ type Symbol:
   non_terminal(String name).   // any non terminal with its name
  
  
-   Grammar rules  A(t) -> u [p] (where p is a possible precedence
-   level: actually, the name of a token) are stored as data of the
-   following type: 
+   Grammar rules A(t) -> u [p] (where p is a possible precedence level: actually, the name
+   of a token) are stored as data of the following type:
  
 type GrammarRule:
   grammar_rule(String                  head,      // A
@@ -956,11 +925,11 @@ type GrammarRule:
                List((Symbol,String))   body,      // u
                Maybe(Int32)            prec).     // precedence level of p
  
-   Note: in the pair (Symbol,String), the second element represents the
-   value of the symbol (if no value is given, it is the empty string). 
+   Note:  in the  pair (Symbol,String),  the second  element represents  the value  of the
+   symbol (if no value is given, it is the empty string).
  
-   Below is a function which reads the right hand side of a grammar
-   rule. We need a type to handle the result of such a reading. 
+   Below is a function  which reads the right hand side of a grammar  rule. We need a type
+   to handle the result of such a reading.
  
 type RightHandResult:
   ok(List((Symbol,String)),        // a correct right hand side has been read
@@ -1023,8 +992,8 @@ define (APM_LexerState,RightHandResult)
     }.
  
  
-   We also need a special type to handle all possible situations in the
-   result of reading a grammar rule.
+   We also need a special type to  handle all possible situations in the result of reading
+   a grammar rule.
  
 type ReadGrammarRuleResult:
   ok(GrammarRule),           // a grammar rule has been read successfully
@@ -1035,8 +1004,8 @@ type ReadGrammarRuleResult:
                              //   reading a parser section
  
  
-   Below is a function which reads a grammar rule whose head
-   (including the colon) has been already read. 
+   Below is  a function which reads  a grammar rule  whose head (including the  colon) has
+   been already read.
  
 define (APM_LexerState,ReadGrammarRuleResult)
   read_after_colon
@@ -1056,8 +1025,8 @@ define (APM_LexerState,ReadGrammarRuleResult)
     }. 
  
  
-   Below is a function which reads a grammar rule whose head has
-   already been read (not including the colon). 
+   Below is a  function which reads a grammar  rule whose head has already  been read (not
+   including the colon).
  
 define (APM_LexerState,ReadGrammarRuleResult)
   read_after_head
@@ -1073,8 +1042,7 @@ define (APM_LexerState,ReadGrammarRuleResult)
   else (ls,syntax_error). 
  
  
-   Below is a function which reads a grammar rule whose head name has
-   already been read. 
+   Below is a function which reads a grammar rule whose head name has already been read.
  
 define (APM_LexerState,ReadGrammarRuleResult)
   read_after_head_name
@@ -1098,7 +1066,7 @@ define (APM_LexerState,ReadGrammarRuleResult)
  
  
  
-   Below is a function, which reads a complete grammar rule from a file. 
+   Below is a function, which reads a complete grammar rule from a file.
  
 define (APM_LexerState,ReadGrammarRuleResult)
   read_grammar_rule
@@ -1145,11 +1113,10 @@ define (APM_LexerState,ReadGrammarRulesResult)
  
       *** (2.5) Finding non terminals. 
  
-   So far, the grammar has been read, but all symbols have been stored
-   as terminals. We must establish the list of names of all non
-   terminals (they simply appear at the head of grammar rules, and
-   change in grammar rules any symbol whose name matches one of these,
-   to a non terminal.
+   So far, the  grammar has been read, but  all symbols have been stored  as terminals. We
+   must establish the list  of names of all non terminals (they  simply appear at the head
+   of grammar  rules, and change  in grammar  rules any symbol  whose name matches  one of
+   these, to a non terminal.
  
  
 define List(String)
@@ -1274,10 +1241,9 @@ define Maybe(One)
  
  
  
-   The next function reads from the first separator to the third
-   (last) one. It also calls the functions which will construct the
-   automaton and dump it into the output file and the log file. Here
-   is what it does:
+   The next function reads from the first separator to the third (last) one. It also calls
+   the functions which will  construct the automaton and dump it into  the output file and
+   the log file. Here is what it does:
  
      - read the name of the parser,
      - read precedence rules, 
@@ -1285,8 +1251,7 @@ define Maybe(One)
      - construct a datum of type 'Grammar',
      - call 'make_parser'
  
-   it returns failure in case of a problem, and success(unique)
-   otherwise. 
+   it returns failure in case of a problem, and success(unique) otherwise.
  
  
 type Grammar:
@@ -1356,10 +1321,9 @@ define Maybe(One)
  
  
  
-   The next function dumps the content of the input file into the output
-   file, until the first separator is found. In other words, it copies
-   the preambule to the output. It does not use the lexer, and must
-   update the line number itself. 
+   The next function dumps  the content of the input file into  the output file, until the
+   first separator  is found. In other  words, it copies  the preambule to the  output. It
+   does not use the lexer, and must update the line number itself.
  
 define Maybe(Int32)
   copy_preambule
@@ -1390,8 +1354,8 @@ define Maybe(Int32)
     }. 
  
  
-   The next function copies the postambule to the output. It does not
-   need to count line numbers. 
+   The next function copies  the postambule to the output. It does  not need to count line
+   numbers.
  
 define One 
   copy_postambule
@@ -1413,9 +1377,8 @@ define One
  
  
  
-   The next function receives the three files (input, output and the
-   log file), reads the grammar and make the automaton. It proceeds in
-   three steps:
+   The next function receives the three files  (input, output and the log file), reads the
+   grammar and make the automaton. It proceeds in three steps:
  
      - copy the preambule to the output, 
      - create a lexer state, read the precedence rules, the grammar
@@ -1462,8 +1425,8 @@ define Maybe(Option)
  
  
  
-   The next function takes the arguments of the command line and
-   separates options from the source file name. 
+   The next  function takes the arguments of  the command line and  separates options from
+   the source file name.
  
 define Maybe((String,List(Option)))
   separate_options
@@ -1508,8 +1471,7 @@ define Maybe((String,List(Option)))
  
  
  
-   Finally, here is the function which is made global. It performs the
-   following tasks:
+   Finally, here is the function which is made global. It performs the following tasks:
  
       - separate options from the source file name (by calling 'separate_options'), 
       - open the source file, 
@@ -1562,31 +1524,28 @@ global define One
    *** (3) Making the parser automaton. 
  
  
-   In order to exemplify our discussion we will refer in the sequel to
-   the following (ambiguous) 'example grammar':
+   In order  to exemplify  our discussion  we will refer  in the  sequel to  the following
+   (ambiguous) 'example grammar':
  
       S -> A
       A -> 
       A -> a
       A -> AA
  
-   Notice that this grammar produces all sequences of a's, including
-   the empty sequence. It is ambiguous since for example the sequence
-   aaa may 'reduce' to S (or 'be derived' from S) in at least two
-   ways: 
+   Notice  that  this  grammar  produces   all  sequences  of  a's,  including  the  empty
+   sequence. It is ambiguous since for example  the sequence aaa may 'reduce' to S (or 'be
+   derived' from S) in at least two ways:
  
       S -> A -> AA -> AAA -> AAa -> Aaa -> aaa
       S -> A -> AA -> Aa  -> AAa -> Aaa -> aaa
  
-   even if we use only 'rightmost' derivations, which means that when
-   we follow the arrows, the non terminal which is replaced is always
-   the rightmost one. It is the case above, as one may easily
-   check. In the first case the tree structure of our sequence is
-   a(aa), while in the second case, it is (aa)a. 
+   even  if we  use only  'rightmost' derivations,  which means  that when  we  follow the
+   arrows, the non terminal which is replaced  is always the rightmost one. It is the case
+   above, as one may easily check. In the first case the tree structure of our sequence is
+   a(aa), while in the second case, it is (aa)a.
  
-   The automaton will realize the first of our two derivations above
-   as follows (the dot represents the current position of reading from
-   the input): 
+   The automaton will realize  the first of our two derivations above  as follows (the dot
+   represents the current position of reading from the input):
  
    .aaa       shift
    a.aa       reduce using rule A -> a 
@@ -1612,26 +1571,24 @@ global define One
    A.         reduce using rule S -> A     (accept)
    S. 
  
-   The ambiguity is realized here by the choice we have in the
-   situation:
+   The ambiguity is realized here by the choice we have in the situation:
  
    AA.a
  
-   We may either reduce using rule A -> AA or shift. 
+   We may either reduce using rule A -> AA or shift.
  
-   However, this grammar is much more ambiguous than this. We could
-   for example have the following sequence:
+   However, this grammar is  much more ambiguous than this. We could  for example have the
+   following sequence:
  
    AA.a       reduce using rule A -> 
    AAA.a      reduce using rule A -> AA
    AA.a
  
-   which is obviously undesirable. In other words, our grammar has not
-   only a shift/reduce conflict, but at least one reduce/reduce
-   conflict. 
+   which is obviously undesirable. In other words, our grammar has not only a shift/reduce
+   conflict, but at least one reduce/reduce conflict.
  
-   If we want to produce the same language (all the sequences of a's)
-   with a non ambiguous grammar, we should use this one:
+   If we want to produce the same language (all the sequences of a's) with a non ambiguous
+   grammar, we should use this one:
  
    S -> A
    A -> 
@@ -1652,18 +1609,16 @@ global define One
  
       *** (3.1) Computing 'First'. 
  
-   Any symbol in a grammar represents a set of sequences of tokens,
-   namely all sequences of tokens which reduce to this symbol. We also
-   say that such a sequence is derived from the symbol, or that it is
-   an 'instance' of the symbol. 
+   Any symbol in a  grammar represents a set of sequences of  tokens, namely all sequences
+   of tokens which reduce to this symbol. We also say that such a sequence is derived from
+   the symbol, or that it is an 'instance' of the symbol.
  
-   To any symbol we associate a finite set of 'extended tokens'. Here
-   an extended token is either 'e' (representing the absence of a
-   token) or a normal token, or the end marker '$'. 
+   To any symbol we associate a finite set of 'extended tokens'. Here an extended token is
+   either 'e' (representing the  absence of a token) or a normal  token, or the end marker
+   '$'.
  
-   By definition, 'First(X)' is the set of all tokens which may come
-   first in an instance of 'X', plus 'e' if the empty sequence is an
-   instance of 'X'.
+   By definition, 'First(X)' is the set of  all tokens which may come first in an instance
+   of 'X', plus 'e' if the empty sequence is an instance of 'X'.
  
    For our example grammar, we have:
  
@@ -1680,10 +1635,9 @@ type ExToken:
   dollar.                   // the end marker
  
  
-   However, computing 'First' in general is not so easy. This is
-   a saturation process. The main work is to compute 'First' for non
-   terminals, since it is trivial for tokens. Here is how we can do
-   this.  
+   However, computing 'First' in general is not so easy. This is a saturation process. The
+   main work is to compute 'First' for non terminals, since it is trivial for tokens. Here
+   is how we can do this.
  
      (1) to each non terminal associate the empty list, i.e put
          First(A) = [ ]. 
@@ -1700,11 +1654,11 @@ type ExToken:
                       - e is not in First(B) then add all of First(B)
                         to First(A). 
  
-   Of course, productions are added to the grammar only for computing
-   'First', not for any other computation. 
+   Of course, productions are added to the grammar only for computing 'First', not for any
+   other computation.
  
-   We also need to compute 'First(X_1...X_k) for any sequence of
-   symbols. This is done by induction on k:
+   We also need to compute 'First(X_1...X_k) for  any sequence of symbols. This is done by
+   induction on k:
  
      First() = [e]
      First(X_1...X_k) =
@@ -1712,8 +1666,8 @@ type ExToken:
        - else First(X_1). 
  
  
-   In practice, we compute only what we call a 'first function', which
-   is an association list:
+   In practice, we compute  only what we call a 'first function',  which is an association
+   list:
  
        [
          (A,[...]),
@@ -1721,12 +1675,12 @@ type ExToken:
          ...
        ]
  
-   of type List((String,List(ExToken))), where 'A', 'B',... are the
-   non terminals, and [...] the list of extended tokens which may come
-   first in an instance of the corresponding non terminal.
+   of type  List((String,List(ExToken))), where  'A', 'B',... are  the non  terminals, and
+   [...]  the  list of  extended  tokens  which  may come  first  in  an instance  of  the
+   corresponding non terminal.
  
-   The next function computes: (l1 -[e]) union l2. However,
-   'e' may belong to l2, and in that case will belong to the result. 
+   The next function computes:  (l1 -[e]) union l2. However, 'e' may  belong to l2, and in
+   that case will belong to the result.
  
 define List(ExToken)
   merge_except_empty
@@ -1746,8 +1700,8 @@ define List(ExToken)
     }.
  
  
-  We will need to convert an extended token to a grammar symbol. 'e'
-  should never be converted. 
+   We will  need to convert  an extended token  to a grammar  symbol. 'e' should  never be
+   converted.
  
 define Symbol
   to_symbol
@@ -1762,8 +1716,8 @@ define Symbol
     }. 
  
  
-   The function below, constructs the initial stage of our 'first
-   function'. In this stage all lists of tokens are empty. 
+   The function below, constructs the initial stage of our 'first function'. In this stage
+   all lists of tokens are empty.
  
 define List((String,List(ExToken)))
   initial_stage
@@ -1777,9 +1731,8 @@ define List((String,List(ExToken)))
     }.
  
  
-   We will also need to find the value of a non terminal (given by its
-   name) in our 'first function'. This search should always be
-   successful.  
+   We will also need to find the value of a non terminal (given by its name) in our 'first
+   function'. This search should always be successful.
  
 define List(ExToken)
   first
@@ -1814,8 +1767,7 @@ define List(ExToken)
     }. 
  
  
-   Finally, we may compute 'First(u)' for any sequence of grammar
-   symbols 'u'. 
+   Finally, we may compute 'First(u)' for any sequence of grammar symbols 'u'.
  
 define List(ExToken)
   first
@@ -1837,11 +1789,10 @@ define List(ExToken)
  
  
  
-   The following function adds a token to a set of tokens in a 'first
-   function'. It is given the extended token 'x' to be added, the
-   name of the non terminal under which it should be added, and the 'first
-   function' into which this operation should be performed. The
-   grammar is not used, but must be transmitted via terminal calls. 
+   The following  function adds a token  to a set of  tokens in a 'first  function'. It is
+   given the extended token  'x' to be added, the name of the  non terminal under which it
+   should  be  added,  and the  'first  function'  into  which  this operation  should  be
+   performed. The grammar is not used, but must be transmitted via terminal calls.
  
 define (List((String,List(ExToken))),List(GrammarRule))
   add
@@ -1864,8 +1815,7 @@ define (List((String,List(ExToken))),List(GrammarRule))
     }. 
  
  
-   The next function tests if a given non terminal may represent the
-   empty sequence. 
+   The next function tests if a given non terminal may represent the empty sequence.
  
 define Bool
   may_be_empty
@@ -1876,8 +1826,8 @@ define Bool
   member(empty,first(name,f)). 
  
  
-   The following function adds all elements of a set of extended
-   tokens to a 'first list' in a given 'first function'. 
+   The following function adds all elements of  a set of extended tokens to a 'first list'
+   in a given 'first function'.
  
 define (List((String,List(ExToken))),List(GrammarRule))
   add_all_of
@@ -1919,8 +1869,8 @@ define (List((String,List(ExToken))),List(GrammarRule))
     }. 
  
  
-   The following function works out one grammar rule for the addition
-   of elements to 'First lists'. 
+   The  following function works  out one  grammar rule  for the  addition of  elements to
+   'First lists'.
  
 define (List((String,List(ExToken))),List(GrammarRule))
   first_work_rule
@@ -1950,10 +1900,9 @@ define (List((String,List(ExToken))),List(GrammarRule))
     }. 
  
  
-   The next function makes one step of completion of first sets (only
-   for non terminals), making one action for each rule in the
-   grammar. We need to return both the 'first function' 'f' and the
-   grammar, because they change during the process. 
+   The next function makes one step of  completion of first sets (only for non terminals),
+   making one  action for  each rule in  the grammar.  We need to  return both  the 'first
+   function' 'f' and the grammar, because they change during the process.
  
 define (List((String,List(ExToken))),List(GrammarRule))
   first_one_step
@@ -1971,7 +1920,7 @@ define (List((String,List(ExToken))),List(GrammarRule))
     }. 
  
  
-  The next function saturates a 'first function'. 
+   The next function saturates a 'first function'.
  
 define (List((String,List(ExToken))),List(GrammarRule),Int32)
   saturate_first
@@ -1988,8 +1937,7 @@ define (List((String,List(ExToken))),List(GrammarRule),Int32)
   else saturate_first(f_new,l_new,count+1). 
  
  
-   We need to extract the list of all non terminals from the
-   grammar. 
+   We need to extract the list of all non terminals from the grammar.
  
 define List(String)
   non_terminals
@@ -2020,8 +1968,7 @@ define List(String)
  
  
  
-   Here is the function which computes the 'first function' associated
-   to a given grammar. 
+   Here is the function which computes the 'first function' associated to a given grammar.
  
 define (List((String,List(ExToken))),Int32)
   first_function
@@ -2041,36 +1988,32 @@ define (List((String,List(ExToken))),Int32)
  
       *** (3.2) Scenarii. 
  
-   As we saw previously, reductions using a grammar rule, occur only
-   on top of stack. If the stack (as far as grammar symbols are
-   concerned) is:
+   As we saw previously,  reductions using a grammar rule, occur only  on top of stack. If
+   the stack (as far as grammar symbols are concerned) is:
  
         ... u
  
-   i.e. if it ends by u (a sequence of grammar symbols), and if there
-   is a production of the form:
+   i.e. if it ends  by u (a sequence of grammar symbols), and if  there is a production of
+   the form:
  
         A -> uv
  
-   then it is possible that after having read an instance of v, we
-   reduce using that rule. Furthermore, the automaton is able to look
-   at the next token to be read (it has one token of
-   'lookahead'). This helps to make decisions, as we will see later,
-   using precedence and association rules. In particular, the
-   automaton knows which token is allowded as the lookahead for a
-   given reduction.
+   then it  is possible  that after having  read an  instance of v,  we reduce  using that
+   rule. Furthermore, the automaton  is able to look at the next token  to be read (it has
+   one token of  'lookahead'). This helps to  make decisions, as we will  see later, using
+   precedence and  association rules.  In particular, the  automaton knows which  token is
+   allowded as the lookahead for a given reduction.
  
-   Hence, we introduce the notion of a scenario. A 'scenario' is a pair,
-   denoted (in these explanations): 
+   Hence, we introduce the notion of a scenario. A 'scenario' is a pair, denoted (in these
+   explanations):
  
       (A ->u.v , (a_1,...,a_k))
  
-   where A -> uv is a production (whose right hand side has been split
-   into two parts u and v, separated by a dot, where u and/or v may be
-   empty), and where (a_1,...,a_k) is a non empty set of tokens.
+   where A ->  uv is a production (whose right  hand side has been split  into two parts u
+   and v, separated by a dot, where u and/or v may be empty), and where (a_1,...,a_k) is a
+   non empty set of tokens.
  
-   In the case of our example grammar, here are all the possible
-   left part of scenarii: 
+   In the case of our example grammar, here are all the possible left part of scenarii:
  
       S -> .A
       S -> A.
@@ -2081,35 +2024,31 @@ define (List((String,List(ExToken))),Int32)
       A -> A.A
       A -> AA.
  
-   That a scenario (A -> u.v, E) is 'possible' in some state s means
-   that the top of stack is described by u (one slot for one symbol),
-   and that reduction using the given grammar rule may occur if the
-   lookahead token (at the time the reduction takes place) belongs to
-   'E'.
+   That a scenario (A -> u.v, E) is 'possible' in some state s means that the top of stack
+   is described by u (one slot for one symbol), and that reduction using the given grammar
+   rule may occur if  the lookahead token (at the time the  reduction takes place) belongs
+   to 'E'.
  
-   It is clear that, the grammar being given as a finite set of rules
-   (and a finite sets of tokens), there is only a finite number of
-   scenarii. 
+   It is clear that,  the grammar being given as a finite set of  rules (and a finite sets
+   of tokens), there is only a finite number of scenarii.
  
    Two scenarii:
  
       (A -> u.v , E)
       (B -> w.t , F)
  
-   are called 'compatible' if either u is a postfix of w, or w a
-   postfix of u. This simply means that there exists a stack for which
-   the two scenarii are possible. The top of that stack must have
-   the longuest of u and w on its top. 
+   are called 'compatible' if either u is a postfix of w, or w a postfix of u. This simply
+   means that  there exists a stack  for which the two  scenarii are possible.  The top of
+   that stack must have the longuest of u and w on its top.
  
    Two scenarii:
  
       (A -> u.v , E)
       (A -> u.v , F)
  
-   are called 'similar' if they have the same left part (same
-   production splitted at the same place). They differ only by the
-   sets of tokens E and F. Two such scenarii may be joined together into
-   the unique scenario:
+   are called 'similar' if  they have the same left part (same  production splitted at the
+   same place). They differ  only by the sets of tokens E and F.  Two such scenarii may be
+   joined together into the unique scenario:
  
       (A -> u.v , G)
  
@@ -2125,9 +2064,9 @@ type Scenario:
            List(ExToken),            // E
            Maybe(Int32)).            // precedence level of grammar rule
  
-   'u' is stored in reverse order, because the most common operation
-   is to kake the head of 'v' and put it in front of 'u', so that the
-   dot in the scenario advances past one grammar symbol. 
+   'u' is stored in  reverse order, because the most common operation  is to kake the head
+   of 'v' and  put it in front of 'u',  so that the dot in the  scenario advances past one
+   grammar symbol.
  
  
  
@@ -2137,30 +2076,25 @@ type Scenario:
  
       *** (3.3) States. 
  
-   A state of our automaton is a finite set of two by two compatible
-   scenarii, which does not contain any two similar
-   scenarii. Intuitively, the scenarii in a state are simply those
-   which are still possible in this state.
+   A state of our automaton is a finite  set of two by two compatible scenarii, which does
+   not contain any  two similar scenarii. Intuitively, the scenarii in  a state are simply
+   those which are still possible in this state.
  
-   The 'core' of a state is what remains if we ignore
-   lookaheads. States which do not differ by the core are called
-   'similar'. 
+   The 'core'  of a state  is what remains  if we ignore  lookaheads. States which  do not
+   differ by the core are called 'similar'.
  
-   Could'nt we consider similar states as equivalent ? The answer is
-   no in theory. But the difference of behavior of the automaton in similar
-   states is negligible in practice. This is the reason why we will
-   identify similar states (merging lists of lookahead for similar
-   scenarii). 
+   Could'nt we consider similar states as equivalent ? The answer is no in theory. But the
+   difference  of  behavior   of  the  automaton  in  similar   states  is  negligible  in
+   practice. This  is the  reason why we  will identify  similar states (merging  lists of
+   lookahead for similar scenarii).
  
-   But let's see what the difference is really. Clearly, since similar
-   states differ only by the lookaheads, the same shift and/or
-   reduces may arise. The difference is only in the decision to make
-   in case of a conflict. However, since the user has plenty of tools
-   to influence such decisions, there is no need to make any
-   distinction between similar states. 
+   But let's see what the difference  is really. Clearly, since similar states differ only
+   by the lookaheads, the  same shift and/or reduces may arise. The  difference is only in
+   the decision to make in case of a conflict. However, since the user has plenty of tools
+   to influence such  decisions, there is no need to make  any distinction between similar
+   states.
  
-   Of course we represent states (up to a certain point) using the
-   type 'List(Scenario)'.  
+   Of course we represent states (up to a certain point) using the type 'List(Scenario)'.
  
  
  
@@ -2185,9 +2119,8 @@ define Bool
   (n1,u1,v1) = (n2,u2,v2). 
  
  
-   The next function takes a scenario 's' and a state, and returns this
-   state from which an eventual scenario similar to 's' has been
-   dropped. 
+   The next function takes  a scenario 's' and a state, and  returns this state from which
+   an eventual scenario similar to 's' has been dropped.
  
 define Maybe(List(Scenario))
   drop_similar
@@ -2229,9 +2162,8 @@ define Bool
     }. 
  
  
-   The next function tests if a list if scenarii contains only
-   scenarii with the splitting dot at the left end (i.e. in front of
-   the right member of the rule). 
+   The next function tests if a list if scenarii contains only scenarii with the splitting
+   dot at the left end (i.e. in front of the right member of the rule).
  
 define Bool
   has_only_front_dots
@@ -2251,9 +2183,8 @@ define Bool
     }.
  
  
-   The next function tests if a given non saturated state has a
-   saturated version similar to some saturated state. It does this
-   without saturating the first state. 
+   The next function tests if a given  non saturated state has a saturated version similar
+   to some saturated state. It does this without saturating the first state.
  
 define Bool
   saturated_is_similar
@@ -2286,18 +2217,17 @@ define Bool
  
        (A -> u.Bv , E)
  
-   (where B is a non terminal), it is possible that the next sequence
-   of tokens to be read matches B. This means that, if B -> w is any
-   B-production, the scenario
+   (where B is a non terminal), it is possible that the next sequence of tokens to be read
+   matches B. This means that, if B -> w is any B-production, the scenario
  
        (B -> .w, ?)
  
-   should also be possible in the same state. Now, what are the
-   acceptable lookaheads for this scenario ? They are obviously all
-   the tokens which may begin an instance of va, for any a in E.
+   should also be possible in the same  state. Now, what are the acceptable lookaheads for
+   this scenario ?  They are obviously all the  tokens which may begin an  instance of va,
+   for any a in E.
  
-   This remark provides a procedure for 'saturating' states. A state
-   is 'saturated' if whenever it contains:
+   This remark  provides a procedure  for 'saturating' states.  A state is  'saturated' if
+   whenever it contains:
  
        (A -> u.Bv , (a_1,...,a_k))
  
@@ -2308,8 +2238,8 @@ define Bool
  
    for all B-productions B -> w. 
  
-   In the sequel, we will compute saturated states, but states are
-   often more conveniently represented by their non saturated version. 
+   In the sequel, we will compute saturated states, but states are often more conveniently
+   represented by their non saturated version.
  
  
    Below is a function which computes    union First(va_i):
@@ -2329,11 +2259,10 @@ define List(ExToken)
     }.
  
  
-   The next function tests if a given state is similar to some state
-   in a given list of states. This is needed for our saturation
-   process, because we must not add to a state a scenario which
-   already belongs (maybe in a similar form) to that state. Otherwise,
-   our process would never end. 
+   The next function  tests if a given state is  similar to some state in  a given list of
+   states. This is needed for our saturation process, because we must not add to a state a
+   scenario which already belongs (maybe in  a similar form) to that state. Otherwise, our
+   process would never end.
  
 define Bool
   already_present
@@ -2351,10 +2280,9 @@ define Bool
     }.
  
  
-   The next function is given a (new) scenario to be inserted
-   into a list of scenarii. If this list contains a similar scenario,
-   the new scenario is just merged to that one. Otherwise, it is
-   simply added to the list. 
+   The next function is given a (new) scenario  to be inserted into a list of scenarii. If
+   this  list contains  a  similar  scenario, the  new  scenario is  just  merged to  that
+   one. Otherwise, it is simply added to the list.
  
 define List(Scenario)
   insert_scenario
@@ -2375,8 +2303,8 @@ define List(Scenario)
     }.
  
  
-   The next function extracts the symbols from the right hand side of
-   a grammar rule (dropping the 'term' part).
+   The next  function extracts  the symbols  from the right  hand side  of a  grammar rule
+   (dropping the 'term' part).
  
 define List(Symbol)
   symbols
@@ -2391,9 +2319,8 @@ define List(Symbol)
     }.
  
  
-   The following function adds to a given state 's', all the scenarii
-   of the form (B -> .w , F), for all B-productions. The set of
-   lookaheads F is given. 
+   The following function adds to a given state 's', all the scenarii of the form (B -> .w
+   , F), for all B-productions. The set of lookaheads F is given.
  
 define List(Scenario)
   add_scenarii
@@ -2429,24 +2356,20 @@ define List(Scenario)
  
  
  
-   The next function performs one step in the saturation of a
-   state. This step consists in a loop on all scenarii in the
-   state. The list l is the list of scenarii which have not yet been
-   used for saturation, while 'all' is the set of all known scenarii
-   in the state at any time. 
+   The next function performs one step in the saturation of a state. This step consists in
+   a loop on all scenarii in the state. The  list l is the list of scenarii which have not
+   yet been used for saturation, while 'all' is the set of all known scenarii in the state
+   at any time.
  
-   For each scenario ('sc1' below), of the form (A -> u.v , E), we
-   first check the form of 'v'. If 'v' is empty the scenario does not
-   participate to saturation, and we just re-enter the loop with the
-   tail of 'l' instead of 'l'. 
+   For each scenario ('sc1' below), of the form (A -> u.v , E), we first check the form of
+   'v'. If  'v' is  empty the  scenario does not  participate to  saturation, and  we just
+   re-enter the loop with the tail of 'l' instead of 'l'.
  
-   If 'v' is not empty, it has a first symbol ('_B' below). This _B
-   cannot be a $. If it is a token, the scenario does not participate
-   to saturation, like above. 
+   If 'v' is not empty,  it has a first symbol ('_B' below). This _B  cannot be a $. If it
+   is a token, the scenario does not participate to saturation, like above.
  
-   Now, if _B is a non terminal, we add to 'all' all the scenarii
-   derived by the previous function from B-productions, and we continue
-   our loop. 
+   Now, if _B is a non terminal, we  add to 'all' all the scenarii derived by the previous
+   function from B-productions, and we continue our loop.
  
 define List(Scenario)
   saturate_state_one_step
@@ -2487,8 +2410,8 @@ define List(Scenario)
     }.
  
  
-   Now, saturating a state is just performing saturation steps until a
-   step does not change the state any more. 
+   Now,  saturating a state  is just  performing saturation  steps until  a step  does not
+   change the state any more.
  
 define List(Scenario)
   saturate_state
@@ -2511,69 +2434,56 @@ define List(Scenario)
  
       *** (3.6) The initial state. 
  
-   The non terminal S represents the totality of what we want to read
-   from the input. More precisely, if the input is correct, it is an
-   instance of S. Hence, since there is only one S-production S -> A,
-   our reading (if successful) will end by a reduction via this rule,
-   and it will be correct if and only if the lookahead token is the
-   end marker: $.
+   The non terminal S represents the totality of what we want to read from the input. More
+   precisely, if the input is correct, it is  an instance of S. Hence, since there is only
+   one S-production S ->  A, our reading (if successful) will end  by a reduction via this
+   rule, and it will be correct if and only if the lookahead token is the end marker: $.
  
-   Hence, at the beginning, there is obviously one and only one
-   wanted scenario, which is:
+   Hence, at the beginning, there is obviously one and only one wanted scenario, which is:
  
       (S -> .A , ($))
  
-   This scenario (which will be called the 'initial scenario') needs
-   to belong to the initial state. In fact, the initial state is
-   simply the smallest saturated state which contains this
-   scenario. In the case of our example, this saturated state will be
-   (after two steps of saturation):
+   This scenario  (which will  be called the  'initial scenario')  needs to belong  to the
+   initial state. In fact, the initial  state is simply the smallest saturated state which
+   contains this scenario. In the case of our example, this saturated state will be (after
+   two steps of saturation):
  
       (S -> .A  , ($))
       (A -> .   , (a,$))
       (A -> .a  , (a,$))
       (A -> .AA , (a,$))
  
-   Note that the rule S -> A appears only one time in the
-   initial state since the state saturation process cannot produce a
-   scenario using this rule. 
-
-   Now the state generation process will produce a state with the
-   scenario (S -> A. , ($)). Obviously, we cannot have other scenarii
-   using this rule. 
-
-   The state which contains the scenario (S -> A. , ($)) is our
-   'accepting state'. Indeed, the input has been read entirely only
-   when we are on the point to reduce using this scenario. In that
-   case the next token to be read is the end marker, and we 'accept'
-   the input. 
-
-   However, we may have a reduce/reduce conflict with this
-   scenario. It is the case in our example grammar. Indeed, in state
-   2 (see below), and if the next token to be read is the end marker,
-   we may either reduce using the scenario (S -> A. , ($)) or the
-   scenario (A -> . , (a,$)). Notice that it is not possible to have a
-   shift/reduce conflict with scenario (S -> A. ,($)), because the
-   token '$' cannot be shifted (it cannot appear in the right member
-   of a rule).  
-
-   Of course the user cannot choose between these two reductions
-   because he does'nt know about the existence of rule S -> A. 
-
-   Nevertheless, in that case, we avoid the conflict by reducing
-   systematically using rule (S -> A. , ($)). This may be justified as
-   follows. 
-
-   The initial state contains the initial scenario, and scenarii
-   obtained by saturation, i.e. with the dot in front of the right
-   member. Hence the accepting state may only contain the accepting
-   scenario, scenarii of the form (? -> A.? , ?) (because we make a
-   transition on A between the two states), and scenarii with the
-   dot in front of the right member. Hence all scenarii in the
-   accepting state have at most one symbol on the left of the
-   dot. This means that if a reduce/reduce conflict arises between the
-   accepting scenario and another scenario, this other scenario is
-   either of the form:
+   Note that the  rule S -> A appears only  one time in the initial  state since the state
+   saturation process cannot produce a scenario using this rule.
+
+   Now the  state generation process  will produce a  state with the  scenario (S ->  A. ,
+   ($)). Obviously, we cannot have other scenarii using this rule.
+
+   The state which contains the scenario (S -> A. , ($)) is our 'accepting state'. Indeed,
+   the input  has been read entirely  only when we are  on the point to  reduce using this
+   scenario. In that case the next token to be read is the end marker, and we 'accept' the
+   input.
+
+   However, we may have a reduce/reduce conflict with this scenario. It is the case in our
+   example grammar. Indeed,  in state 2 (see below),  and if the next token to  be read is
+   the end marker, we may either reduce using the scenario (S -> A. , ($)) or the scenario
+   (A -> . ,  (a,$)). Notice that it is not possible to  have a shift/reduce conflict with
+   scenario (S -> A.  ,($)), because the token '$' cannot be  shifted (it cannot appear in
+   the right member of a rule).
+
+   Of course the  user cannot choose between these two reductions  because he does'nt know
+   about the existence of rule S -> A.
+
+   Nevertheless, in that case, we avoid the conflict by reducing systematically using rule
+   (S -> A. , ($)). This may be justified as follows.
+
+   The initial state  contains the initial scenario, and  scenarii obtained by saturation,
+   i.e. with  the dot in  front of the  right member. Hence  the accepting state  may only
+   contain the accepting scenario, scenarii of the form  (? -> A.? , ?) (because we make a
+   transition on  A between the  two states), and  scenarii with the  dot in front  of the
+   right member. Hence all scenarii in the  accepting state have at most one symbol on the
+   left  of the  dot.  This means  that if  a  reduce/reduce conflict  arises between  the
+   accepting scenario and another scenario, this other scenario is either of the form:
  
           (B -> . , ($ ...))
  
@@ -2584,9 +2494,9 @@ define List(Scenario)
    In the first case, ???
  
  
-   The following function constructs the non saturated initial state
-   for a given grammar. It simply looks for the unique S-production,
-   and constructs state 0 containing the unique initial scenario. 
+   The  following  function  constructs  the  non  saturated initial  state  for  a  given
+   grammar. It simply looks for the unique S-production, and constructs state 0 containing
+   the unique initial scenario.
  
 define List(Scenario)
   initial_state
@@ -2611,20 +2521,18 @@ define List(Scenario)
  
       *** (3.7) Transitions. 
  
-   Of course our automaton has transitions. It has two kinds of
-   transitions: those which result from the reading of a token, and
-   those which result from the reduction via a rule, after a sequence
-   of tokens has been read which is an instance of the right side of
-   this rule. The first ones are labelled by tokens, while the others
-   are labelled by non terminals.
+   Of course our  automaton has transitions. It has two kinds  of transitions: those which
+   result from  the reading of a  token, and those which  result from the  reduction via a
+   rule, after a sequence  of tokens has been read which is an  instance of the right side
+   of this rule. The  first ones are labelled by tokens, while  the others are labelled by
+   non terminals.
  
    If in some state, we have the scenario:
  
       (A -> u.av , E)
  
-   (where 'a' is a token) then, if the next token to be read is 'a',
-   it is clear that the transition will be performed to a state
-   containing the scenario:
+   (where 'a' is a token) then, if the next  token to be read is 'a', it is clear that the
+   transition will be performed to a state containing the scenario:
  
       (A -> ua.v , E)
  
@@ -2634,15 +2542,14 @@ define List(Scenario)
  
       (A -> u.Bv , E)
  
-   and if, after reading some tokens, we reduce via this B-production and
-   return to this state, we will have to make a transition to a state
-   containing:
+   and if, after reading  some tokens, we reduce via this B-production  and return to this
+   state, we will have to make a transition to a state containing:
  
       (A -> uB.v , E)
  
    (E again unchanged). 
  
-   All our transitions will occur in one of these two situations. 
+   All our transitions will occur in one of these two situations.
  
  
  
@@ -2654,11 +2561,12 @@ define List(Scenario)
  
       *** (3.8) Generating the states. 
  
-   Which states do we needs ? We need the initial state, and all the
-   states which are reachable from it via one of the two above kinds
-   of transitions. This gives the method for generating states. 
+   Which states  do we needs  ? We need  the initial state, and  all the states  which are
+   reachable from it via one of the  two above kinds of transitions. This gives the method
+   for generating states.
  
    (1) when creating a new state, saturate it, 
+   
    (2) for each symbol for which there are scenarii in the state with
        this symbol after the dot, construct the state needed for the
        corresponding transition.  
@@ -2728,8 +2636,8 @@ define List(Scenario)
       *** (3.9) Making the automaton. 
  
  
-   The following function takes a scenario (A -> u.Xv , E), where X is
-   any grammar symbol, and a list of lists of scenarii of the form:
+   The following function takes a scenario (A -> u.Xv , E), where X is any grammar symbol,
+   and a list of lists of scenarii of the form:
  
      [
        [
@@ -2740,17 +2648,14 @@ define List(Scenario)
       ...
      ]
  
-   i.e. such that in each list (called a 'class'), the scenarii (? ->
-   u.? , ?) have the same symbol as the last one in 'u' (i.e. the
-   first one in our representation, since 'u' is stored in reverse
-   order). The class above is said ''corresponding to Y''. 
+   i.e. such that  in each list (called a 'class'),  the scenarii (? -> u.?  , ?) have the
+   same symbol as the last one in 'u' (i.e. the first one in our representation, since 'u'
+   is stored in reverse order). The class above is said ''corresponding to Y''.
  
-   The function looks for a class corresponding to X. If it exists the
-   scenario is added to this class, after its dot has been put past
-   X. Otherwise, it makes a new class.  
+   The function looks for  a class corresponding to X. If it  exists the scenario is added
+   to this class, after its dot has been put past X. Otherwise, it makes a new class.
  
-   If the scenario has no symbol after the dot, it is not classified
-   at all. 
+   If the scenario has no symbol after the dot, it is not classified at all.
  
 define List(List(Scenario))
   classify
@@ -2794,14 +2699,13 @@ define List(List(Scenario))
  
  
  
-   The function 'next_states' takes a state 'state', and produces the
-   list of all states which may be reached from 'state' via a single
-   transition (either on shifting a token or after reduction to a non
-   terminal). 
+   The function 'next_states'  takes a state 'state', and produces the  list of all states
+   which may be reached  from 'state' via a single transition (either  on shifting a token
+   or after reduction to a non terminal).
  
-   It works as follows. It partitions 'state' so that each element of
-   the partition has scenarii with the same symbol after the dot. Then
-   the dot is put past this symbol. For example, if 'state' is:
+   It works as  follows. It partitions 'state'  so that each element of  the partition has
+   scenarii with the same symbol after the dot.  Then the dot is put past this symbol. For
+   example, if 'state' is:
  
      [
        (A -> u.av  ,  E)
@@ -2822,10 +2726,10 @@ define List(List(Scenario))
      ]
  
  
-   The next function takes a (non saturated) state, and computes the
-   list of all (non saturated) states which may be the target of a
-   transition (either on a token or on a non terminal) from that
-   state. It transforms a state into a set of classes like the above.
+   The next  function takes a  (non saturated)  state, and computes  the list of  all (non
+   saturated) states which  may be the target of  a transition (either on a token  or on a
+   non terminal)  from that state. It  transforms a state into  a set of  classes like the
+   above.
  
 define List(List(Scenario))
   next_states
@@ -2843,12 +2747,11 @@ define List(List(Scenario))
  
  
  
-   Now, in order to compute our automaton (of type
-   'List(List(Scenario))'), we must start with the initial non
-   saturated state and add 'next' states until no more state may be
-   added. Of course, we add states only if they are not already
-   present in the automaton. More presisely, if there is a similar
-   state in the automaton, we must merge those two states. 
+   Now, in order to compute our  automaton (of type 'List(List(Scenario))'), we must start
+   with the initial non  saturated state and add 'next' states until  no more state may be
+   added.  Of  course,  we add  states  only  if  they  are  not already  present  in  the
+   automaton. More presisely, if there is a  similar state in the automaton, we must merge
+   those two states.
  
    Here is how we merge states. 
  
@@ -2909,8 +2812,7 @@ define List(List(Scenario))
     }. 
  
  
-   At each step of the construction of our automaton, we have two
-   lists: 
+   At each step of the construction of our automaton, we have two lists:
  
        - the list 'have_next' of those states for which next states
          have been already constructed, 
@@ -2997,8 +2899,8 @@ define List(List(Scenario))
  
       *** (4.1) Numbering states and adding transitions lists. 
  
-   Now that our states are established, we need to rework them. Here
-   are the operations performed:
+   Now that our  states are established, we  need to rework them. Here  are the operations
+   performed:
  
      - Put an identifying number on each state (beginning at 0)
  
@@ -3011,7 +2913,7 @@ type IntermediateState:
           List((Symbol,Int32))    transitions). 
  
  
-    The next function just add numbers identifying states. 
+    The next function just add numbers identifying states.
  
 define List(IntermediateState)
   number
@@ -3027,8 +2929,8 @@ define List(IntermediateState)
     }. 
  
  
-   The next function gives the number identifying a non saturated
-   state in a list of intermediate states. 
+   The next  function gives  the number  identifying a non  saturated state  in a  list of
+   intermediate states.
  
 define Int32
   find_id
@@ -3047,11 +2949,10 @@ define Int32
     }. 
  
  
-   The next function takes a class (a list of scenarii with the same
-   grammar symbol Y before the dot) and an automaton in the form os a
-   list of intermediate states, and returns the pair (Y,n), where Y is the
-   previous grammar symbol and n the integer identifying that class in
-   the automaton.
+   The next  function takes a  class (a list  of scenarii with  the same grammar  symbol Y
+   before the  dot) and an  automaton in the  form os a  list of intermediate  states, and
+   returns  the pair  (Y,n), where  Y is  the previous  grammar symbol  and n  the integer
+   identifying that class in the automaton.
  
  
 define (Symbol,Int32)
@@ -3075,10 +2976,9 @@ define (Symbol,Int32)
  
  
  
-   The following function takes a partition of a state (in the form of
-   a list of classes), an automaton (in the form of a list of
-   intermediate states), and returns a list of pairs (X,n) saying ``if
-   transition is on X, then go to state n''.
+   The following function takes a partition of a state (in the form of a list of classes),
+   an automaton  (in the form  of a list  of intermediate states),  and returns a  list of
+   pairs (X,n) saying ``if transition is on X, then go to state n''.
  
 define List((Symbol,Int32))
   make_transitions
@@ -3099,8 +2999,7 @@ define List((Symbol,Int32))
  
  
  
-    The next function adds transitions to all intermediate states in
-    our automaton. 
+   The next function adds transitions to all intermediate states in our automaton.
  
 define List(IntermediateState)
   add_transitions
@@ -3143,15 +3042,15 @@ define List(IntermediateState)
  
       ( A-> u.v , E)
  
-   and if v is not empty, E is no more needed. Such a scenario is
-   called a 'shifting' scenario, because it will cause the shifting of
-   either a token or of an instance of a non terminal.
+   and if  v is not  empty, E is no  more needed. Such  a scenario is called  a 'shifting'
+   scenario, because it will  cause the shifting of either a token or  of an instance of a
+   non terminal.
  
-   On the contrary, scenarii of the form 
+   On the contrary, scenarii of the form
  
       (A -> u. , E)
  
-   are called 'reducing' scenarii, because they call for a reduction. 
+   are called 'reducing' scenarii, because they call for a reduction.
  
  
  type NonEmptyList($T):
@@ -3184,12 +3083,11 @@ type NewState:
         List(Conflict)            conflicts).  
  
  
-   Given an automaton in the form of a list of intermediate states, we
-   transform it into an automaton in the form of a list of new
-   states. This is a state by state operation. 
+   Given an automaton in  the form of a list of intermediate  states, we transform it into
+   an automaton in the form of a list of new states. This is a state by state operation.
  
-   The next function checks if a precedence level may be deduced from
-   the right member of the rule.
+   The next function checks if a precedence  level may be deduced from the right member of
+   the rule.
  
  
 define Maybe(Int32)
@@ -3235,8 +3133,8 @@ define Maybe(Int32)
  
  
  
-   For each state, we just need to separate the list of scenarii, and
-   slightly rearrange each of them. 
+   For each state, we  just need to separate the list of  scenarii, and slightly rearrange
+   each of them.
  
 define (List(ReducingScenario),List(ShiftingScenario))
   separate
@@ -3262,9 +3160,8 @@ define (List(ReducingScenario),List(ShiftingScenario))
     }. 
  
  
-   The next function establishes the list of conflict in a given
-   state, from the two lists of reducing scenarii and shifting
-   scenarii. 
+   The next function establishes the list of conflict in a given state, from the two lists
+   of reducing scenarii and shifting scenarii.
  
  
 define List($T)
@@ -3409,10 +3306,9 @@ define Int32
       *** (4.3) Making decisions. 
  
  
-   We will now examine our states to decide what to do in the presence
-   of a given lookahead. In other words, we must construct our
-   'action' function. We continue with the same example. We record all
-   possibilities in the following table:
+   We  will now  examine our  states to  decide  what to  do in  the presence  of a  given
+   lookahead. In  other words, we must  construct our 'action' function.  We continue with
+   the same example. We record all possibilities in the following table:
  
      |   a           $
    --+-------------------------
@@ -3421,15 +3317,13 @@ define Int32
    2 |   s1/r2       r1/r2
    3 |   s1/r2/r4    r2/r4
  
-   Indeed, in state 0, if we see an 'a' we may either shift and go to
-   state 1, or reduce using rule 2 (A -> ). If we see a '$' we can
-   only reduce using rule 2. In state 1, we can only reduce using rule
-   3 (A -> a). In state 2, if we see 'a', we ca shift and go to state
-   1, or reduce using rule 2 (A -> ). If we see a '$' we can reduce
-   using either rule 1 (S -> A) or rule 2 (A -> ). In state 3, if we
-   see 'a', we can shift and go to state 1, or reduce using either
-   rule 2 (A -> ) or rule 4 (A -> AA). If we see '$', we can reduce
-   using either rule 2 or rule 4. 
+   Indeed, in state 0, if  we see an 'a' we may either shift and  go to state 1, or reduce
+   using rule 2 (A ->  ). If we see a '$' we can only reduce using  rule 2. In state 1, we
+   can only reduce using rule 3 (A -> a). In state 2, if we see 'a', we ca shift and go to
+   state 1, or  reduce using rule 2  (A -> ). If we  see a '$' we can  reduce using either
+   rule 1 (S ->  A) or rule 2 (A -> ). In  state 3, if we see 'a', we  can shift and go to
+   state 1, or reduce using  either rule 2 (A -> ) or rule 4 (A ->  AA). If we see '$', we
+   can reduce using either rule 2 or rule 4.
  
    Hence, as expected, the example grammar is highly ambiguous. 
  
@@ -3517,8 +3411,8 @@ define Int32
  
  
  
-   Finally, here is a tool to print a 'first function'. We begin by a
-   function printing a list of extended tokens. 
+   Finally, here is a tool to print a  'first function'. We begin by a function printing a
+   list of extended tokens.
  
 define One 
   print
@@ -3923,14 +3817,6 @@ define One
           }
     }. 
  
- define One 
-  print
-    (
-      WAddr(Int8) file,
-      String s
-    ) = 
-  print(file,s,0). 
-
 define One
   trace_body
     (
@@ -4011,9 +3897,8 @@ define One
  
    read trace_apg.anubis
  
-   The function 'make_parser' receives the grammar read from the
-   source file (together with its name, its precedence and association
-   rules), and also the two output files. 
+   The function  'make_parser' receives  the grammar read  from the source  file (together
+   with its name, its precedence and association rules), and also the two output files.
  
 define Maybe(One)
   make_parser