tcl - 为什么编译器不自动支撑 expr？

Question

我正在阅读 Donal Fellows 的精彩解释，解释为什么你应该支撑你的expr.

这让我想知道为什么 tcl 编译器不自动{}支持expr? 这种自动支撑在什么情况下会失效？

Answer 1

关于这个的一些随机想法......

• 该语言的优势之一是评估由少数统一应用的规则控制。让参数expr自动支撑意味着该命令的规则中必须有一个例外。
• 这也意味着解释器必须被重写，因为它在确定它正在处理的命令之前评估参数。该expr命令可以重命名或别名，使解释器更难确定何时自动支撑。
• 这意味着如果有人想要对参数进行双重评估，或者想要以不直接匹配表达式标记的方式构造参数，他们将不得不绕过自动支撑。
• 这意味着可能与许多旧代码不兼容。

让解释器成为“后座司机”并不是真正的 Tcl 方式。

Answer 2

这让我想知道为什么 tcl 编译器不自动{}支持expr?

它实际上是在 8.0 的一些 alpha 版本中这样做的。它被删除是因为更广泛的社区绝对讨厌它。核心 Tcl 语言——Tcl(n) 手册页上的 12 条规则——保持极小和简单，并且统一应用于一切。

没有特殊情况。这是大多数 Tcl 程序员想要的。

如果我没记错的话，自动支撑是特别考虑的if和while。使用if，这是因为在 Tcl 7 中省略大括号来测试命令结果是一种特别常见的做法，因为它更快（表达式引擎慢得令人尴尬）。使用while，这是因为省略大括号是一个常见的用户错误。

这种自动支撑在什么情况下会失效？

好吧，在这样的情况下会很明显：

set a 1
set b 2
set op +
set c [expr $a$op$b]

现在，设置c为3. 使用自动支撑，这将是一个语法错误（因为表达式语法对连续三个变量没有任何作用）。提出了一种解决方法：

set c [eval expr $a$op$b]

但坦率地说，让每个人都支持他们的表达式，除非他们真的想要双重替换（和运行时表达式编译）被认为是更好的。

双重替换几乎总是表明存在安全漏洞，也总是表明存在性能问题；几乎总是有更好（更快，更安全）的方法来做到这一点。支撑你的表达。它更安全、更快捷，而且非常容易做到：有什么不喜欢的？