Antlr4 语言翻译 - 将模板逻辑与访问者类分开? [英] Antlr4 language translation - separating template logic from visitor class?

问题描述

我正在考虑将大量相对简单的 TSQL 代码切实地转换为 Groovy 代码.肯定有很多原因，但驱动原因只是看是否可以完成，并在此过程中了解编译器/语法/等.

I’m looking at pragmatically translating huge amounts of relatively simple TSQL code to Groovy code. There are a number of reasons sure, but the driving reason is just to see if it can be done and in the process learn about compilers/grammers/ etc.

Antlr4 似乎是解决这个问题的理想工具(Java 是加分项).

Antlr4 seems like the ideal tool for this problem (Java is a plus).

标记/解析 TSQL(使用语法文件)，并使用生成的 Listener/Visitor 读取树非常简单.

Tokenizing / parsing the TSQL (using a grammar file), and reading the tree using the generated Listener/Visitor is pretty straight forward.

我知道我可以在继承的访问者中创建 Groovy 代码的字符串表示，但是将匹配的 Groovy 标记值与我的 TSQLVisitor 耦合似乎不是最干净的解决方案.

I know I could just create the string representation of the Groovy code inside of my inherited visitor, but coupling the matching Groovy token values with my TSQLVisitor doesn’t seem like the cleanest solution.

这里的最佳实践是什么?以及一般用于在 Antlr4 中将一种语言映射到另一种语言?

我正在考虑的事情:

1. 使用 StringTemplate，并在 STG 文件中定义我的常规代码(我的 TSQLVisitor 将使用这些模板并返回完整的字符串Groovy 代码的表示).
2. 切换到 Antlr3支持将 StringTemplate 逻辑直接添加到 Grammar 文件中.

推荐答案

最佳实践取决于您的目标.如果转换不得引入或必须尽量减少任何额外的技术负担、性能或维护开销，则由 Ira 的评论控制.

Best practices depends on your objective. Where the conversion must not introduce or must minimize any added technical baggage or performance or maintenance overhead, then Ira's comments control.

然而，如果性能和维护不是本质问题，转换在语义上接近 1:1，并且您有能力在目标环境中添加运行时支持代码，那么 Antlr4 样式转换成为可能.当然，源语言和目标语言之间的语义差异越大，难度就越大——目标运行时支持库的大小和复杂性会适得其反.而且，只需一个深层次的差异即可推动对 Ira 开发的分析工具的需求.

If, however, performance and maintenance are not essential issues, the conversion is close to 1:1 semantically, and you have the ability to add run-time support code in the target environment, then an Antlr4 style conversion becomes possible. Of course, the greater the semantic differences between the source and target languages the more difficult it becomes - the size and complexity of the target run-time support lib becomes counter-productive. And, it only takes one deep-seated difference to drive a requirement for an analysis tool like Ira has developed.

假设已经开发了足够的 Groovy 库，目标代码的生成将减少到接近来自访问者 onEntry 和 onExit 例程的单行调用.通过抽象渲染可以在一定程度上减少耦合:

Presuming an adequate Groovy lib has been developed, production of the target code is reduced to near one-liner's called for from the visitor onEntry and onExit routines. Coupling can be reduced somewhat by abstracting the rendering:

public class Render {

    private static final String templateDir = "some/path/to/templates";
    private STGroupFile blocksGroup;
    private STGroupFile stmtGroup;

    public Render() {
        blocksGroup = new STGroupFile(Strings.concatAsClassPath(templateDir, "Blocks.stg"));
        stmtGroup = new STGroupFile(Strings.concatAsClassPath(templateDir, "Statements.stg"));
    }

    public String gen(GenType type, String name) {
        return gen(type, name, null);
    }

    /**
     * type is an enum, identifying the group template
     * name is the template name within the group
     * varMap contains the named values to be passed to the template
     */
    public String gen(GenType type, String name, Map<String, Object> varMap) {
        Log.debug(this, name);
        STGroupFile stf = null;
        switch (type) {
            case BLOCK:
                stf = blocksGroup;
                break;
            case STMT:
                stf = stmtGroup;
                break;
        }
        ST st = stf.getInstanceOf(name);
        if (varMap != null) {
            for (String varName : varMap.keySet()) {
                try {
                    st.add(varName, varMap.get(varName));
                } catch (NullPointerException e) {
                    Log.error(this, "Error adding attribute: " + name + ":" + varName + " [" + e.getMessage() + "]");
                }
            }
        }
        return st.render();
    }
}

这篇关于Antlr4 语言翻译 - 将模板逻辑与访问者类分开?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！