Error reporting

[robrix]

I’m currently experimenting in the tests before applying this across the interface, since it’s difficult to experiment quickly when small changes require refactoring every combinator.

An overview of the current experiment:

Error reporting replaces the Optional return value of parsers with Either<Error, T>. This means that every parser reports an error when it fails to match, describing (in brief) what it expected in order to be able to parse, but did not find.

Error is a simple tree, with leaves consisting of a String and an IndexType, and branches being arrays of Errors. These map fairly directly onto terminal/nonterminal parsers, respectively.

When implemented for all combinators, terminal parsers will each be able to directly state their unmet expectations:

let input = "abc"
(%"xyz")(input, input.startIndex) // => .left(.leaf("expected 'xyz'", input.startIndex))

Intuitively, nonterminals will combine their sub-parsers’ errors in some parser-dependent fashion:

let input = "abc"
(%"def" | %"geh")(input, input.startIndex) // => .left(.branch([.leaf("expected 'def'", input.startIndex), .leaf("expected 'geh'", input.startIndex)]))

While thorough, I fear that this will lead to poor signal to noise ratios, so there are still things to do:

• [x] Explore mixing error-reporting and non-error-reporting parsers. Findings: mo’ overloads, mo’ problems.
• [x] Explore assigning human-readable identifiers to key parsers in a grammar, and using these to build error messages.
• Explore maintaining and reporting a path of (identifier, index) pairs. Later.
• Explore reductions returning Either directly, enabling reporting of semantic errors at parse time. Later.
• [x] Merge master in.

Fixes #41. Fixes #47.

[robrix]

/cc @jspahrsummers Fixing up some test failures and then will merge this. Will explore the other things in separate PRs.

[robrix]

Well I guess I should also test this out a bit!

[jspahrsummers]

[robrix]

This is ready for review :tada:

Note that the errors it produces are not particularly friendly as yet. They do, however, relate source information and can be decorated with human-readable identifiers for the kinds of things it’s trying to parse (via describeAs), which is an ok start.

[robrix]

@jspahrsummers: Unless you have any objections I’m gonna get master merged in and then merge this tomorrow.

[robrix]

(The takeaway being that there’ll be issues to file on what the errors look like but I figure they can be tackled after the fact.)

[jspahrsummers]

Not sure how soon I'll be able to return to ogdl-swift, because I'd like to get RAC 3 out the door before WWDC week. :confused:

[robrix]

That’s fine :+1: