Error Message Clinic

The point

A compiler is a user interface, and its users meet it almost entirely through its error messages. Dragon §4.1.3 sets the standard; this is measuring yourself against it.

Do this

1. Collect real ones. Each person writes three broken programs — one lexical, one syntax, one semantic error — runs them through their own compiler, and pastes the actual output.
2. Score every message out of four: does it give the LINE? name the OFFENDING THING? say what was EXPECTED? suggest a FIX? Most first drafts score one.
3. Classify the recovery. For each syntax error, which of Dragon's four strategies did your compiler use — panic mode, phrase level, error production, or none at all?
4. Rewrite the worst three, aiming for four out of four.

   before:  syntax error
   
   after:   Syntax error, line 7:
              missing ';' after assignment
              suggestion: add ';' after 'total = 2 + 3'

5. Implement one as a bison error production, and explain why the production can say more than a generic handler could.
6. Swap compilers. Run your broken programs through a group member's. Whose messages would you rather receive at 2am?

A harder question, if you have time

Should the compiler stop after reporting an error, or keep going? Try both. Feed a file with five errors to each. Keeping going can cascade one mistake into twenty spurious ones; stopping makes the programmer recompile five times. Dragon §4.1.4 does not settle it for you.