Question

编译过程将代码变为机器指令，这使得代码必然面临机器环境的限制，例如存储的使用与 CPU 执行权限的交接就是这类语言中主要的两类复杂问题：内存分配和线程调度。解释型语言将程序的入口由 CPU 指令序列变成代码的自然入口，散列存储使我们避免面临存储地址的限制，这些技术可以让语言从“机器问题”中解放出来。这一结果让我们认识到，机器环境的限制只是语言实现中的负担。

因此，我们的问题得以回到此前的讨论：程序的所有行为无外乎两点，其一找到（包括逻辑在内的）数据；其二计算。亦即是说，在一个解释性的，或不以机器问题为焦点的语言中，“找到（包括逻辑在内的）数据”必然会成为本质、核心和关键的问题。表 6 列出了整个系统中的语法元素的性质。

表 6　语法元素的性质

* 可用于指定行为所依赖的行为，或关联项。例如 JavaScript 中的排序，可以指定排序过程。

** 作为通用行为，必须传入行为具体过程与参考数据。例如 Win32 SDK 中的 EnumWindows() 的列举。

*** 返回同时包括数据与行为的一个结构。例如 JavaScript 中的闭包。

通过“定义”，我们确定系统中的元素必然只存在数据、行为。这种定义通常是语法性质的，但最终总是可以表达为一个“名/值”映射——虽然这并非实现上的必需。需要留意的是，尽管表 6 中刻意从“数据”中把“行为”分离出来，并将后者进一步地分解为 计算() → 值 这样两种，而事实上它们都可以视作数据，可以用相同的方法 定义 ，并施以相同的 行为 。

所以我常说，程序是“被定义出来”的。因而我们通过思维就可以完成全部程序，而它在执行过程中的排错、修正与优化等，是出于我们在工具使用上的、熟练度训练的必需，而非编程思维训练的必需。

必须在这里指出的是，无论我们的编程语言如何变化，上述都是语义完整性的需求，即最大可能的集合。当然，其前提在于我们对“定义”的假设，如果所定义的语法元素更多，那么这一组合的空间就会变得更大，在语言的语义表达上会趋于丰富，进而可能无法控制；如果所定义的语法元素变小，例如将数据与行为统一为数据，则语义表达上会更简洁，但也可能出现（用自然语言来理解时的）歧义 7 。

最后，我们也可以推论出：既然“找到（逻辑与数据）”本质上也是一个行为——或称之为计算，那么它必然也满足表 6 中有关“计算和值”这两类行为的全部约束，亦即它可能实现的全部方法 8 。