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
