context-free-grammar

问题 Have found C++ BNF and there next lines selection-statement: if ( condition ) statement if ( condition ) statement else statement Now trying to write parser. Need to build parse tree. On input i have BNF and source file. But i'm stucked in how i can point my parser what if condition evaluated to true, then it need to execute first statement otherwise else block? Thanks. 回答1: Conditional statements have a simple recursive structure. The corresponding recursive descent parser has a similarly

问题 Have found C++ BNF and there next lines selection-statement: if ( condition ) statement if ( condition ) statement else statement Now trying to write parser. Need to build parse tree. On input i have BNF and source file. But i'm stucked in how i can point my parser what if condition evaluated to true, then it need to execute first statement otherwise else block? Thanks. 回答1: Conditional statements have a simple recursive structure. The corresponding recursive descent parser has a similarly

问题 Here's the grammar, which is supposed to describe a language of nested braces with commas as delimiters: L ::= {L} | L,L | A few more examples of strings I'd expect the grammar to accept and reject: Accept: {,{,,{,}},,{,}} {{{{}}}} {,{}} Reject: {}{} {,{}{}} {{},{} 回答1: Done by hand: L ::= { L } | { L } , | , L | ε Or, instead of just winging it we could use a more systematic approach and apply the algorithm from Wikipedia on removing immediate left recursion: L ::= { L } L 1 | L 1 L 1 ::= ε

问题 I'm about to make a parser for a fictional subset of XML with the following EBNF grammar: DOCUMENT ::= ELEMENT ELEMENT ::= START_TAG (ELEMENT | DATA)* END_TAG | EMPTY_TAG START_TAG ::= < NAME ATTRIBUTE* > END_TAG ::= </ NAME > EMPTY_TAG ::= < NAME ATTRIBUTE* /> ATTRIBUTE ::= NAME = STRING The above is the grammar 'as is', without any changes. Here is my attempt at converting it to LL(1): DOCUMENT ::= ELEMENT EOF ELEMENT ::= PREFIX > ELEMENT_OR_DATA END_TAG | PREFIX /> PREFIX ::= < NAME OPT

问题 I'm about to make a parser for a fictional subset of XML with the following EBNF grammar: DOCUMENT ::= ELEMENT ELEMENT ::= START_TAG (ELEMENT | DATA)* END_TAG | EMPTY_TAG START_TAG ::= < NAME ATTRIBUTE* > END_TAG ::= </ NAME > EMPTY_TAG ::= < NAME ATTRIBUTE* /> ATTRIBUTE ::= NAME = STRING The above is the grammar 'as is', without any changes. Here is my attempt at converting it to LL(1): DOCUMENT ::= ELEMENT EOF ELEMENT ::= PREFIX > ELEMENT_OR_DATA END_TAG | PREFIX /> PREFIX ::= < NAME OPT

问题 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? 回答1: In his original paper on LR parsing, Knuth gives the following

问题 As we know, given a regular grammar, we have algorithm to get its regular expression. But if the given grammar is context-free grammar (but it only generates regular language), like S->aAb A->bB B->cB|d Is there any existing algorithm that can get the regular expression in general? Thanks！ 回答1: In the most general sense, there is no solution. The problem of determining whether a CFG is regular is undecidable (Greibach Theorem, last 3 pages of http://www.cis.upenn.edu/~jean/gbooks/PCPh04.pdf )

问题 It seems that recursive-descent parsers are not only the simplest to explain, but also the simplest to design and maintain. They aren't limited to LALR(1) grammars, and the code itself can be understood by mere mortals. In contrast, bottom up parsers have limits on the grammars they are able to recognize, and need to be generated by special tools (because the tables that drive them are next-to-impossible to generate by hand). Why then, is bottom-up (i.e. shift-reduce) parsing more common than

问题 A C program source code can be parsed according to the C grammar(described in CFG) and eventually turned into many ASTs. I am considering if such tool exists: it can do the reverse thing by firstly randomly generating many ASTs, which include tokens that don't have the concrete string values, just the types of the tokens, according to the CFG, then generating the concrete tokens according to the tokens' definitions in the regular expression. I can imagine the first step looks like an

问题 This article on how browsers work explains how CSS is context free, while HTML is not . But what about JavaScript, is JavaScript context free? I am learning about CFG and formal proofs, but am a long way away from understanding how to figure this out. Does anyone know if JavaScript is context free or not? 回答1: No, JavaScript is not a context-free language. It is very close to one, and the ECMAScript 5 specification does indeed use a context-free grammar 1 to describe the language's syntax