Chapter 13. Context Variable

Use a variable to hold context required during a parse.

Imagine you are parsing a list of items, capturing data about each one. Each bit of information about an item can be captured independently, but you also need to know which particular item you are capturing information for.

A Context Variable does this by keeping the current item in a variable and reassigning it as you move to a new one.

13.1 How It Works

You have a Context Variable whenever you have a variable named something like currentItem which you update periodically during the parse as you move from one item to another in the input script.

A Context Variable can be a Semantic Model object or a builder. A Semantic Model is superficially more straightforward, but this is only true if all its properties are mutable when the parse needs them to be changed. If this is not the case, it’s usually best to use some kind of builder to gather the information and create the Semantic Model object when done—something like a Construction Builder.

13.2 When to Use It

There are lots of places where you have to keep context during a parse, and a Context Variable is an obvious choice. It’s easy to create and get going.

Context Variables are problematic, however, particularly as you get more of them. By their nature, they are mutable state that has to be kept track of, and bugs adore this kind of mutable state. It’s easy to forget to update the Context Variable at the right moment, and debugging can get quite difficult. There are usually alternative ways of organizing the parse that can reduce the need for Context Variables. While I don’t say that any Context Variable is evil, I do prefer to use techniques that don’t need them—and you’ll see mentions of this scattered around the book.

13.3 Reading an INI File (C#)

I wanted a very simple example to illustrate what a Context Variable looks like, and the old INI file format is a good illustration. Although it can seem somewhat old-fashioned—it was “improved” by the Registry in Windows—it still remains a lightweight and readable way to handle a simple list of items with properties. Alternative formats like XML and YAML can handle more complex structures, but at a cost of readability and parsing difficulty. If your needs are simple enough for an INI file, it remains a reasonable choice.

For my example, here is a list of project codes and some property data for each one:

Although there’s no standard form for an INI file format, the basic elements are property assignments, separated into sections. In this case, each section is a project code.

The Semantic Model is trivial.

The INI file format is easy to read using Delimiter-Directed Translation. The basic structure of the parser implements the usual approach of breaking the script into lines and parsing each one.

The first statements in the line parser just handle blanks and comments.

The Context Variable—currentProject—appears for parsing sections; at this point I assign to it.

I then use the Context Variable when parsing a property.

Using reflection makes the code more complex, but it does mean that I don’t need to update the parser when I add more properties to the Semantic Model.