根据MLton文件：
标准ML要求在使用之前定义类型。 [link]
并非所有实现都强制执行此要求（例如，SML / NJ没有），但上面链接的页面很好地说明了为什么可能需要健全性（取决于实现如何处理值限制） ，它符合 Definition 中的一些评论：
虽然我们的定义没有假设，但每个上下文 C = T ， U ， E 具有tynames E ⊆ T 的属性。因此，可以认为 T 松散地包含“已经生成”的所有类型名称。 [...]当然，关于“已生成”的内容的评论在语义规则方面并不准确。但是可以很容易地证明以下精确结果：
设S为句子 T ， U ， E ⊢短语⇒ A 这样tynames E ⊆ T ，让S'成为句子 T '， U '， E '⊢短语'⇒ A '出现在S的证明中;然后还有tynames E '⊆ T '。
[第21页]
但我对此感到困惑。
首先 - 上述定理似乎落后了。如果我正确地理解了“在S的证明中出现”这一短语，那么这似乎意味着（通过相反的方式）“一旦你的上下文违反了tynames E ⊆ T < / em>，所有后续的背景也会违反这一意图“。即使这是真的，似乎断言反向会更有用和有意义，即“如果到目前为止所有上下文都符合tynames E ⊆ T的意图，那么任何随后可推断的背景也将符合该意图“。否？
其次 - MLton的陈述和 Definition 的陈述实际上似乎都不受推理规则（或其后的“进一步限制”）的支持。一些推理规则有“ C ”的“tynames τ⊆ T ”或“tynames VE ⊆ T C “作为附带条件，但此程序不需要这些规则（在上面链接的文档中给出）：
val r = ref NONE
datatype t = A | B
val () = r := SOME A
（具体来说：规则（4）与let，规则（14）与=>和规则（26）与rec有关。这些都不在此使用程序。）
从另一个方向来看，规则（17）涵盖datatype声明，只要求生成的类型名称不在 T C < / em>的;所以它不会阻止在现有值环境中使用类型名称的生成（除非已经确实 C ⊆ T C < / em>的）。
我觉得我可能会遗漏一些非常基本的东西，但我不知道它会是什么！
答案 0 :(得分：3)
关于你的第一个问题，我不确定你为什么建议阅读。结果基本上说如果你有一个派生 S （把它想象成一棵树），它的上下文满足条件，那么它的所有子派（想想子树）都会有满足条件的上下文。换句话说，所有规则维护条件。将条件视为上下文 C 的格式良好要求。
关于第二个问题，请注意在排序规则（24）中使用，，根据需要扩展 T of C 。更具体地说，如果为r分配了类型t option ref，那么第一个声明将生成一个环境 E 1 ，并带有相应的 t < / em>∈ tynames E 1 。然后，根据排序规则（24），第二个声明必须在上下文 C' = C ⊕ E < sub> 1 ，定义为 C +（ tynames E 1 ， E 1 ）在4.3节中。因此， t ∈ T的C'，这是良好形成所必需的，因此，规则（17）将无法选择相同的 t < / em>作为t的表示。