Hello, I tried looking at it a bit. First of all, your cleanups are awesome. :)
Unfortunately, I need to ask for help in order to work on this more. I thought I would first move the code-generating functions to their own module. It seems like this should be a simple and obviously-correct transformation, because I didn't change any code - just moved it to its own module, and replaced its definition by a (use-modules ...) clause. Yet I have somehow created an error, and I don't see why. If you have time, could someone please explain why the attached patch does not work? I am afraid there is some interaction between modules and syntax generators that I don't understand. The patch will apply to the wip-mlucy branch. Thanks, Noah On Fri, Feb 18, 2011 at 5:03 PM, Andy Wingo <wi...@pobox.com> wrote: > On Wed 02 Feb 2011 01:26, Noah Lavine <noah.b.lav...@gmail.com> writes: > >> Here it is! All of the unhygienic syntax is gone, is a series of only >> 20 commits. :-) The peg.test tests should all pass after each one of >> these commits. > > Thanks! You've probably seen that I've applied this to wip-mlucy, which > we should probably rename wip-peg. I've also added on a number of > cleanups of my own, some of which I will push out shortly when my ISP > figures out the route to git.sv.gnu.org again (hah). > > The branch still needs some work before it can go in. I have a feeling > that it should probably be split into two modules -- one providing the > things that peg-sexp-compile needs (minus `peg' patterns perhaps?) and > another that uses the "base" library to define a PEG grammar. Perhaps? > In any case we need to not have the entire thing in one big ol' > eval-when. > > Also, the documentation needs some help, and perhaps the patterns need > some tweaking -- for example (& pat) makes more sense than (body & pat > 1) or the like. > > I think Michael's work was pretty great, especially considering the > scope of the problem. It has the potential to have so wide an impact > that we should focus on making it have exactly the right interface > before we merge it in. > > Onwards, upwards, etc.! > > Andy > -- > http://wingolog.org/ >
0001-Move-PEG-code-generators-into-their-own-module.patch
Description: Binary data
