对链式比较运算符 (x < y < z) 的语言支持答案

【问题标题】：Language support for chained comparison operators (x < y < z)对链式比较运算符 (x < y < z) 的语言支持
【发布时间】：2026-01-08 08:45:01
【问题描述】：

question 发布了关于链式比较运算符以及它们在不同语言中的解释方式。

链接比较运算符意味着(x < y < z) 将被解释为((x < y) && (y < z)) 而不是((x < y) < z)。

关于该问题的 cmets 表明 Python、Perl 6 和 Mathematica 支持链接比较运算符，但还有哪些其他语言支持此功能，为什么它不更常见？

快速浏览一下 Python 文档就会发现，这个功能至少从 1996 年就已经存在。是否有更多的语言没有添加这种语法的原因？

静态类型的语言在类型转换方面会出现问题，但还有其他原因导致这种情况不常见吗？

【问题讨论】：

好问题。在我看来，它甚至至少可以向后兼容 Java。（因为 < 和 > 没有为布尔值定义。）
我认为这并不常见，因为程序员太习惯 < 作为二元运算符了。
为什么静态类型的语言会有这个问题？你的意思是什么类型转换？
不，您不需要动态输入。首先，静态类型不会阻止布尔运算符。其次，即使这样做，此功能也不需要布尔值上的< 和>，它需要编译器将x > y < z 重写为x > y and y < z。您无法通过在布尔值上定义 < 和 > 来解决此问题 - 但由于无论如何都没有定义这些（这将是荒谬的），因此可以将此功能添加到例如Java 不会破坏尝试排序布尔值的现有代码。
是的，抱歉，我错误地组合了这些问题。它仍然让我想知道为什么这不是更常见的语法。

【解决方案1】：

自 1960 年代后期以来，链式比较是 BCPL 的一项功能。

【讨论】：

【解决方案2】：

它应该更常见，但我怀疑这不是因为它使解析语言更复杂。

好处：

缺点：

至于为什么不，我的猜测是：

【讨论】：

如何“教授数学”并不一定有好处。数学思想是如何教授的，甚至是如何写下来的，通常都不能反映正确的基本思想。现在，外行人尝试编程更为常见，但真正深入的编程最终需要更好地理解函数符号和概念（例如 lambda 表达式）。 “x
不同意“坚持最小意外原则”：首先吸引我到 C 语言的一件事是，无论上下文如何，每个表达式都有相同的含义。无论上下文如何，a < b 始终会生成 1 或 0。没有惊喜。 a < b 有时是二元 < 运算符，有时是由 < 符号和后来的 < （或 > 等）组成的三元运算符的一部分，会增加认知负荷

【解决方案3】：

Scheme（可能还有大多数其他 Lisp 家族语言）在其语法中有效地支持多重比较：

(< x y z)

这可以被认为是具有三个参数的< 函数的普通函数应用程序。请参阅规范中的6.2.5 Numerical Operations。

Clojure 也支持chained comparison。

【讨论】：

【解决方案4】：

我认为 ICON 是具有此功能的原始语言，而在 ICON 中，它不适合将布尔值作为特殊的“失败”标签处理，而所有其他值都被视为 true。

【讨论】：

【解决方案5】：

好处太小，不足以证明语言复杂化。

你并不经常需要它，多几个字符很容易干净利落地得到同样的效果。

【讨论】：

增加复杂性似乎是一个糟糕的理由。我想不出当前功能在动态类型语言中有用的原因，而这会添加额外的功能而不会产生太大的冲突。在我看来，它也更容易阅读。
我倾向于同意。它的简洁性是百万分之一，但实施并融入语法确实需要很多麻烦。
@Alan 你不能这么想。相反，您必须扭转局面，与规范、记录、计划、实施和测试所需的工作相比，您能获得什么？
@Alan：至于对复杂性的投票：还有哪些其他功能会“期望”拥有该功能（例如自定义重载运算符），让它们明确地工作有多复杂？它是否会引入潜在的解析歧义（ala C++ 的std::list<std::list<int>> 问题）？您是否希望它短路评估（foo(value) < b < bar(value) - 如果foo(value) < b 为假，是否会调用 bar？），为什么或为什么不呢？需要进行大量的调查以支持任何新的语言功能，尤其是那些在流行语言中不常见的功能。
当前流行的语言都有从 C 继承的垃圾语法。有/有很多语言支持链式比较，因此无需重新发明*。