This is an open-ended project to evaluate and improve the shortcomings of the errors generated by the Factor compiler, parser, and libraries. Here are some well-known candidates for improvement to start with:
The "unbalanced branches" and "___ digs arbitrarily deep into the stack" errors, which are raised when the branches of an if statement or loop don't have balanced stack effects, currently report only the lowest-level blocks that don't balance, which are often buried deep inside a stack of standard library combinators and have little relevance to what's in the user's actual code that causes the imbalance. How to select and report the most helpful set of blocks responsible for the stack imbalance is an open question among the Factor developers and will require some experimentation.
Parsing errors often give little hint as to where the syntax error is. A "';' expected but got EOF" error doesn't help much when you have several dozen "FOO:" definitions above it, any of which could be missing its closing semicolon. The parser should at least remember the name and location in the source of the syntax word that threw the syntax error.
Since Factor has extensible syntax controlled mainly by independent syntax words, much syntax error reporting is left up to these individual syntax words. The parser reports syntax errors at the point it's read up to in the source file. However, many syntax words slurp up entire forms from the source file in a single pass, then further validate and parse the contents in a second pass. This causes syntax errors to be reported at the final line of the form, even if the error could be attributed to a specific line inside the form. Common declaration syntax words such as TUPLE: and STRUCT: should be reworked to read from the parser incrementally. (This would have a side benefit of reducing the memory requirements of those syntax words too.)
Circular dependencies between source files can currently lead either to confusing "not defined" errors or infinite looping in the loader.
Ambitious students could research and improve other inadequate errors encountered by themselves or other Factor developers.
Benefit to student
The student gets to exercise UI design skills designing and implementing useful error messages.
Benefit to community
The user experience for Factor developers improves.
This revision created on Sat, 27 Feb 2010 02:53:53 by jckarter