<p>There are plenty of libraries out there that provide tools like LL parsers, combinator parsers, ebnf parsers and more. However, these may not always be suited to the grammar of a programming language.</p>
<p>What language constructs/grammar features would create a situation where hand-writing a parser would be more beneficial than using a parsing library?</p>

<implementation><parsing>
When should I use a hand-written parser over a parsing library?
CC BY-SA 4.0
2023-05-20T11:25:56.057Z
Possibly relevant post: https://softwareengineering.stackexchange.com/questions/17824/should-i-use-a-parser-generator-or-should-i-roll-my-own-custom-lexer-and-parser
FireTheLost
<p>Writing a recursive descent parser is pretty simple, but the downside is that you it is hard to figure out the exact spec for the grammar when looking at the code. Another downside is that it's often easy to break ambiguities in a recursive descent parser by hacking some special behaviour. Unfortunately this can end up causing things being parsed in unforeseen ways.</p>
<p>If you need to feed your grammar into some tool (for instance you're making a language plugin) it's also beneficial to have an actual grammar for it.</p>
<p>When you want to error report on the other hand, you might want to parse more than is valid in your language in order to produce good error messages.</p>
<p>So we roughly end up with the following cases:</p>
<ol>
<li>You're writing the main compiler for a general purpose language: use a hand written parser to have good control over error messages and recovery.</li>
<li>You are just parsing a small DSL: use a parser generator if you want.</li>
<li>You're writing a tool that works on correct code and transforms it: a parser generator is sufficient.</li>
<li>You want to iterate on your grammar and see that it is consistent: use a parser generator.</li>
</ol>

CC BY-SA 4.0
2023-05-20T12:51:07.593Z
2023-05-20T12:51:07.593Z
Nuoji
CC BY-SA 4.0
2023-05-20T13:16:31.597Z
*"it is hard to figure out the exact spec for the grammar when looking at the code"* ─ not sure about this. The code structure of a recursive descent parser will closely mirror the BNF or PEG for the language grammar. For my own language MJr, I wrote the PEG after the parser, and found it fairly straightforward to do so.
kaya3
CC BY-SA 4.0
2023-05-20T18:33:50.403Z
Although the general spec will be simple, special cases will not be. I have several examples with my language.
Nuoji
# When should I use a hand-written parser over a parsing library?
Posted by: username_0 on 2023-05-20
There are plenty of libraries out there that provide tools like LL parsers, combinator parsers, ebnf parsers and more. However, these may not always be suited to the grammar of a programming language.

What language constructs/grammar features would create a situation where hand-writing a parser would be more beneficial than using a parsing library?
**Tags:** implementation parsing
> **Comments:**
> **username_1**: Possibly relevant post: https://softwareengineering.stackexchange.com/questions/17824/should-i-use-a-parser-generator-or-should-i-roll-my-own-custom-lexer-and-parser  
---
## 1 answers
### Answer by username_2 on 2023-05-20. Score: 6
Writing a recursive descent parser is pretty simple, but the downside is that you it is hard to figure out the exact spec for the grammar when looking at the code. Another downside is that it's often easy to break ambiguities in a recursive descent parser by hacking some special behaviour. Unfortunately this can end up causing things being parsed in unforeseen ways.

If you need to feed your grammar into some tool (for instance you're making a language plugin) it's also beneficial to have an actual grammar for it.

When you want to error report on the other hand, you might want to parse more than is valid in your language in order to produce good error messages.

So we roughly end up with the following cases:

1. You're writing the main compiler for a general purpose language: use a hand written parser to have good control over error messages and recovery.
2. You are just parsing a small DSL: use a parser generator if you want.
3. You're writing a tool that works on correct code and transforms it: a parser generator is sufficient.
4. You want to iterate on your grammar and see that it is consistent: use a parser generator.
> **Comments:**
> **username_3** (2023-05-20): *"it is hard to figure out the exact spec for the grammar when looking at the code"* ─ not sure about this. The code structure of a recursive descent parser will closely mirror the BNF or PEG for the language grammar. For my own language MJr, I wrote the PEG after the parser, and found it fairly straightforward to do so.  
> **username_2** (2023-05-20): Although the general spec will be simple, special cases will not be. I have several examples with my language.  
---
