Today's riddle: why does CUP emit the generated parser as TWO classes?

OK, so when you use CUP to generate a parser, it emits two classes: a parser class, and an action class (which contains the code generated for the semantic actions associated with the productions of your grammar). These are totally separate classes.

Today's riddle is this:

Why is the code for the semantic actions generated in a separate class?

Here are some possible answers:

1. Your guess is as good as mine.
2. Look in the user manual to find out --- oh wait, the user manual doesn't explain this.
   
3. To ensure that you must violate encapsulation in order to allow semantic actions to refer to internal parser operations?
   

My complaint is that if you want add additional fields--for example, a symbol table object---the semantic actions can't directly refer to it!

The action code can refer to the parser via a field called parser, but that's only useful for calling public methods on the parser object. But that means that any internal parser state/operations that the semantic actions want to access must be exposed as public, violating encapsulation.

Blech.