研究界认为,将信息从一种程序分析工具转移到另一种时,图形交换是正确的做法。见http://www.gupro.de/GXL
最近,OMG 定义了一个交换抽象语法树的标准。见http://www.omg.org/spec/ASTM/1.0/Beta1/
这个问题似乎一次又一次地得到解决。多年来提出的六种“工具巴士”提案都解决了这个问题,但没有人超越这个行业。问题在于 a) 使用任何类型的可嵌套表示法 [括号如 LISP,如 XML,...] 来表示 AST 都很容易,因此人们可以轻松推出自己的解决方案,并且 b) 一个工具可以与另一个交换 AST ,他们都必须在 AST 节点的含义上达成基本一致;但是大多数 AST 都是偶然地从每个工具使用的特定语法/解析技术中衍生出来的,而且工具之间几乎总是存在分歧。所以,我见过很少有工具可以有意义地交换 AST。
如果你在做一个爱好,我会坚持使用类似于 lisp 的树编码,其中每个节点都具有以下格式: ( ... ) 它易于生成且易于阅读。
我致力于使用专业工具来操作程序。如果我们已经打印出 AST,我们就执行上述操作。在实践中,大多数单个 AST 都过于复杂,因此我们几乎不会打印出整个 AST,最多只有一个节点和几个子节点。我们的工具不与任何人交换 AST(见上述原因:),但可以很好地在内存中构建它,出于分析原因或转换原因用它做一些奇怪的事情,然后要么删除它(无需将其发送到任何地方)或从树中重新生成原始语言文本。[后者意味着你需要反解析或“prettyprinting”技术]