问题标签 [peg]

Treetop 似乎在第一个规则之后忽略了更多规则，并且无法解析与语法文件中的第一个规则不匹配的任何内容。我已经尝试交换规则的顺序，但仍然只考虑第一个。

此语法文件匹配所有整数和浮点数，但不匹配 '123, 456' 或 '123,456' 解析器 failure_reason 属性显示此“预期 - 在第 1 行第 1 列（字节 1）之后”

我错过了什么吗？

I'm using the Python Parsimonious Parser to try to build an interpreter for a simple language I'm designing. I watched this tutorial video which was very helpful, and now I'm slowly modifying the code to match my own rules. I'm stuck on an assignment rule originally defined as:

I modified the rule slightly with the following grammar:

I'd like the parser to evaluate SET a, 7 for example, the same as a = 7 and bind the value 7 to the name a. However, when I attempt to parse it, I get this error from the Parsimonious library:

I'm fairly new to parsing/lexing and am not entirely sure if I defined the rule correctly. Was hoping someone with more parsing/lexing experience can help me properly define the rule and explain where I went wrong. Also perhaps explain the Parsimonious error to me?

我正在尝试使用 PEG.js 构建一个简单的解析器。我希望用户能够输入一系列关键字，它们之间有一个可选的“AND”，但我似乎无法获得可选和工作。它总是期待它，即使我已经用 ? （零或一）。

将此语法粘贴到http://pegjs.majda.cz/online：

我的目标是将这些输入中的任何一个解析为 ["foo", "bar"] 的数组：

首先...是否可以使用 PEG 完成简单的语法突出显示。

我只是在寻找它能够识别和突出 C 风格语言常见的基本内容

第二...如果有任何类似的例子，请告诉我

第三...如果我以错误的方式进行此操作，并且有更常见且经过验证的方法可以做到这一点，那么也请告诉我

我正在尝试扩展PEG.js的示例语法，以使用我的在线 BASIC 解释器实验的所有 4 个运算符解析数学表达式：

http://www.dantonag.it/basicjs/basicjs.html

但并非所有表达式都被正确解析。

这是我的 PEG 语法：

它可以正确解析像 2*3+1（给出 7）这样的表达式，但不能正确解析像 2-1-1 这样给出 2 而不是 0 的表达式。

你能帮我改进和调试吗？

提前致谢。

编辑：我在语法中添加了“数字”规则。是的，我的语法给出了一个类似于解析树的递归结构作为输出。

以下模式（来自此页面）仅匹配带有平衡括号的字符串：

1-是什么1 - lpeg.S"()"意思？

+1in是什么patt / repl + 1意思？

/而且我仍然不能很好地从这篇论文中得到优先选择算子的功能

任何帮助将不胜感激！

我正在玩PEG.js和阅读，在Nathans 大学我找到了一个很好的“解释”如何构建我自己的语言，但我坚持这一步

我不明白primary请给我解释一下

测试

我的问题是为什么需要/ "(" comma:comma ")"如果条目没有括号，如果删除该行最后一个测试失败

我正在寻找一个 peg.js 语法表达式来匹配：

• "variable"# 失败
• "variable."# 失败
• ""# 失败
• "variable.variable"＃ 好的
• "variable.variable.variable.variable.variable"＃好的

我期望的输入

• {PATH: "variable.variable"}
• {PATH: "variable.variable.variable.variable.variable"}

示例.pegjs

我不知道如何使表达式重复，但也使它成为可选的。

Grammar:

Input:

Question: Which error message correct at position 2 for given input?

P.S.

I write parser and I have choice (dilemma) take into account that "b" expected at position or not take.

The #1 error (expected "b", "c") want to say that input "a b" expected but because it optional it may not expected but possible.

I don't know possible is the same as expected or not?

Which error message better and correct #1 or #2?

Thanks for answers.

P.S.

In first case I define marker of testing as limit of position.

Limit moved in optional expressions:

The "b" expression move _inputPos above the testing pos and add failure at _inputPos.

In second case I can define marker of testing as boolean flag.

The "b" expression in this case not add failure because it tested (inner for optional expression).

What you think what is better and correct?

1. Testing defined as specific position and if expression above this position (_inputPos > testing) it add failure (even it inside optional expression).

2. Testing defined as flag and if this flag set that the failures not takes into account. After executing optional expression it restore (not reset!) previous value of testing (true or false).

Also failures not takes into account if rule not fails. They only reported if parsing fails.

P.S.

Changes at 06 Jan 2014

This question raised because it related to two different problems.

First problem:

Parsing expression grammar (PEG) describe only three atomic items of input:

• terminal symbol
• nonterminal symbol
• empty string

This grammar does not provide such operation as lexical preprocessing an thus it does not provide such element as the token.

Second problem:

What is a grammar? Are two grammars can be considred equal if they accept the same input but produce different result?

Assume we have two grammar:

Grammar 1

rule <- type? identifier

Grammar 2

rule <- type identifier / identifier

They both accept the same input but produce (in PEG) different result.

Grammar 1 results:

• {type : type, identifier : identifier}
• {type : null, identifier : identifier}

Grammar 2 results:

• {type : type, identifier : identifier}
• {identifier : identifier}

Quetions:

• Both grammar equal?
• It is painless to do optimization of grammars?

My answer on both questions is negative. No equal, Not painless.

But you may ask. "But why this happens?".

I can answer to you. "Because this is not a problem. This is a feature".

In PEG parser expression ALWAYS consists from these parts.

ORDERED_CHOICE => SEQUENCE => EXPRESSION

And this explanation is the my answer on question "But why this happens?".

Another problem.

PEG parser does not recognize WHITESPACES because it does not have tokens and tokens separators.

Now look at this grammar (in short):

program <- WHITESPACE expr EOF

expr <- ruleX

ruleX <- 'X' WHITESPACE

WHITESPACE < ' '?

EOF <- ! .

All PEG grammar desribed in this manner.

First WHITESPACE at begin and other WHITESPACE (often) at the end of rule.

In this case in PEG optional WHITESPACE must be assumed as expected.

But WHITESPACE not means only space. It may be more complex [\t\n\r] and even comments.

But the main rule of error messages is the following.

If not possible to display all expected elements (or not possible to display at least one from all set of expected elements) in this case is more correct do not display anything.

More precisely required to display "unexpected" error mesage.

How you in PEG will display expected WHITESPACE?

• Parser error: expected WHITESPACE
• Parser error: expected ' ', '\t', '\n' , 'r'

What about start charcters of comments? They also may be part of WHITESPACE in some grammars.

In this case optional WHITESPACE will be reject all other potential expected elements because not possible correctly to display WHITESPACE in error message because WHITESPACE is too complex to display.

Is this good or bad?

I think this is not bad and required some tricks to hide this nature of PEG parsers.

And in my PEG parser I not assume that the inner expression at first position of optional (optional & zero_or_more) expression must be treated as expected. But all other inner (except at the first position) must treated as expected.

Example 1:

This failure take into account and report as "expected '>'" This is because we not skip "type" but enter into "type" and after really optional "List" we move position from first to next real "expected" (that already outside of testing position) element.

"List" was in "testing" position.

If inner expression (inside optional expression) "fits in the limitation" not continue at next position then it not assumed as the expected input.

From this assumption has been asked main question.

You must just take into account that we are talking about PEG parsers and their error messages.

以Parslet自己的创建者的代码示例（可在此链接中获得）作为起点，我需要对其进行扩展，以便从以类 C 语法编写的文件中检索所有未注释的文本。

提供的示例能够成功解析 C 风格的注释，将这些区域视为常规行空间。但是，这个简单的示例只需要文件的非注释区域中的“a”字符，例如输入示例：

用于检测非注释文本的规则很简单：

因此，我需要概括前面的规则以从更通用的文件中获取所有其他（未注释的）文本，例如：

我是 Parsing Expression Grammars 的新手，我之前的试验都没有成功。