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

Question

这是关于使用SML进行大规模编程的。首先概述了为此目的可用的内容，然后是一个小小的总结，最后是一个简单的问题。

use伪条款

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

  

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

之后

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

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

ML Basis Files

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

load伪条款

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

摘要

• load很好，但只能被MoscowML认可
• MLBasis文件可能不错，但Poly / ML和莫斯科ML都不承认它。
• MLton无法识别use

将所有内容放在一个大的bundle文件中，是所有编译器和解释器中唯一可互操作的东西;这很有效，但很快就会成为负担。

问题

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

Answer 1

你没有提到的一个系统是SML / NJ的编译管理器（CM），它非常强大。还有一些其他鲜为人知的系统。

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

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