Expectation failures can repeat expected (non-) terminals

[joshuabowers]

Given the following recursive parser:

const parser = peg`s: a b c
a: "a"*
b: "b"* a
c: "c"* b`

When parsing an input string which fails to match the tokens the parser is expecting, the generated error message can have (seemingly redundant) expectations:

parser.children('a d a')

/* =>
(1:3) Failure: Expected "a", "b", "a", "c", "b", "a" or end of input

> 1 | a d a
    |   ^
*/

Presumably, this is due to the multiple different recursive pathways the parser could expand the non-terminals into. However, for error reporting to the user, these repeated expectations don't provide much insight: what, fundamentally, is different between the first expected "a", the second, and the third?

Would it be possible to filter the expectations when generating the error message to only keep the distinct, unique tokens? I see from stringifyEntry you are map/reducing the expected array. Perhaps something similar to what this stackoverflow answer to a similar problem would be applicable, as a step performed before the map?

This is very low priority---as in I don't need this functionality in the immediate future.

[strblr]

Should be solved in 0.3.17 (just published).