是否可以使用通用标记模式来标记面向对象范式下的所有编程语言？
我计划开发一个工具，将用编程语言（例如：Java）编写的程序转换为通用标记语言（例如：XML ) 并且该标记代码被转换为另一种语言（例如：C#）。
简单来说，它是一种编程语言转换器，可以将用一种语言编写的程序转换为另一种语言。
我认为这是可能的，但我不知道从哪里开始。我想知道这样做的可能性以及有关某些现有系统的信息。
i have planned to develop a tool that converts a program written in a programming language (eg: Java) to a common markup language (eg: XML) and that markup code is converted to another language (eg: C#).
in simple words, it is a programming language converter that converts program written in one language to another language.
i think it is possible but i don know where to start. i wanna know the possibilities to do so and information about some existing system.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
你想要做的事情非常困难，但如果你想知道你要做什么，我在下面列出了你需要遵循的步骤：
首先是困难的一点：
首先你获得或派生一个操作语义您的源语言和目标语言。
然后，您可以增强语义以捕获源和目标内存模型。
然后您需要在一个通用操作模型中统一这两个增强语义。
然后您需要定义从源语言到通用操作模型的映射。
然后您需要定义从操作模型到目标语言的映射
正如您在问题中指出的那样，步骤 4 很简单.
第 1 步很困难，因为大多数语言没有指定足够正式的语义；但我建议查看 http://lucacardelli.name/TheoryOfObjects.html 因为这是最好的起点构建传统的 OO 语义的要点。
一般来说，第 2 步几乎肯定是不可能的，但如果您愿意牺牲一些效率，则可能会非常困难。
第 3 步将取决于第 1 步结果的干净程度，但可能会很微妙、棘手，甚至不可能。
第 5 步并不简单，它实际上是在编写一个编译器。
最终，由于步骤 1 和 2 中继承的困难，您打算做的事情通常是不可能的。但是，如果您愿意，那么它应该很困难，但可行：严格限制支持的源语言结构；几乎忘记了正确处理线程；并选择两种语义足够相似的语言（即 Java 和 C# 可以，但 C++ 和其他语言则不行）。
What you are trying to do is extremely hard, but if you want to know what you are up for I've listed the steps you need to follow below:
First the hard bit:
First you obtain or derive an operational semantics for your source and target languages.
Then you enhance the semantics to capture your source and target memory models.
Then you need to unify the two enhanced-semantics within a common operational model.
Then you need to define a mapping from your source languages onto the common operational model.
Then you need to define a mapping from your operational model to your target language
Step 4, as you pointed out in your question, is trivial.
Step 1 is difficult, as most languages do not have sufficiently formal semantics specified; but I recommend checking out http://lucacardelli.name/TheoryOfObjects.html as this is the best starting point for building a traditional OO semantics.
Step 2 is almost certainly impossible in general, but may be merely obscenely difficult if you are willing to sacrifice some efficiency.
Step 3 will depend on how clean the result of step 1 turned out, but is going to be anything from delicate and tricky to impossible.
Step 5 is not going to be trivial, it is effectively writing a compiler.
Ultimately, what you propose to do is impossible in general, due to the difficulties inherited in steps 1 and 2. However it should be difficult, but doable, if you are willing to: severely restrict the source language constructs supported; pretty much forget handling threads correctly; and pick two languages with sufficiently similar semantics (ie. Java and C# are ok, but C++ and anything-else is not).
这取决于您想要支持什么语言，但总的来说，这是一个巨大的问题。除非您计划只支持每种语言的一小部分，否则这是一项艰巨的任务。
真正的问题是每种编程语言都有不同的功能（有些区域重叠，有些则不重叠）以及解决相同问题的不同方法——检测程序员试图解决和转换的问题非常棘手这是一个新的习语。 :) 并考虑一下用不同语言创建的 GUI 之间的差异...
请参阅 http://xmlvm.org/ 举个例子（一个旨在通过 XML 中间点在多种不同语言的源代码之间进行转换的项目）——该网站在一定程度上涵盖了他们正在应对的挑战以及他们采取的妥协，并且（如果您仍然有对此类项目感兴趣...）提出更具体的后续问题。
特别注意输出源代码的样子——它根本不可读、可维护、高效等。
It depends on what languages you want to support, but in general this is a huge & difficult task unless you plan to only support a very small subset of each language.
The real problem is that each programming languages has different features (with some areas that overlap and others that don't) and different ways of solving the same problems -- and it's pretty tricky to detect the problem the programmer is trying to solve and convert that to a new idiom. :) And think about the differences between GUIs created in different languages....
See http://xmlvm.org/ as an example (a project aimed at converting between source code of many different languages, with an XML middle-point) -- the site covers in some depth the challenges they are tackling and the compromises they take, and (if you still have any interest in this kind of project...) ask more specific followup questions.
Notice specifically what the output source code looks like -- it's not at all readable, maintainable, efficient, etc..
为任何单一语言生成 XML “技术上很容易”：构建解析器、构造和抽象语法树，并将该树转储为 XML。 （我构建了可以为多种语言执行此操作的现成工具）。通过技术上的简单，我的意思是社区知道如何做到这一点（参见任何编译器教科书，例如 Aho&Ullman Dragon 的书）。我并不是说这在努力方面是一项微不足道的练习，因为真正的语言是复杂而混乱的；人们曾多次尝试构建 C++ 解析器，但很少成功。 （我取得了其中一项成功，但要成功的代价却很高）。
真正困难的（我并没有尝试这样做）是根据公开语言语义的单一模式生成 XML。如果没有这个，基本上就不可能编写从通用 XML 到任意目标语言的翻译器。这被称为 UNCOL 问题，自 1958 年以来人们一直在寻找答案。我注意到维基百科文章似乎表明问题已解决，但自 1961 年以来，您在文献中找不到很多对 UNCOL 的引用。
我见过的最接近的尝试是 OMG 的“ASTM”模型（http://www.omg.org/spec/ASTM/1.0/Beta1/ ）；它导出 XMI，即 XML。但是 ASTM 模型内置了许多转义，以允许它不能完美建模的语言（AFAIK，这意味着每种语言）以任意方式扩展 XMI，以便特定于语言的信息可以被编码。因此，每个语言解析器都会生成 XMI 的自定义版本，因此每个读者都必须非常了解扩展，并且完全的通用性消失了。
It is "technically easy" to produce XML for any single langauge: build a parser, construct and abstract syntax tree, and dump out that tree as XML. (I build tools that do this off-the-shelf for many languages). By technically easy, I mean that the community knows how to do this (see any compiler textbook, e.g., Aho&Ullman Dragon book). I do not mean this is a trivial exercise in terms of effort, because real languages are complicated and messy; there have been many attempts to build C++ parsers and few successes. (I have one of the successes, and it was expensive to get right).
What is really hard (and I don't try to do) is produce XML according to a single schema in which the language semantics are exposed. And without that, it will be essentially impossible to write a translator from a generic XML to an arbitrary target language. This is known as the UNCOL problem and people have been looking since 1958 for the answer. I note that the Wikipedia article seems to indicate the problem is solved, but you can't find many references to UNCOL in the literature since 1961.
The closest attempt I've seen to this is the OMG's "ASTM" model (http://www.omg.org/spec/ASTM/1.0/Beta1/); it exports XMI which is XML. But the ASTM model has lots of escapes built into it to allow langauges that it doesn't model perfectly (AFAIK, that means every language) to extend the XMI in arbitrary ways so that the language-specific information can be encoded. Consequently each language parser produces a custom version of the XMI, and thus each reader has to pretty much know about the extensions and full generality vanishes.