For the problem I was solving when I wrote the e-mail, I decided
to return the AST from some nonterminals, but have other non-terminal
nodes transform the AST to a string inline and return it, resulting in
a transformed string at the end of the parse.
For the additional information I was interested in passing along, I
settled on immediately executing the code for that rule but undoing
the changes I made if later non terminals did not parse. (Suggested
elsewhere in this thread.)
I happened to be lucky enough to have a single 'or' rule in my grammar
that could handle all of the unwinding as each of its rules failed.
My unwind rule was clearing a stack, making unwinding simple too.
My next parse project is much more complicated, and I'm going to be
more formal in solving it by working on the AST in a separate pass.
-Alan
On Wed, Oct 20, 2010 at 02:16:48AM +0200, Orlando Hill wrote:
> Hi Alan,
>
> I'm not sure that there is a typical approach. Either of your
> suggested methods should work. It just depends on what you want your
> grammar language to be able to express.
>
> If you really want to embed print statements into your grammars,
> collecting the code snippets would seem the way to go.
>
> If the languages you're transforming are much more complex than your
> example, it might be easier to have the parser build an AST and then
> traverse the AST to generate further output. That way, you can chain
> transformations of the AST together rather than trying to do
> everything in a single pass.
>
> Orlando.
>
> On Wed, Oct 20, 2010 at 12:59 AM, Alan Post <alanp...@sunflowerriver.org>
> wrote:
> > Hello List,
> >
> > I've just started using and working on a packrat parser.
> >
> > My specific problem is that I have an input language that I want to
> > transform into an output language and collect some data about what
> > occured during the parse.
> >
> > As a simple example, imagine the following grammar and code:
> >
> > start <- a b c / b
> >
> > a <- 'a' {print "a"}
> > b <- 'b' {print "b"}
> > c <- 'c' {print "c"}
> >
> > If I give the input "ab", this is is not a valid string, but if the
> > code immediately executes during the parse, It will print both "a"
> > and "b". A more complex example might parse a fair part of the input
> > before backtracking.
> >
> > Given that backtracking could make code executed in-place like this
> > invalid, what is typical in a packrat parser if the code can be
> > specified inline like this?
> >
> > Do I limit myself to non-destructive (functional) operations? Do I
> > collect the code snippets and execute all of them after a valid parse?
> > Something else?
> >
> > Thank you for your help,
> >
> > -Alan
> > --
> > .i ko djuno fi le do sevzi
> >
> > _______________________________________________
> > PEG mailing list
> > PEG@lists.csail.mit.edu
> > https://lists.csail.mit.edu/mailman/listinfo/peg
> >
>
> _______________________________________________
> 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
