Alan
Yes, but I don't follow your last question...
Probably more than the group wants to know so I'm happy to talk to you
offline:
cashin.pe...@gmail.com
Peter.
On Fri, Dec 10, 2010 at 10:13 AM, Alan Post <alanp...@sunflowerriver.org>wrote:
> Peter,
>
> This is fantastic, thank you.
>
> Help me understand:
>
> A <- B `C 'd'
> B <- 'b'
> C <- 'c'
>
> Here production A includes two non-terminal (B and C) and one terminal
> ('d') rule.
>
> Do I understand that 'd' in this case does *not* produce a node in
> the syntax tree, but that rule B and C do? But that after C
> generates a node, the ` arranges not to have it placed in the syntax
> tree? If so, what rule do you use to disambiguate the case where 'd'
> does not produce a node but 'b' does?
>
> -Alan
>
> On Fri, Dec 10, 2010 at 09:53:42AM +1300, Peter Cashin wrote:
> > Hi Alan
> > I have been working on grammar rules I'm calling PBNF, for Parser-BNF,
> > that can be automatically executed as a parser. The PEG operators are
> a
> > subset of the PBNF operators, but to fully automate a grammar I need
> to
> > define the implicit syntax tree that the grammar rules specify.
> > Your issue comes up all the time in that context: my approach is to
> have a
> > literal 'x' match without producing a syntax tree node (you can always
> add
> > a rule if you do want it in the syntax tree). Rules that generate leaf
> > nodes are designated in the grammar, they are terminal rules if you
> like,
> > so they generate a literal match (but no internal syntax sub-tree).
> But
> > sometimes you want to reference a rule but still not to generate a
> syntax
> > tree node, and I have used the `x operator: the ` prefix is a sort of
> > quote like, and its unobtrusive in the grammar.
> > If you want to take a look you will find it all at:
> > [1]http://github.com/spinachtree/gist
> > Maybe other people have different solutions, I'd like to know..
> > Cheers,
> > Peter.
> >
> > On Fri, Dec 10, 2010 at 9:01 AM, Alan Post
> > <[2]alanp...@sunflowerriver.org> wrote:
> >
> > I'm working on my PEG parser, in particular the interface between
> > the parse tree and the code one can attach to productions that
> > are executed on a successful parse.
> >
> > I've arranged for the two predicate operations, & and !, to not add
> > any output to the parse tree. That means that the following
> > production:
> >
> > rule <- &a !b "c"
> >
> > Produces the same parse tree as:
> >
> > rule <- "c"
> >
> > Internally, this means that I recognize that the sequence operator
> > (which contains the productions '&a', '!b', and '"c"' in this
> > example) is being called with predicates in every position but one,
> > and rather than returning a list containing that single element,
> > I return just the single element.
> >
> > As I've been doing this, I've found that I want a new operator
> similar
> > to '&'. '&' matches the production it is attached to, but it does
> not
> > advance the position of the input buffer.
> >
> > I'd like an operator that matches the production it is attached to,
> > advances the input buffer, but doesn't add anything to the parse
> > tree.
> >
> > Here's an example:
> >
> > mulexp <- digit '*' digit EOF -> {(lambda (x y) (* x y))}
> >
> > the mulexp production is a sequence of four other rules, but only
> > two of them are needed by the associated code. It would be nice
> > if I could write the code rule like it is above, rather than say
> > this:
> >
> > (lambda (x op y EOF) (* x y))
> >
> > Having to account for all the rules in the sequence, but really
> > only caring about two of them. Here is the example rewritten
> > with '^' expressing "match the rule, advance the input, but don't
> > modify the parse tree":
> >
> > mulexp <- digit ^'*' digit ^EOF -> {(lambda (x y) (* x y))}
> >
> > Before I go inventing syntax for this use case, will you tell me if
> > this is already being done with other parsers? Have any of you had
> > this problem and already solved it, and if so, what approach did you
> > take?
> >
> > -Alan
> > --
> > .i ko djuno fi le do sevzi
> >
> > _______________________________________________
> > PEG mailing list
> > [3]...@lists.csail.mit.edu
> > [4]https://lists.csail.mit.edu/mailman/listinfo/peg
> >
> > References
> >
> > Visible links
> > 1. http://github.com/spinachtree/gist
> > 2. mailto:alanp...@sunflowerriver.org
> > 3. mailto:PEG@lists.csail.mit.edu
> > 4. 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
