4 ms·
The way I write parsers nowadays is to write a pseudo-code description of the grammar, then treat that pseudo-code as data that must be transformed into a valid
by alextgordon 12y ago
The way I write parsers nowadays is to write a pseudo-code description of the grammar, then treat that pseudo-code as data that must be transformed into a valid parser.
The end result is a fast, memory-safe parser in C or C++, and a whole lot of ugly python code :)
- chubot 12y agoThat's interesting -- do you have examples somewhere? Are you saying you write an parser-specific parser generator in Python for every problem, with the goal of producing readable C or C++? (As opposed to the sometimes unreadable output of parser generators.)
- aidenn0 12y agoI used to entirely use hand-written recursive-descent parsers, until I discovered packrat style parsers. They are crazy fast and so easy to write. Also, the parser generator I use (esrap) lets you fall-back on recursive decent for parsing rules.
- Nitramp 12y agoThey are crazy fast Do you have a link/citation for that? I always thought they were asymptotically linear due to the memoization, so comparable to LL, LALR etc, but in practice much slower due to the overhead compared to those more traditional approaches.
- aidenn0 12y agoFor me, I expect Esrap to end up within a factor of 2-4 of a hand-tuned recursive decent parser on sbcl.