On Fri, Aug 6, 2010 at 1:40 AM, Michael Lucy <michaelgl...@gmail.com> wrote: > On Wed, Jul 28, 2010 at 12:13 AM, Michael Lucy <michaelgl...@gmail.com> wrote: >> I've officially eliminated the last define-macro expression. >> >> However, I get the feeling that things may not be exactly as desired. >> The original program made extensive use of functions in building the >> macros, and I originally tried to replace these with macros. This >> turned out to be a little difficult to debug, however (read: I was >> unable to make the code actually work). I eventually abandoned this >> and just made datum->syntax calls. > > I've left this alone since then; it would be nice to get some > confirmation that this was the right choice though. If it isn't, I > think I still have time to change it before the GSOC deadline (and > like I said, I'll hang around after it).
So, we're essentially at the GSOC deadline. I pushed up the finished form of what I have to the git repository, plus some benchmarks. I also added a variant on packrat parsing using a cache instead of a hash (the hash performs poorly on flat text files). This turned out to be well worth it; on the relatively limited benchmarking suite it was about a 50x performance boost. Quick summary of files added (all in origin/mlucy): Actual module: module/ice-9/peg.scm Test suite: test-suite/tests/peg.test Benchmarks: test-suite/tests/peg.bench (wasn't quite sure where to put this) Documentation: doc/ref/api-peg.texi (also updated guile.texi to include it) The macros haven't been touched (except I fixed up one define-macro macro that had slipped past my radar). I'll be hanging around after the deadline tidying up a bit more (I'd like some more benchmarks); if the macro situation isn't what you guys want I'll fix it. > > Anyway, I just pushed up everything I have to the git repository (I > think; I may have screwed up the syntax). I'm basically done except > that the documentation/comments could use some more touching up, I > don't have a set of benchmarks yet and I haven't really optimized > things all that much. > >> >> On the one hand, this works. I also find it easier to debug, and I >> think it looks cleaner. >> >> The downside is that one doesn't get all the same benefits of >> referential transparency, so I still have gensyms in the functions >> etc. Is this a problem? >> >> If so, I can definitely replace everything with macros, but I might >> not be able to do that and get everything else done by the GSOC >> project deadline. I'd like to hang around after the project is >> officially done from Google's point of view to polish things up, so I >> could also do it then. >> >> Another question about module namespaces: I have some syntax that I'd >> like to be available to code generated by macros in my module, but >> which I'd rather not export to the user (to avoid clobbering their >> functions). Is there a standard way of doing this? I can't seem to >> find anything in the module documentation regarding giving namespaces >> to things in modules except for :renamer, which has to be done by the >> user--the only options appear to be not exporting it at all, or >> exporting it straight into the user's namespace. The best fix I can >> think of is naming the syntax things the user is unlikely to ever take >> (or maybe using gensyms to make sure it isn't a name they take). >> >