SML 或多或少的大型系统：编译器和解释器的互操作性

Question

这是关于使用 SML 进行大型编程的。首先是对该目的似乎可用的内容的摘要，然后是一个小摘要，最后是一个简单的问题。

use 伪子句

Top-level type, exception, and value identifiers (standardml.org)

请注意，使用功能是特殊的。虽然 没有精确定义，其预期目的是 获取文件的路径名并处理 文件内容为输入的 SML 源代码 由用户输入。它可以用作简单的构建 机制，特别是对于交互式会话。 大多数实现将提供更复杂的 为更大的源集合构建机制 文件。实现不需要提供 一个使用函数。

后来

val use : string -> unit    (* implementation dependent *)

它的缺点是：至少不被 MLton 支持，虽然没有标准化，但似乎与所有主要的 SML 系统都有相同的行为，即重新加载一个单元的次数与遇到use 一样多，由于 SML 的生成语义，这是不行的（多次定义一个结构，将导致不同的定义，这对于类型定义尤其错误）。

机器学习基础文件

存在所谓的“机器学习基础文件”：MLBasis (mlton.org) 和 ML‑Kit ML Basis Files (sourceforge.net)。

load 伪子句

MoscowML 有 load，其作用类似于仅使用一次的 use，即如果单元已加载，则不会重新加载单元，这是组成系统的预期。

总结

• load 不错，但只有 MoscowML 认可
• MLBasis 文件可能很好，但 Poly/ML 和 Moscow ML 都无法识别它
• MLton 无法识别use

将所有内容放在一个大的捆绑文件中，是唯一可以与所有编译器和解释器一起工作的可互操作的东西；这行得通，但很快就会成为一种负担。

问题

是否有已知的可互操作方式来组成由多个 SML 源文件组成的系统？

Answer 1

您没有提到的一个系统是 SML/NJ 的 Compilation Manager (CM)，它非常强大。还有一些其他鲜为人知的系统。

尽管如此，情况确实很糟糕。 SML 根本没有标准化的单独编译机制。在实践中，这意味着编写可移植的 Makefile 或类似的东西是相当痛苦的。

对于HaMLet，我经历了那种痛苦，为了让它与 7 种不同的 SML 实现一起编译。方法是使用受限（依存顺序）CM 文件和必要数量的 make + sed hackery 来为其他系统生成元文件。它还可以生成一个文件，其中包含所有源的相应“使用”调用，以及至少支持它的所有其他系统。总而言之，它并不漂亮，但效果很好。