grako

Improving errors output by Grako-generated parser

由 痞子三分冷 提交于 2019-12-25 08:57:05
问题 I'm trying to figure out the best approach to improving the errors displayed to a user of a Grako-generated parser. It seems like the default parse errors displayed by the Grako-generated parser when it hits some parsing issue in the input file are not helpful. The errors often seem to imply the issue is in one part of the input file when the true error is somewhere different. I've been looking into the Grako Semantics class to put in some checks which would display better error messages if

Do I have a bug in my grammar, or the parser-generation tool?

由 倖福魔咒の 提交于 2019-12-12 13:50:55
问题 The following is an EBNF-format (mostly - the actual syntax is documented here) grammar that I am attempting to generate a parser for: expr = lambda_expr_list $; lambda_expr_list = [ lambda_expr_list "," ] lambda_expr; lambda_expr = conditional_expr [ "->" lambda_expr ]; conditional_expr = boolean_or_expr [ "if" conditional_expr "else" conditional_expr ]; boolean_or_expr = [ boolean_or_expr "or" ] boolean_xor_expr; boolean_xor_expr = [ boolean_xor_expr "xor" ] boolean_and_expr; boolean_and

Grako - How to do error handling?

由 梦想的初衷 提交于 2019-12-12 04:17:28
问题 How do I do error handling with Grako? EBNF (MyGrammar.ebnf): pattern = { tag | function }* ; tag = tag:( "%" name:id "%" ); function = function:("$" name:id "()" ); id = ?/([^\\%$,()=])+/? ; I'm generating the parser with python -m grako --whitespace '' MyGrammar.ebnf > my_parser.py Parsing an empty string and a "bad" string (that could not be matched by the grammar) both results to an empty AST Closure. parser = MyGrammarParser() ast = parser.parse(u"%test%", rule_name='pattern') #ast

Rule precedence issue with grako

由 情到浓时终转凉″ 提交于 2019-12-01 09:23:22
I'm redoing a minilanguage I originally built on Perl (see Chessa# on github ), but I'm running into a number of issues when I go to apply semantics. Here is the grammar : (* integers *) DEC = /([1-9][0-9]*|0+)/; int = /(0b[01]+|0o[0-7]+|0x[0-9a-fA-F]+)/ | DEC; (* floats *) pointfloat = /([0-9]*\.[0-9]+|[0-9]+\.)/; expfloat = /([0-9]+\.?|[0-9]*\.)[eE][+-]?[0-9]+/; float = pointfloat | expfloat; list = '[' @+:atom {',' @+:atom}* ']'; (* atoms *) identifier = /[_a-zA-Z][_a-zA-Z0-9]*/; symbol = int | float | identifier | list; (* functions *) arglist = @+:atom {',' @+:atom}*; function =

Rule precedence issue with grako

由 妖精的绣舞 提交于 2019-12-01 06:10:53
问题 I'm redoing a minilanguage I originally built on Perl (see Chessa# on github), but I'm running into a number of issues when I go to apply semantics. Here is the grammar: (* integers *) DEC = /([1-9][0-9]*|0+)/; int = /(0b[01]+|0o[0-7]+|0x[0-9a-fA-F]+)/ | DEC; (* floats *) pointfloat = /([0-9]*\.[0-9]+|[0-9]+\.)/; expfloat = /([0-9]+\.?|[0-9]*\.)[eE][+-]?[0-9]+/; float = pointfloat | expfloat; list = '[' @+:atom {',' @+:atom}* ']'; (* atoms *) identifier = /[_a-zA-Z][_a-zA-Z0-9]*/; symbol =

Parsing of optionals with PEG (Grako) falling short?

由 北战南征 提交于 2019-12-01 03:52:54
问题 My colleague PaulS asked me the following: I'm writing a parser for an existing language (SystemVerilog - an IEEE standard), and the specification has a rule in it that is similar in structure to this: cover_point = [[data_type] identifier ':' ] 'coverpoint' identifier ';' ; data_type = 'int' | 'float' | identifier ; identifier = ?/\w+/? ; The problem is that when parsing the following legal string: anIdentifier: coverpoint another_identifier; anIdentifier matches with data_type (via its
订阅 grako