Bison Advice

[Lowell Boggs, Jr.]

Understanding problems in a bison grammar can be challenging. The best advice I can give is to move slowly. That is, do not type in a bunch of grammar changes then expect to debug what is wrong with them. Instead, plan out the changes, then enter them into the grammar file one at a time, fully test all the language fragments your change is supposed to address. Run all your tests. Save the state the whole directory using "make backup", then add the next grammar fragment.

[Lowell Boggs, Jr.]

By the way, as bison runs, it writes several kinds of diagnostic information to the file, mc_parser.all.

Please use google to find out what it all means. However, it does provide the raw data needed to think through most problems. However, if you make many changes at once, that process may be extremely painful.

[Lowell Boggs, Jr.]

More good advice: don't duplicate syntax fragments textually -- instead make a grammar fragment and use it instead of the duplication. This doesn't prevent all painful debug sessions with bison error messages, but it does reduce them quite a bit.

For example, don't do this:

target: OPEN_PAREN FRED CLOSE_PAREN other stuff;
second: OPEN_PAREN FRED CLOSE_PAREN even more stuff;

I'm not positive this exact text will get you into trouble, but you get the idea: duplicating fragments will ultimately burn you and make for painful debug sessions.

Instead do something like:

  parentheticalFred:  OPEN_PAREN FRED CLOSE_PAREN;
  target:             parentheticalFred other stuff;
  second:             parentheticalFred even more stuff;

[Lowell Boggs, Jr.]

Optional grammar fragments can be a problem too. If you want to try using optional syntax, use google to search for that. I advise against it. Instead of thinking in terms of optional syntax fragments, instead think of two different fragments -- one with the seemingly optional part, and one without. The problem with optional fragments is that they seem to be magnets for bison errors.

For example, a source module may or may not define any grammar fragments -- it might be empty or only comments. You would make all definitions optional, but this leads a slew of bison errors for any complex grammar. Instead, define your module like this:

module: END | definitionList;

Where end is a token, defined like this:

%token END 0 "end of file"

And definitionList would be defined something like this:

definitionList: definition
| definitionList definition
;

definition: <whatever>;</whatever>

Note that nothing is optional here. Bison guarantees end of file will eventually occur and normally hides it from all productions, but if you specfically test for it in a production, you can take advantage of it.

By the way, lists must be defined using tail recursion as I have shown above. Any other method results in strange errors. Its weird but get used to it.