Thank you for sharing this. I've "watched" your project, and when I'm next working on the documentation I'll put a link to your parser in my "see also" section.
I'll send a note once I've had a chance to do that. I wish your parser had been listed on this page: http://pdos.csail.mit.edu/~baford/packrat/ which collects links to packrat parsers and which is the #1 page on google search on the subject. I considered the approach you've settled on and decided to solve my problem another way, largely because I have an existing PEG grammar I'm using, and I was not interested in hand-converting it to scheme. I do like your approach generally, however, as you leverage the features your language gives you. Tony Garnock-Jones, who published the only other scheme-based packrat parser I'm aware of did something similar, expressing the grammar using define-syntax. -Alan On Mon, Nov 15, 2010 at 11:48:29AM -0700, Jon Rafkind wrote: > In my scheme packrat parser generator I define everything with macros. > Its somewhat simpler in that I don't have to do extra parsing and I get > the benefit of using macro technology to process the Peg. > > The generator: https://github.com/kazzmir/Pegs/blob/master/peg.rkt > An example usage: > https://github.com/kazzmir/Pegs/blob/master/peg-tests/calculator.ss > > On 11/15/2010 07:32 AM, Alan Post wrote: > > I'm implementing a packrat parser in Scheme. I'm at the point of > > writing a bootstrap parser in Scheme for PEG, and my bootstrap > > parser is basically working. > > > > I haven't yet decided on the syntax for embedding code in the > > parser. My only example for doing this is peg/leg: > > > > http://piumarta.com/software/peg/peg.1.html > > > > which encloses code in {} brackets and permits references to parts > > of the parse tree with <>: > > > > { action } > > Curly braces surround actions. The action is arbitray C source > > code to be executed at the end of matching. Any braces within > > the action must be properly nested. Any input text that was > > matched before the action and delimited by angle brackets (see > > below) is made available within the action as the contents of > > the character array yytext. The length of (number of characters > > in) yytext is available in the variable yyleng. (These variable > > names are historical; see lex(1).) > > > > < An opening angle bracket always matches (consuming no input) and > > causes the parser to begin accumulating matched text. This text > > will be made available to actions in the variable yytext. > > > > > A closing angle bracket always matches (consuming no input) and > > causes the parser to stop accumulating text for yytext. > > > > What else is out there? Is this something reasonably standard or does > > every tool do something different? > > > > -Alan > > > _______________________________________________ > PEG mailing list > PEG@lists.csail.mit.edu > https://lists.csail.mit.edu/mailman/listinfo/peg -- .i ko djuno fi le do sevzi _______________________________________________ PEG mailing list PEG@lists.csail.mit.edu https://lists.csail.mit.edu/mailman/listinfo/peg
