用于多语言生成的 Antlr [英] Antlr for multiple language generation

查看:26
本文介绍了用于多语言生成的 Antlr的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

这篇关于 antlr 简单示例的帖子展示了如何创建和我们java的语法.

然而,这在 Exp.g 源代码中混合了语法和 Java 源代码.

我的问题是,是否可以将语法文件与目标语言解耦,以便一个语法文件可以用于生成多个 Java、Scala、C++ 等词法分析器/解析器?

解决方案

这主要取决于语法中使用目标代码的原因.是否只是对找到的标记执行某些操作的操作代码(例如,构建符号表或替代树表示),然后删除此类本机代码并在之后进行处理(使用解析树walker 或访问者)确实没有问题.

然而,谓词是不同的.它们用于引导解析器并且还需要本机代码.您可以做的是将所有本机代码移动到您生成的解析器派生自的基类中.然后,您只需要用目标语言重新编写这个基类,并保持语法大部分没有本机代码(除了调用本机代码的单个函数调用).

这种方法的优点是不需要额外的库引用(C/C++ 中的#include,其他语言中的导入),这也是防止用于多个目标的本机代码.

This post about the antlr simple example shows how to create and us a grammar for java.

However, this intermixes the grammar and the Java source code in the Exp.g source.

My Question is, Is it possible to decouple the grammar file from the target language, so that the one grammar file can be used for generating multiple Java, Scala, C++, etc Lexers/Parsers?

解决方案

It depends mostly on the reason why target code is used in the grammar. Is it only action code to do something with the found tokens (e.g. building a symbol table or alternative tree representation) then is indeed no problem do remove such native code and do the processing afterwards (using a parse tree walker or visitor).

However, predicates are a different. They are used to guide the parser and also require native code. What you can do is to move all the native code into a base class from which your generated parser derives. You then only need to re-write this base class in your target language and keep the grammar mostly free of native code (except for a single function call, which invokes the native code).

This approach has the advantage that no additional library reference is necessary (#include in C/C++, import in other languages), which also is native code preventing use for multiple targets.

这篇关于用于多语言生成的 Antlr的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆