But I still think it's a pretty good idea.
It turns out that, in practice, it's better to be selective about where you apply the packrat mechanism.
The mathematical function doesn't matter as much as the practical overhead.
I mean... the clue's in the name, right?
(I worked on PEG and Packrat for my MEng.)
But, seriously, it's called "packrat parsing," because it saves all the things. You have to expect it's going to use a bit of memory.
If I am reading the page 20 graphs, though, the parsing time gets crushed by the competition when parsing programming languages (Java, in the example). It is only competitive for simple grammars.
Beyond that, I feel like recursive descent parsers are the PostgreSQL of parsing: they are not exciting, but they get the job done well without fail.
The rare cases where you need something else require subtle justification.
It was extremely simple. No state variables, each function was its own state. The only place where there was any call stack buildup was of course in nested arrays/hashes, but guile doesn't do stack overflows, just out of memory, so that was less of an issue.
Proposal to use PEG parser in python
Python PEG grammar
If you want to understand the compile-time techniques available in D language that are being used by the Pegged library this is a handy guide:
Nice paper. Two columns. Why? In the 1980's computer science conferences like STOC and FOCS would hand out telephone-book sized proceedings, and it took two columns to squeeze it all in. Not relevant now, but the two columns make it that much harder to read on a tablet. I don't generally wish ill on anyone, but it's hard not to wish that the editors responsible for this idiotic convention would just die or retire in either order.
Also, this paper is from ICFP 2002 whose proceedings were published in print form. Several libraries hold it: https://www.worldcat.org/title/proceedings-of-the-seventh-ac...
Anyway it appears that from 2017 onwards the ICFP proceedings are no longer published in print (they're published as part of PACMPL, an electronic journal), and indeed the ICFP 2020 papers for example (https://dl.acm.org/toc/pacmpl/2020/4/ICFP) are not in two columns anymore. So everything seems reasonable IMO.
On the other hand, I have often wondered why this convention was used so much, especially when some types of content would never reasonably fit into a single column (and people didn't want to float a graphic in there)
What sort of tablet are you using in 2020 which doesn't have the pinch-to-zoom functionality?
"two columns to squeeze it all in" Just use a single column and half the pages then...