TLA+ 《Specifying Systems》翻译初稿——Section 14.6 What TLC Doesn't Do（TLC不能做什么）

本节提出了TLC的几个局限性：

• 覆盖 $Naturals$和 $Integers$模块的Java类仅处理范围为 $-2^{31}..(2^{31}-1)$中的数字；
• $\textrm{CHOOSE}$ 和 $\textrm{CASE}$的语义与TLA+不完全吻合，事实上 $\textrm{CHOOSE}\; x \in S:P$返回的是第一个满足条件的元素而不是任一满足条件的元素；
• TLC将字符串视为原始值，而不是函数。因此，合法的TLA+表达式"abc" [2]会被视为错误。

我们希望TLC生成满足规约的所有行为。但是没有程序可以针对任意规约执行此操作。我已经提到了TLC的一些局限性，您可能还会遇到其他限制。

其中一点是覆盖 $Naturals$和 $Integers$模块的Java类仅处理范围为 $-2^{31}..(2^{31}-1)$中的数字。如果任何计算生成的值超出此范围，则TLC会报错。TLC不能生成满足任意规约的所有行为，但可以实现更轻松的目标，即确保它确实生成的每个行为都满足该规约。但出于效率考虑，TLC并不总是能够达到这一目标。它以两种方式背离TLA+的语义：

• TLC没有保留 $\textrm{CHOOSE}$的精确语义。如第16.1节所述，如果S等于T，则 $\textrm{CHOOSE}\; x \in S:P$ 应该等于 $\textrm{CHOOSE}\: x \in T:P$，但是，仅当S和T在语法上相同时，TLC才能保证这一点。例如，TLC可能会为两个表达式计算不同的值：
  $\textrm{CHOOSE} \; x \in \left \{ 1,2,3 \right \}:x<3$
  $\textrm{CHOOSE} \; x \in \left \{ 3,2,1 \right \}:x<3$
  CASE表达式存在类似的TLA +语义冲突，其语义在第16.1.4节中CHOOSE之后定义。
• TLC 不保留TLA +语义中字符串的表示。 在TLA+中，字符串"abc"是三元素序列|，即具有定义域 $\left \{ 1,2,3 \right \}$的函数。TLC将字符串视为原始值，而不是函数。因此，合法的TLA+表达式"abc" [2]会被视为错误。