Geyacc: Parser Description File

Parser Description File

The geyacc input file consists of three sections, separated by a line with just %% in it:

declarations
%%
rules
%%
user code

Comments follow Eiffel style conventions and have no effect on the description's semantics.

Declarations section

The declarations section contains geyacc declarations that define terminal and nonterminal symbols, specify precedence, and so on. In some simple grammars these declarations are not needed.

This section may also contain Eiffel code to be copied verbatim to the beginning of the generated parser class. The Eiffel text has to be enclosed between two marks %{ and %} such as in the following example:

%{
class MY_PARSER

inherit

    YY_PARSER_SKELETON [ANY]

create

    make
%}

Geyacc does not generate the note, class header, formal generics, obsolete, inheritance and creation clauses. As the example above shows, Eiffel declarations are used to specify such clauses in order to ensure that the generated parser class is syntactically and semantically correct. Here, the name of the generated class is MY_PARSER and its creation procedure is make, a routine inherited from class YY_PARSER_SKELETON. This class also provides numerous facilities such as routine parse for analyzing a given input text. The generated parser class has to inherit from one such class to work properly.

If several of these Eiffel blocks appear in the declarations section, they are all copied to the generated parser class in their order of appearance in the input file.

Rules section

The rules section of the geyacc input contains one or more grammar rules, and nothing else. There must be at least one grammar rule, and the first %% (which precedes the rules section) may never be omitted even if it is the first thing in the description file.

User code section

Finally, the user code section is simply copied verbatim to the end of the generated parser class. Geyacc does not generate the invariant clause and the end of class keyword. This section is hence used to specify such clauses and also to define features called from the semantic actions. The presence of this section is optional (if it is missing, the second %% in the input file may be skipped, too) but is highly recommended if only to specify the end of the generated parser class and thus ensure that this class is syntactically correct.

Names of implementation features inherited from class YY_PARSER_SKELETON are prefixed by yy. As a consequence, user-declarared feature names beginning with this prefix should be avoided.