When using a macro it sometimes happen to make an error and use a syntax not accepted by the macro. If the author of the macro didn't insert error detection with helpful messages associated, you'll waste a lot of time trying to find what's wrong. The problem is that adding such cheks is usually very boring. The idea then is to add to Arc a way to easily construct a syntax checker with meaningful error messages, in order to make such task immediate.
As I have remarked before, treeparse was influenced by Haskell's parsec. One of the features of parsec is the optional infusion of more meaningful error messages into grammars. One could easily imagine adding this functionality to treeparse.
Interesting. I suppose this means that (at least for the cps version of treeparse) a fail must also "return" an error value (potentially just a "Expected lit %c, not found"). Of course 'alt parsers would ignore the error message, and generate its own when all alternatives fail ("No alternatives found"). Hmm. I think if the fail continuation returned an error message, we could create a filt-style parser (for the cps case):
For the monadic version, our old nil-as-fail code would have to be changed I suspect; basically instead of the old type Return = Return parsed remaining actions | nil, we'll need type Return = Return parsed remainig actions | Failed message .
To discover the line of the error the interpreter should provide a way to associate every form or symbol passed to the macro with its line number. As an example there could be a function such as (line-num form-with-an-error) to get the line number.
My "attachments" idea was conceived with this potential use too - jus attach the line number to the object, which acts just like the original object (i.e. matches with 'is, etc.).
