Suggestion for revising documentation on writing custom parsers
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 35/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- cpp
- Domain
- documentation
Research direction
Start in doc/tutorial.qbk around line 3792 and read the section discussing custom parsers. Revise the wording to be more neutral and add guidance or an example addressing complex literals such as SystemVerilog's 5 'D 3. Done means the section explains when custom parsers are appropriate and gives users practical direction.
Written by the indexing model from the issue text.
Description
Thank you for your work on Boost Parser. It's an impressive library, and I've found it quite powerful.
While I appreciate the humor in the writing, I found the tone to be slightly dismissive of scenarios where writing custom parsers might genuinely be the most effective solution. For instance, I am working on parsing SystemVerilog code, which includes number literals with unique syntax, such as 5 'D 3. Parsing such constructs character by character using char_ primitives seems neither convenient nor effective, and it would make a strong case for writing a custom parser akin to uint_.
I believe this use case illustrates that there are situations where users might reasonably need more guidance on creating low-level parsers. If this section of the documentation could include:
- A more neutral tone when addressing the use of custom parsers.
- An example of how to effectively handle complex cases (like SystemVerilog number literals) using the library's primitives or via a custom parser.
This approach would make the documentation more inclusive and better serve a wider range of users.
Thank you again for your efforts, and I hope my feedback helps in further refining the excellent resources you provide.
- Dominant language
- C++
- Stars
- 182
- Forks
- 28
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from boostorg/parser
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 1/5 Under an hour Newbie friendliness 82/100
-
Difficulty 1/5 Under an hour Newbie friendliness 20/100
-
Difficulty 3/5 1-2 days Newbie friendliness 55/100
-
Difficulty 3/5 1-2 days Newbie friendliness 48/100
Similar issues
-
ai_reviewed
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
ydb-platform/ydb#53869 · 3 comments ·
-
bug cert blocker needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
project-chip/connectedhomeip#74373 ·
-
upstream update
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
conan-io/conan-center-index#31035 ·
-
Bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
documentation
Difficulty 1/5 Under an hour Newbie friendliness 85/100
vllm-project/vllm-ascend#17329 ·