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]

>     creation

>         make
>     %}

Geyacc does not generate the indexing, 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.