CoCo 到 ANTLR 转换器中的表达式
我正在一个实用程序中解析 CoCo/R 语法以自动化 CoCo -> ANTLR 翻译。核心 ANTLR 语法是:
rule '=' expression '.' ;
expression
: term ('|' term)*
-> ^( OR_EXPR term term* )
;
term
: (factor (factor)*)? ;
factor
: symbol
| '(' expression ')'
-> ^( GROUPED_EXPR expression )
| '[' expression']'
-> ^( OPTIONAL_EXPR expression)
| '{' expression '}'
-> ^( SEQUENCE_EXPR expression)
;
symbol
: IF_ACTION
| ID (ATTRIBUTES)?
| STRINGLITERAL
;
我的问题是这样的结构:
CS = { ExternAliasDirective }
{ UsingDirective }
EOF .
CS 结果是带有 OR_EXPR 节点的 AST,尽管没有“|”特点 实际上出现了。我确信这是由于定义 表达式,但我看不到任何其他方式来编写规则。
我确实对此进行了实验以解决歧义。
// explicitly test for the presence of an '|' character
expression
@init { bool ored = false; }
: term {ored = (input.LT(1).Type == OR); } (OR term)*
-> {ored}? ^(OR_EXPR term term*)
-> ^(LIST term term*)
它确实有效,但这次黑客攻击让我更加坚信某些根本性的问题是错误的。
非常感谢任何提示。
I'm parsing CoCo/R grammars in a utility to automate CoCo -> ANTLR translation. The core ANTLR grammar is:
rule '=' expression '.' ;
expression
: term ('|' term)*
-> ^( OR_EXPR term term* )
;
term
: (factor (factor)*)? ;
factor
: symbol
| '(' expression ')'
-> ^( GROUPED_EXPR expression )
| '[' expression']'
-> ^( OPTIONAL_EXPR expression)
| '{' expression '}'
-> ^( SEQUENCE_EXPR expression)
;
symbol
: IF_ACTION
| ID (ATTRIBUTES)?
| STRINGLITERAL
;
My problem is with constructions such as these:
CS = { ExternAliasDirective }
{ UsingDirective }
EOF .
CS results in an AST with a OR_EXPR node although no '|' character
actually appears. I'm sure this is due to the definition of
expression but I cannot see any other way to write the rules.
I did experiment with this to resolve the ambiguity.
// explicitly test for the presence of an '|' character
expression
@init { bool ored = false; }
: term {ored = (input.LT(1).Type == OR); } (OR term)*
-> {ored}? ^(OR_EXPR term term*)
-> ^(LIST term term*)
It works but the hack reinforces my conviction that something fundamental is wrong.
Any tips much appreciated.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
您的规则:
始终导致重写规则创建根类型为
OR_EXPR
的树。您可以像这样创建“子重写规则”:为了解决语法中的歧义,最简单的方法是启用全局回溯,这可以在语法的
options { ... }
部分中完成。一个快速演示:
使用输入:
生成 AST:
,输入:
生成:
测试此类:
并使用该类生成的输出,我使用以下网站创建 AST 图像:< a href="http://graph.gafol.net/" rel="nofollow noreferrer">http://graph.gafol.net/
HTH
编辑
要考虑
OR
表达式,您可以尝试这样的操作(快速测试!):它将源:解析
为以下 AST:
Your rule:
always causes the rewrite rule to create a tree with a root of type
OR_EXPR
. You can create "sub rewrite rules" like this:And to resolve the ambiguity in your grammar, it's easiest to enable global backtracking which can be done in the
options { ... }
section of your grammar.A quick demo:
with input:
produces the AST:
and the input:
produces:
The class to test this:
and with the output this class produces, I used the following website to create the AST-images: http://graph.gafol.net/
HTH
EDIT
To account for epsilon (empty string) in your
OR
expressions, you might try something (quickly tested!) like this:which parses the source:
into the following AST:
expression
的产生式明确表示它只能返回一个OR_EXPR
节点。您可以尝试以下操作:再往下,您可以使用:
The production for
expression
explicitly says that it can only return anOR_EXPR
node. You can try something like:Further down, you could use: