Hi Casey In my OMeta implementations I have found that simply recording the position of the deepest error and then printing out the remaining input text was sufficient to debug my grammars.
I think the next step I would take (if that wasn't sufficient) is to create a test suite that tests each grammar rule independently, successively building up to the complex input that is failing. John On Tue, 2011-12-13 at 23:17 -0800, Casey Ransberger wrote: > I know this has come up before. Hopefully I'm not about to repeat a lot. > > Debugging this stuff just seems really hard. And significantly harder than > what I've experienced working with e.g. Yacc. > > Hypothesis: Yacc had a lot of time to bake before I ever found it. PEGs are > new, so there's been less overall experience with debugging them. > > I've experimented in what little time I can devote with OMeta, PetitParser, > and Treetop. The debugging experience has been roughly consistent across all > three. > > One particular issue which has bugged me: memoization seems to carry a lot of > instance-state that's really hard to comprehend when the grammar isn't > working as I expect. It's just really hard to use that ocean of information > to figure out what I've done wrong. > > Given that with these new parsing technologies, we're pretty lucky to see > "parse error" as an error message, I can't help but think that it's worth > studying debugging strategies. Heh. :D I'm really not complaining, I'm just > pointing it out. > > Has anyone here found any technique(s) which makes debugging a grammar > written for a PEG/packrat less of a pain in the butt? > > I'd be really interested in hearing about it. > > > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
