Comment by dhess | Hacker News Reader

Comment by dhess | Hacker News Reader

Parent Full thread

This is the chief drawback of these two libraries: they are poorly documented (and are arguably not documented at all). In general, parsers is for parsing and trifecta is for reporting errors and diagnostics. Trifecta looks especially nice for giving context to error sites, but I haven't used it much yet (only for highlighting, really).

By "error recovery," do you mean backtracking? If so, there are several ways of doing that, which can be found here:

https://hackage.haskell.org/package/parsers-0.12.2.1/docs/Te...

See the 'choice', 'option', and 'try' combinators, and also the '<|>' operator in Control.Applicative.

If you need more than that, you can extend parsers' monadic parsing to roll your own error recovery.

Currently, the best way to understand how parsers and trifecta work is to look at projects that use them. I will give you some links to the ones I've used and found helpful, if a bit more complicated than the parsers I am currently writing:

https://github.com/ekmett/ermine/tree/master/src/Ermine

https://github.com/idris-lang/Idris-dev/tree/master/src/Idri...

And here is a relevant Reddit thread, which includes a link to Edward Kmett's slide deck which motivates trifecta/parsers and gives a high-level view of how they work:

https://www.reddit.com/r/haskell/comments/2uc6kp/are_there_a...

I hope this helps!

Thanks! I'll take a look at these projects.

By recovery I mean something like "f(x,y,z;" triggering an error message "did you miss ')' here?", with parser recovering and proceeding further, in a hope to report more errors in a single run - see how Clang handles this, with a handcrafted recursive descent parser.

Backtracking does not help here, it must be done with custom heuristics at each node. I am doing this kind of things declaratively on top of an elaborate PEG-based generator (using an idea of signals attached to both successful and failed branches, and then choosing which signals to execute based on the exact points of failure), but would be very interested to see a lightweight combinator-based solution.

`trifecta` is basically produces `clang`-style error messages (i.e. they have the pretty colors, underlined text spans, cursor pointers into the text, and really good error messages indicating the real problem and not some unrelated problem). That's why most people recommend `trifecta` when error reporting quality is paramount.

The author of the `trifecta` library is extremely knowledgeable about parsing/backtracking/recovery/error-reporting and has put a lot of thought into how to improve error message relevance as much as possible.

Ok, I think I understand now how it works (played with Idris parser a bit). Sort of a simple trick, I'll borrow it for the lower tier combinator-based parsing layer.

I was even more interested in handcrafted, custom error messages rather than constructed. Still cannot figure out how to stuff custom recovery heuristics into a combinator-based code.

Reply on news.ycombinator.com