Comprehensive Error Reporting Overhaul

[kjosib]

"Any fool can write a compiler for correct source programs" (J.S. Rohl 1972)

Right now the interfaces.py module contains a few exception classes which get used in various ways to report errors. It's been rather ad-hoc up to now. In particular, the ParseError class goes to some effort to provide information about the situation in which an error happened. Then there's the ErrorHelper class in grammar.py, which is just about exactly an admission of guilt. This got the job done in the demos, but it does not really seem like the right architecture.

From first principles:

• What kind of information would we like to know about different categories of errors that might pop up in a language-driven system? Not just scan and syntax, but also semantic errors (because interfaces) which can refer to potentially several locations and have various bits of explanatory text added.
• How can that information be organized and structured to pass around as data?
• What sorts of operational things should become the exception hierarchy?
• Are exceptions even the right approach, given a long-term goal to perhaps handle error-productions with some panache? Or is that all simply a matter of choosing (writing) another "engine" with error-productions in mind? Errors not thrown are still errors, and should make sense as such.
• What convention might best apply so all application code knows where to find error descriptive data simply and easily?
• How can we achieve some measure of consistency, so that it would be possible to write to an interface and supply good error help in a wide variety of settings?
• Is it too soon to think about internationalization? (Probably so.)

[kjosib]

Maybe don't raise exceptions in the parser engine itself. Instead, delegate to an error-strategy object for whatever sort of reporting (or aborting) seems appropriate to the client application. Parse errors turn into a stream of events. The same idea can be used in the scan engine, and by extension for semantics.