My Dylan PEG parser has optional clauses associated with a production. One
clause (“afterwards”) executes if the parse succeeds, and can alter the
semantic value returned by the production, inspect the sub-tokens that the
production matched, and cause the parse to fail. The other clause (“cleanup”)
is executed whether the parse succeeds or fails, but I haven’t actually found
much use for it; I envisioned it to clean up global state created for lower
productions, but grammar attributes seem to work better.
One significant question you’ll have to answer is how code associated with a
production interacts with the parse cache that defines a packrat parser. Should
the code execute only once, or should it execute every time the production’s
value is called upon? I chose to execute the code only once, on the assumption
that any operations it performs will be integrated into the production’s cached
semantic value, but that has screwed me up on occasion. But I figure there’d be
screw-ups on occasion either way.
In the general case, you can’t *enforce* that the operations be only functional
(unless you are using a functional language, of course, but I don’t think you
are). Even if you do rely on the programmer to only call pure functions, you
would still have to answer that question and figure out a way to replace the
normal semantic value with whatever the code returns.
On Oct 19, 2010, at 3:59 PM, Alan Post 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
