In this section we shall describe the syntax for the input grammar files that are to be converted into a finite state machine (FSM) for recognising input events with tested guard conditions.

The basic model is that you write a formal FSM specification and store it to a file with a '.g' extension to its name. The parselr command-line program is then run with the command line option -f and your FSM specification file as arguments. This causes a new file filled containing C# source code to be generated. That C# source file, along with a C# source file that you write providing an input event source are added to the project in Visual Studio or other C# development environment you are using. References to the Parsing.dll and ParserGenerator.dll libraries are added to the project, and the project compiled.

The process of constructing an input event source, and of setting up the project are described elsewhere. Here we focus on the contents of the input FSM specification file.

The input file contains between two and four discrete sections. These are in order:

• The options section. This contains a list of parser options that are either used by the state machine generator itself to modify its behaviour, or as flags to pass on to the compiled output code. This section can be omitted if you are happy to just accept a set of defaults, or if you are generating an in-line finite state machine at runtime.
• The events or tokens section. This is a mandatory section of the input grammar and contains the list of different input event types that may appear when retrieved from the input event source. For example, if you have written a finite state machine that controls a pedestrian crossing, examples of your input events might be a token representing the pressing of a pedestrian request-to-cross button, ar a token representing a timer timeout event.
• The guards or conditions section. This section is optional. If your finite state machine ever performs a transition that is dependent on a guard condition as well as an input event, the different functions that test if a guard condition is true must be listed here.
• The fsm section. This section contains a formal description of all the states and the transitions between them, and is usually by far the most complicated section of the grammar to write. The full syntax for how to write this is given elsewhere in this set of documentation. The section is mandatory.

All sections begin with a keyword as given in the list of section descriptions above. Some section types have alternative keywords that are aliases for each other, namely events or tokens, and guards or conditions. The fsm section takes an argument to the fsm keyword in parentheses where the argument is the name of the starting state in the FSM in which the machine will begin to execute. All four sections have bodies enclosed in curly braces.

options
{
    ... options go here ...
}
 
events
{
    ... events or tokens go here ...
}
 
guards
{
    ... guard condition function names here ...
}
 
fsm(startingStateName)
{
    ... grammar description goes here ...
}