> > I don't think I would use a parsing lib to build a general purpose programming language though. At least not one that I intended to ship.

> Curious why not? Too big of a dependency?

Really very poor diagnostics. I've used a few, but for really nice helpful messages[1] you really need to build it yourself and handle some subset of the context when parsing the grammar.

--

[1] For example, maybe you want to issue errors of "'SomeVariable' not defined on line 53. Did you mean 'someVariable'?".

Or perhaps you want to issue the message "Unexpected end of input on line 570 - expected closing '}' to match opening '{' on line 515, column 22".

It gets especially annoying if the language provides meta-programming or compile-time logic - the parser generator, if it can even handle such a thing, spits out either an error for a line that is nowhere near the source of the error, or spits out pages and pages of a backtrace.

It is inevitable that you'd run into issues eventually that are due to the parsing library itself. Whether that be performance or otherwise. Sure, you can fix those problem in the lib yourself, but maybe you just can't for one reason or another. It is also possible that the lib is really good and has no problems, but your problem ends up being slightly different which makes it a pain to implement with the library that you choose.

When you are making a general purpose language that gets shipped to the masses, a core component of that thing you are making is the parsing. I'd say it is in your best interest to have complete control over how that works and be able to understand that well. That would mean putting in the work to make the parser yourself.

I don't just feel this way about building programming languages. I believe this is true for any kind of production level software that you write. It is important to maintain control and deep understanding of technologies that are core to your product. Building something from ready made components, while tempting, often ends badly.