grammar

Imagine a simple grammar: (a|ab)c Which reads (a or ab) followed by c. The parse tree would look like this: and / \ or c / \ a ab Now given it this input: abc We would traverse first down the left side of the tree, and match "a", then go back up a level. Since "a" matched, the "or" is also true, so move on to the "c". "c" does not match, and we hit the end of the road. But there was an alternate path it could have taken; had we traversed down to "ab", we would have found a match. So what I want to do for "or" nodes is essentially this: Evaluate left branch If left branch doesn't match, try

S -> bA|aB A -> a|aS|bAA B -> b|bS|aBB Any easy method other than trying to find a string that would generate two parse trees ? Can someone please give me a string that can prove this. There is no easy method for proving a context-free grammar ambiguous -- in fact, the question is undecidable , by reduction to the Post correspondence problem . Shweta There is a string though: bbaaba S -> bA -> bbAA -> bbaA -> bbaaS -> bbaabA -> bbaaba S -> bA -> bbAA -> bbaSA -> bbaaBA -> bbaabA -> bbaaba 来源： https://stackoverflow.com/questions/4878418/how-can-i-prove-that-this-grammar-is-ambiguous

I would like to know the name of the syntax used for the Cloud Firestore security rules as described at https://firebase.google.com/docs/firestore/security/get-started?authuser=0 . I would like to find syntax highlighter for that syntax and maybe parsers for it. Firebase Security Rules is a custom DSL. Condition expressions are JS like, and should work with one of those. The path matching framework is less common, but we're working on providing the grammar + additional tooling (syntax highlighting, parsing, type checking, evaluators) in the future. For those interested in the history, the

I am revamping an inhouse C language bison/flex-based parser, amongst others introducing proper __ attribute__ support. Since I cannot find any official BNF-style grammar which describes GNU GCC __ attribute__ idea (except the http://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html document) I am extracting bits and pieces from the C++x11 standard and comments in various implementations found over the web. I have almost got it done (at least when it comes to parsing examples included in GCC's doc cited above) but one particular example has given me a headache with no hint of solution in

This is a follow up question from Grammar: difference between a top down and bottom up? I understand from that question that: the grammar itself isn't top-down or bottom-up, the parser is there are grammars that can be parsed by one but not the other (thanks Jerry Coffin So for this grammar (all possible mathematical formulas): E -> E T E E -> (E) E -> D T -> + | - | * | / D -> 0 D -> L G G -> G G G -> 0 | L L -> 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 Would this be readable by a top down and bottom up parser? Could you say that this is a top down grammar or a bottom up grammar (or neither)? I am

I have the following grammar: S → a S b S | b S a S | ε Since I'm trying to write a small compiler for it, I'd like to make it LL(1). I see that there seems to be a FIRST/FOLLOW conflict here, and I know I have to use substitution to resolve it, but I'm not exactly sure how to go about it. Here is my proposed grammar, but I'm not sure if it's correct: S-> aSbT | epsilon T-> bFaF| epsilon F-> epsilon Can someone help out? templatetypedef In his original paper on LR parsing , Knuth gives the following grammar for this language, which he conjectures "is the briefest possible unambiguous grammar

I have written a grammar for vaguely Java-like DSL. While there are still some issues with it (it doesn't recognize all the inputs as I would want it to), what concerns me most is that the generated C code is not compilable. I use AntlrWorks 1.5 with Antlr 3.5 (Antlr 4 apparently does not support C target). The problem is with expression rules. I have rules prio14Expression to prio0Expression which handle operator precedence. To problem is at priority 2, which evaluates prefix and postfix operators: ... prio3Expression: prio2Expression (('*' | '/' | '%') prio2Expression)*; prio2Expression: ('+

Silly question, but why does the following line compile? int[] i = new int[] {1,}; As you can see, I haven't entered in the second element and left a comma there. Still compiles even though you would expect it not to. I suppose because the ECMA 334 standard say: array-initializer: { variable-initializer-list(opt) } { variable-initializer-list , } variable-initializer-list: variable-initializer variable-initializer-list , variable-initializer variable-initializer: expression array-initializer As you can see, the trailing comma is allowed: { variable-initializer-list , } ↑ P.S. for a good answer