编译器跨平台实现和自然语言翻译

摘要：在阅读编译原理相关书籍时，意识到编译器设计本质上是语言翻译的简化问题。假设发明了一个新的语言X，我们要设计一个用X语言书写的，并可以编译X语言文件的编译器C for 计算机A 做C X XA。

在阅读编译原理相关书籍时，意识到编译器设计本质上是语言翻译的简化问题; 我们把高级语言书写的代码，通过编译器 + 解释器的过程变成计算机可以理解的机器码；就是相当于把一段文字翻译给一个外国人听；当然编译器的翻译工作要比自然翻译的过程简单很多；但是设计思想可以借鉴；

现在选取一个角度，来思考一些问题;

一个由语言L编写的，将语言X程序文件翻译成语言Y程序文件的翻译程序称为编译器，记作C _L ^XY

编译器应该选择什么语言来实现呢？假设没有任何前人的工作，那必须用汇编写一套编译器去编译高级语言，编译器毫无疑问是一项复杂的工作的，用汇编这种低级语言去直接实现它，基本上是一个难到无法发成的工作；这是一个核心问题，汇编实现编译器这种复杂软件难度太大！

先放下上面的问题稍后再说，假设已经历经千辛万苦实现了一个 L --> A的编译器C _A ^LA ；我们来思考下面2个问题；

现在再回答一开始的问题，如何实现一个编译器L-->A,直接用汇编简直难到不可能；

其实Case 1已经给出了这个问题的一个方案； 递归分解 ;

编译器自展
将语言拆分成L1...Ln个层次(Ln-1 属于Ln)，首先实现最底层核心的L1部分的编译器, 然后在用L1语言编译器实现L2的功能....以此递归下去，然后实现整个语言；
编译器自举
编译器自举的概念是是用高级语言L是用L语言写的编译器编译自身，计做C _L ^L? ，？表示它是可以移植的；
这个目标似乎听起来不太可能（鸡生蛋，蛋生鸡），但是现在一些语言的编译器比如GOLANG它得编译器就是自举；但现在简要说明一下步骤：
首先理解我们所说的编译器C是一个可执行文件是比如windows下的exe文件，它本身与语言无关，OS也不关注源文件是什么； java中的jar并不是可执行文件；
假设发明了一个新的语言X，我们要设计一个用X语言书写的，并可以编译X语言文件的编译器C for 计算机A 做C _X ^XA ;
- 用一个已知语言J的编译器做一个可以编译将X语言编译为A的编译器，计做C _J ^XA ；
- 用X语言实现功能与C _J ^XA ，功能一摸一样的编译器即为C _X ^XA ；然后用编译器C _J ^XA 去编译生成编译器；
- 在基于自展思想，完全可以用C _X ^XA 取代C _J ^XA ，即使是未来需要增强修改编译器本身的功能;

使用编译器自举的优势就不深入分析，毕竟未来用到的机会不多；我们的核心是要理解这种思想;

接下来在进一步思考

关于Java的编译器是不是自举问题，应该不是；我目前还不是特别理解自举实现的好处，只是觉得自举这个思想很有趣；此外Java号称与与平台无关（这里的平台即包括执行的OS平台，也包括语言平台（Java虚拟机不仅仅只支持java语言），如果是自举，到底用具体什么语言去自举呢？
如前所述当已经存在语言X实现的编译器后，可以用该语言X实现任何其他语言的编译器for 任何计算机（ 其实换句话说，只要你掌握了一门语言，那么通过学习你就可以掌握任何一门语言更容易理解 ）；如果我们把这个语言X在Java语境中就理解成Class文件（字节码），也就不难理解Java跨平台特性，也并非难到无法实现;在自然语义分析中，这个语言X就可以理解成某种中间语言，据我所知，google翻译就是采用这种中间语言的方式来处理不同语言间的翻译；即在概念上，字节码（java） == 中间语言(自然语言的互相翻译)；所以它们的好坏，很大程度上就取决于这个中间层的规范以及设计了；

编译器跨平台实现 和 自然语言翻译