Comment by eru
10 hours ago
Writing parsers by hand this way can be fun (and might be required for the highest performance ones, maybe?), but for robustness and ease of development you are generally better off using a parser combinator library.
10 hours ago
Writing parsers by hand this way can be fun (and might be required for the highest performance ones, maybe?), but for robustness and ease of development you are generally better off using a parser combinator library.
Are you?
The majority of production compilers use hand rolled parsers, ostensibly for better error reporting and panic synch.
One anecdote in the same vein, a couple of months ago, I wanted to parse systemd-networkd INI files in Python and the python built-in ConfigParser [0] and pytest's iniconfig parser [1] couldn't handle multiple sections with the same name so I ended up writing 2 parsers, one using a ParserCombinator library and one by hand and ended up using the latter given it was much simpler to understand and I didn't have to introduce an extra dependency.
Admittedly, INI is quite a simple format, hence I mention this as an anecdote.
[0] https://docs.python.org/3/library/configparser.html
[1] https://github.com/pytest-dev/iniconfig
As a project gets larger the cost of owning a dependency directly begins to outweigh the impedance mismatch between 3rd party software & software customized to your project.
I've got 10 full time senior engineers on a project heading in to its 15th year. We rewrite even extremely low level code like std::vector or malloc to make sure it matches our requirements.
UNIX was written by a couple of dudes.
That’s because Python is a bad language for writing parser combinators and parsers based on them. Try Haskell.