lalr

问题 I had lots of conflicts, most of them were due to operators and relational operators which had different precedences. But I still face some conflicts that I don't really know how to tackle them. some of them are below. I suspect that maybe I should do epsilon elimination for stmtlist but to be honest I'm not sure about it. state 70: state 70 (27) block -> LCB varlist . stmtlist RCB (25) varlist -> varlist . vardec (28) stmtlist -> . stmt (29) stmtlist -> . stmtlist stmt (30) stmtlist -> . (15

问题 A disadvantage of a (LA)LR parser is that a reduce is only processed at the end of a rule. This is a problem in programming languages with scoped variables like javascript . Example: var a = 2; function (a) { a = 4; } See the above code example. A parser could look like: program : instruction program {} | {} ; instruction : command {} | function {} ; command : "var" identifier "=" literal ";" {} ; function : "function" "(" arguments ")" "{" program "}" {/*1*/} ; arguments : identifier {} |

问题 I'm implementing the automatic construction of an LALR parse table for no reason at all. There are two flavors of this parser, LALR(0) and LALR(1), where the number signifies the amount of look-ahead. I have gotten myself confused on what look-ahead means. If my input stream is 'abc' and I have the following production, would I need 0 look-ahead, or 1? P :== a E Same question, but I can't choose the correct P production in advance by only looking at the 'a' in the input. P :== a b E | a b F I

问题 I'm implementing the automatic construction of an LALR parse table for no reason at all. There are two flavors of this parser, LALR(0) and LALR(1), where the number signifies the amount of look-ahead. I have gotten myself confused on what look-ahead means. If my input stream is 'abc' and I have the following production, would I need 0 look-ahead, or 1? P :== a E Same question, but I can't choose the correct P production in advance by only looking at the 'a' in the input. P :== a b E | a b F I

问题 TL;DR VERSION: Is there a parser generator that supports the following: when some rule is reduced (I assume LALR(1) parser), then reduction isn't performed, but parser backs off and replaces input with different code using values from this rule and parses that code. Repeat if needed. So if code is "i++" and rule is "expr POST_INCR", I can do more or less: expr POST_INCR -> "(tmp = expr; expr = expr + 1; tmp)" So basicaly code rewriting using macros? LONG VERSION: I wrote yet another simple

问题 I need to parse a block of code which looks like this: * Block | Line 1 | Line 2 | ... It is easy to do: block : head lines; head : '*' line; lines : lines '|' line | '|' line ; Now I wonder, how can I add nested blocks, e.g.: * Block | Line 1 | * Subblock | | Line 1.1 | | ... | Line 2 | ... Can this be expressed as a LALR grammar? I can, of course, parse the top-level blocks and than run my parser again to deal with each of these top-level blocks. However, I'm just learning this topic so it

问题 A lot of websites states that packrat parsers can parse input in linear time. So at the first look they me be faster than LALR parser contructed by the tools yacc or bison. I wanted to know if the performance of packrat parsers is better/worse than the performance of LALR parser when tested with common input (like programming language source files) and not with any theoretical inputs. Does anyone can explain the main differences between the two approaches. Thanks! 回答1: I'm not an expert at

问题 I'm currently using happy to parse a language, but I don't think the parser is relevant, except to say it's an LALR parser. Here's a small excerpt from the grammar: ArithExpr -> ArithExpr + ArithExpr ArithExpr -> ( ArithExpr ) ArithExpr -> ... BoolExpr -> ArithExpr == ArithExpr BoolExpr -> ( BoolExpr ) BoolExpr -> ... The problem is that I'm getting reduce-reduce conflicts. I think the issue arises when I try to parse something like the following: ( ( 2 + 3 ) == ( 4 + 5 ) ) There's only one

问题 I'm attempting to write a grammar to parse templating language say jinja2 (or twig at your choose), and I can't successfully parse switch-case statement. Let me show desired syntax: {% switch username %} {% case "Jim" %} I want to say: {% case "Nik" %} Hello man! {% endcase %} {% case "Bob" %} Hi {% default %} Who are you? {% endswitch %} Here endcase just works as break. Worked portion of my grammar file: program ::= template_language(Q) . { status->ret = Q; } template_language(R) ::=

问题 I want to make a python program that uses PLY to parse Javascript files, I din't found any sources of parsers that implement the ECMAScript, Javascript rules that use PLY. The only thing I found was some ANTLR grammar files to parse javascript and ecmascript: http://www.antlr.org/grammar/1153976512034/ecmascriptA3.g http://www.antlr.org/grammar/1206736738015/JavaScript.g Can ANTLR grammar files be adapted to be used as PLY rules, if yes, how can be done in a semi-automatic way, do I need to