home *** CD-ROM | disk | FTP | other *** search
/ minnie.tuhs.org / unixen.tar / unixen / PDP-11 / Trees / V6 / usr / doc / yacc / ss3 < prev    next >
Encoding:
Text File  |  1975-06-26  |  3.8 KB  |  113 lines
  1. .SH
  2. Section 3: Lexical Analysis
  3. .PP
  4. The user must supply a lexical analyzer which reads the input stream and communicates tokens
  5. (with values, if desired) to the parser.
  6. The lexical analyzer is an integer valued function called yylex, in both C and Ratfor.
  7. The function returns an integer which represents the type of the token.
  8. The value to be associated in the parser with that token is
  9. assigned to the integer variable yylval.
  10. Thus, a lexical analyzer written in C should begin
  11. .DS
  12. yylex ( ) {
  13.     extern int yylval;
  14.     . . .
  15. .DE
  16. while a lexical analyzer written in Ratfor should begin
  17. .DS
  18. integer function yylex(yylval)
  19.     integer yylval
  20.     . . .
  21. .DE
  22. .PP
  23. Clearly, the parser and the lexical analyzer must agree on the type numbers in order for
  24. communication between them to take place.
  25. These numbers may be chosen by Yacc, or chosen by the user.
  26. In either case, the ``define'' mechanisms of C and Ratfor are used to allow the lexical analyzer
  27. to return these numbers symbolically.
  28. For example, suppose that the token name DIGIT has been defined in the declarations section of the
  29. specification.
  30. The relevant portion of the lexical analyzer (in C) might look like:
  31. .DS
  32. yylex( ) {
  33.     extern int yylval;
  34.     int c;
  35.     . . .
  36.     c = getchar( );
  37.     . . .
  38.     if( c >= \'0\' && c <= \'9\' ) {
  39.         yylval = c\-\'0\';
  40.         return(DIGIT);
  41.     }
  42.     . . .
  43. .DE
  44. .PP
  45. The relevant portion of the Ratfor lexical analyzer might look like:
  46. .DS
  47. integer function yylex(yylval)
  48.     integer yylval, digits(10), c
  49.     . . .
  50.     data digits(1) / "0" /;
  51.     data digits(2) / "1" /;
  52.     . . .
  53.     data digits(10) / "9" /;
  54.     . . .
  55. #   set c to the next input character
  56.     . . .
  57.     do i = 1, 10 {
  58.         if(c .EQ. digits(i)) {
  59.             yylval = i\-1
  60.             yylex = DIGIT
  61.             return
  62.         }
  63.     }
  64.     . . .
  65. .DE
  66. .PP
  67. In both cases, the intent is to return a token type of DIGIT, and a value equal to the numerical value of the
  68. digit.
  69. Provided that the lexical analyzer code is placed in the programs section of the specification,
  70. the identifier DIGIT will be redefined to be equal to the type number associated
  71. with the token name DIGIT.
  72. .PP
  73. This mechanism leads to clear
  74. and easily modified lexical analyzers; the only pitfall is that it makes it
  75. important to avoid using any names in the grammar which are reserved
  76. or significant in the chosen language; thus, in both C and Ratfor, the use of
  77. token names of ``if'' or ``yylex'' will almost certainly cause severe
  78. difficulties when the lexical analyzer is compiled.
  79. The token name ``error'' is reserved for error handling, and should not be used naively
  80. (see Section 5).
  81. .PP
  82. As mentioned above, the type numbers may be chosen by Yacc or by the user.
  83. In the default situation, the numbers are chosen by Yacc.
  84. The default type number for a literal
  85. character is the numerical value of the character, considered as a 1 byte integer.
  86. Other token names are assigned type numbers
  87. starting at 257.
  88. It is a difficult, machine dependent
  89. operation to determine the numerical value of an input character
  90. in Ratfor (or Fortran).
  91. Thus, the Ratfor user of Yacc will probably wish
  92. to set his own type numbers, or not use any literals in his specification.
  93. .PP
  94. To assign a type number to a token (including literals),
  95. the first appearance of the token name or literal
  96. .I
  97. in the declarations section
  98. .R
  99. can be immediately followed by
  100. a nonnegative integer.
  101. This integer is taken to be the type number of the name or literal.
  102. Names and literals not defined by this mechanism retain their default definition.
  103. It is important that all type numbers be distinct.
  104. .PP
  105. There is one exception to this situation.
  106. For sticky historical reasons, the endmarker must have type
  107. number 0.
  108. Note that this is not unattractive in C, since the nul character is returned upon
  109. end of file; in Ratfor, it makes no sense.
  110. This type number cannot be redefined by the user; thus, all
  111. lexical analyzers should be prepared to return 0 as a type number
  112. upon reaching the end of their input.
  113.