Timeline for When to use a Parser Combinator? When to use a Parser Generator?
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 27, 2016 at 22:25 | comment | added | Karl Bielefeldt | Not by default, no, but they have more convenient hooks for adding good error messages. | |
| Dec 27, 2016 at 21:13 | comment | added | mrr | Parser generators aren't exactly known for their good error messages either, to be honest. | |
| Dec 25, 2016 at 12:00 | comment | added | John R. Strohm | With a Parser Combinator, by definition all you can get in an error condition is "Starting at this point, no legal input was found". This doesn't really tell you what was wrong. In theory, the individual parsers called at that point could tell you what it expected and DIDN'T find, but all you could do is print all that out, making for a looooooong error message. | |
| Dec 22, 2016 at 19:50 | comment | added | Karl Bielefeldt | It's not that you can't print error messages with parser combinators, it's that their advantages are less evident when you throw error messages into the mix. Do a relatively complex grammar using both methods and you'll see what I mean. | |
| Dec 22, 2016 at 18:59 | comment | added | Qqwy | Thank you for your answer! Why would it be easier to build readable error-messages using a Parser Generator than a Parser Combinator? (Regardless of what implementation we are talking about, specifically) For instance, I know that both Parsec and Spirit contain functionality to print error messages including line+column information, so it seems definitely possible to do this in Parser Combinators as well. | |
| Dec 22, 2016 at 16:59 | history | answered | Karl Bielefeldt | CC BY-SA 3.0 |