5 ms·
This course follows the traditional approach to writing parsers. These traditional approaches were developed in times when memory was scarce and where back-trac
by fjfaase 6y ago
This course follows the traditional approach to writing parsers. These traditional approaches were developed in times when memory was scarce and where back-tracking was impossible, simply because files were too large to be stored in RAM. Back-tracking parsers are much easier to write and in most cases performance can be brought to acceptable levels by applying caching. I have experimented with developing interpreting parsers that work with user-friendly grammar representations, and discovered that using caching can result in acceptable performance. I also discovered that a small interpreter often is faster than generated code, probably due to a better CPU cache performance. For two examples of these approaches see: https://github.com/FransFaase/IParse https://github.com/FransFaase/IParse and https://github.com/FransFaase/RawParser https://github.com/FransFaase/RawParser (WIP).
- sleavey 6y agoGuido van Rossum talks about this in his series on designing a PEG parser for Python [1], now used in 3.9. [1] https://medium.com/@gvanrossum_83706/peg-parsing-series-de5d41b2ed60 https://medium.com/@gvanrossum_83706/peg-parsing-series-de5d...
- DmitrySoshnikov 6y agoYes, backtracking still might be an option although has its known limitations in terms of parallel paths. We describe backtracking in this class too. The LL in the the view of manual Recursive descent is the most used on practice along with combinators and LALR(1).