无限定符列表推导式：为何Haskell与Clean不支持而Miranda支持？

背景与问题 #

列表推导式（又称ZF表达式）包含一系列限定符，既可以是生成器，也可以是布尔值表达式（即“过滤表达式”）作为守卫。其中，无限定符的列表推导式（如[1 | ]）在Miranda中合法，但在Haskell（经ghci验证）和Clean中不合法——要实现类似效果，只能添加True守卫写成[1 | True]，但这样更冗长。

有文献用这类推导式做等式推理示例：

[E | ] ++ L = [E] ++ L = (E:[]) ++ L = E:L

核心疑问：Haskell和Clean的语言设计者为何决定禁用无限定符的列表推导式？是否存在仅在这两种语言中会引发不良特性交互而Miranda中不存在的情况？

解答分析 #

1. 语法一致性与解析复杂度考量 #

Haskell和Clean的设计更偏向严格的语法规则一致性：列表推导式被明确定义为必须跟随至少一个限定符（生成器或守卫）。这种规则能避免语法歧义，让解析器实现更简洁。

Miranda允许省略限定符，本质是把空限定符集视为“恒真守卫”的语法糖，但Haskell和Clean的设计者认为，这种省略带来的表达便利极其有限，却会增加语法规则的复杂度——毕竟日常开发中用[E | True]就能完全替代，只是多写了几个字符而已。

2. 特性交互的潜在冲突 #

Haskell和Clean引入了Miranda没有的特性，这些特性与无限定符列表推导式可能产生不良交互：

• Haskell的do记号关联：Haskell的列表推导式是do记号的语法糖（比如[x | x <- xs, p x]对应do {x <- xs; guard (p x); return x}）。如果允许[E | ]，就对应do {return E}，这在语义上可行，但设计者认为这种写法偏离了列表推导式“基于限定符生成列表”的设计初衷，容易混淆列表推导式与纯return表达式的用途。
• Clean的严格求值逻辑：Clean采用严格求值策略，列表推导式的实现逻辑与Miranda的惰性求值有差异。无限定符的列表推导式在严格求值下语义就是单元素列表，但Clean的语法规则更强调“推导必须有依据”，空限定符的写法会打破这种直观性，还会增加类型推断规则的边缘情况处理成本。

3. 语言设计的取舍 #

从语言设计的优先级来看，Haskell和Clean都倾向于最小化非必要语法糖，除非某个语法糖能带来显著的表达优势或可读性提升。无限定符列表推导式的使用场景非常有限（主要是等式推理的示例），日常开发中几乎用不到，因此设计者认为不值得为这小众场景增加语法规则的复杂度。

内容的提问来源于stack exchange，提问作者Antonielly