自1995年以来，在强大的计算机科学家团队的支持下，我一直在构建工具（DMS软件再造工具包）来进行通用程序处理（语言翻译为特例）。DMS提供通用解析，AST构建，符号表，控制和数据流分析，转换规则的应用，带有注释的源文本的再生等，所有这些都通过计算机语言的显式定义进行参数化。
机器，你需要做到这一点的量也为广大的（特别是如果你希望能够在一个通用的方式来做到这一点对于多国语言），然后你需要用不可靠的定义语言可靠分析器（PHP是这个完美的例子）。
您考虑构建或尝试进行语言到语言的翻译并没有错，但是我认为您会发现，对于真正的语言而言，这比您预期的要艰巨得多。我们仅在DMS上就投入了大约100个人年，在每种“可靠”的语言定义（包括我们为PHP痛苦地构建的语言）上又花了6到12个月的时间，对于讨厌的语言（例如C ++）则要花更多的时间。这将是“一次学习经历”；这一直在我们身上。（您可能会发现上述网站上的“技术论文”部分有趣，可快速开始学习）。
人们经常尝试从他们熟悉的某种技术入手，以构建某种通用的机器，这是工作的一部分。（Python AST是一个很好的例子）。好消息是，这项工作已经完成。坏消息是，机械中内置了无数的假设，直到您尝试将其摔倒做其他事情时，您才会发现其中的大部分。到那时，您发现机器已经连接起来可以执行其最初的工作，并且会真的，真的会抵制您使它做其他事情的尝试。（我怀疑尝试让Python AST为PHP建模会很有趣）。
我最初开始构建DMS的原因是建立的基础很少内置这样的假设。它使我们有些头痛。到目前为止，还没有黑洞。（过去15年中，我工作中最难的部分是试图防止这种假设蔓延）。
很多人也犯了一个错误的假设，即如果他们可以解析（并且可能获得AST），那么他们就可以做好一些复杂的事情。艰巨的教训之一是，您需要符号表和流程分析才能进行良好的程序分析或转换。AST是必要的，但还不够。这就是Aho＆Ullman的编译器书不止于第二章的原因。（OP拥有此权利，因为他计划在AST之外构建其他机器）。有关此主题的更多信息，请参见解析后的寿命。
关于“我不需要完美的翻译”的评论很麻烦。弱翻译的工作是转换80％的“简单”代码，而剩下20％的代码要手工完成。如果您打算转换的应用程序很小，并且只打算转换一次，那么20％就可以了。如果要转换许多应用程序（甚至是随时间变化很小的同一应用程序），那不是很好。如果您尝试转换100K SLOC，那么20％就是20,000原始代码行，这些代码难以翻译，理解和修改，而您还无法理解另外80,000行已翻译程序。这需要大量的努力。在百万行级别，这实际上是不可能的。更难，他们通常会长时间拖延，付出高昂的代价并经常彻底失败，这很痛苦。
要翻译大型系统，您需要拍摄的是90％的高转换率，或者您可能无法完成翻译活动的手动部分。
另一个关键考虑因素是要翻译的代码大小。即使使用良好的工具，也要花费大量的精力来构建能正常运行的强大翻译器。尽管构建翻译器而不是简单地进行手动转换似乎很性感和酷，但是对于较小的代码库（例如，根据我们的经验，最多10万个SLOC），经济学根本无法证明其合理性。没有人喜欢这个答案，但是，如果您真的只需要翻译10K SLOC代码，则最好是硬着头皮做一下。是的，那很痛苦。
我认为我们的工具非常出色（但是，我有很大的偏见）。建立一个好的翻译仍然非常困难。我们大约需要1.5到2个人工年，我们知道如何使用我们的工具。不同之处在于，有了如此多的设备，我们成功的次数多于失败的次数。
602392714
清零编程群