> If I write a parser combinator based parser for a grammar that is not ambiguous
How do you even know it is not ambiguous to begin with?
I already said it doesn't matter what tool you use to parse a language designed by someone else. The language you design yourself is not automatically free of ambiguity, and intuition only gets you so far. If you stick to only using productions which are valid LL/LR, then why not have that enforced by the tool, so it can warn you when you go astray?
> How do you even know it is not ambiguous to begin with?
By knowing what makes a grammar ambiguous, and not doing it, and having a test suite that I need anyway.
> If you stick to only using productions which are valid LL/LR, then why not have that enforced by the tool, so it can warn you when you go astray?
A large part of the reason why there are so many parser generators is that we to date do not have a parser generator design that generates parsers that most people like to use for major projects. I've written about 5 generations of parser generators myself over the last 30 years, and I hate every one of them, yet every one was written in response to not finding a parser generator I consider tolerable to work with.
Most of the time it's easier to work with a hand-rolled parser. Parser combinators makes that easier, and more reusable.
How do you even know it is not ambiguous to begin with?
I already said it doesn't matter what tool you use to parse a language designed by someone else. The language you design yourself is not automatically free of ambiguity, and intuition only gets you so far. If you stick to only using productions which are valid LL/LR, then why not have that enforced by the tool, so it can warn you when you go astray?