Hello, > If the s-expression is a compile-time constant, and if the PEG compiler > is written in purely-functional style and confined within a single > top-level form, then peval should be able to produce the parser > procedure at compile-time. Otherwise, it would be produced at run-time. > > This is part of the reason partial evaluation is so exciting. It's not > just about increasing the speed of existing programs. More importantly, > it allows you to write new programs more elegantly.
I agree, and in fact I sent an email a few days ago saying the same thing. :-) I suspect that any macro that doesn't introduce variable bindings could be written that way, which would be excellent. It might also be much easier to write, because there are better debugging facilities for interpreters than macros, like the trace command and the debugger. I hope peval gets to that point soon. Since you've brought it up, I've been thinking of a feature I would want before using that style. peval by default will have to restrict what it inlines to save space. I'd like a way to guarantee that the things I want inlined would be inlined, by calling peval myself. So the best way to do PEG might be something like (define (peg-sexp-compile sexp) (peval (lambda (string) (peg-sexp-interpret sexp string)) #:full)) or something along those lines, where #:full indicates that all of peg-sexp-interpret should be inlined. (Although in real life you'd want a much better way to indicate what should be inlined, and I don't know what it is yet. I haven't thought through the interface at all.) That is a long term idea for peval, though. It looks like there are many more urgent things to do. Noah