为什么导出固定性声明是一个“坏主意”？答案

【问题标题】：Why is exporting fixity declarations a "bad idea"?为什么导出固定性声明是一个“坏主意”？
【发布时间】：2021-08-23 13:06:50
【问题描述】：

根据 David MacQueen 在他的对标准 ML 的反思报告中的说法¹，

词法范围的中缀指令是来自 Pop-2 的不明智的遗产。它们使解析变得复杂，并且不能很好地与模块系统一起使用，因为中缀指令不能通过结构导出或在签名中指定（添加这样的功能不是一个好主意）。。 p>

现在我确实同意他的说法，即 infix[r] 声明的私有范围是一个坏主意，它使导入的用户定义的运算符非常无用，但我为此设想的解决方案是实际导出这些声明在签名中..不要完全摆脱它们。
在我所知道的具有固定性声明的语言中（ML 和派生类、Haskell 和派生类、Prolog 等），我感兴趣的是它们是否记录了该想法的优点和/或缺点。更一般地说，语言实现者的既定设计经验可以带来有趣的见解，以发现（从用户角度来看）似乎是一个很好的便利功能的缺点。

所以我的问题是，简而言之，文献中是否有引用和/或已知问题支持 MacQueen 关于不导出固定性的观点？

【问题讨论】：

我的观点：通用运算符的固定性是众所周知的。通常很难用不熟悉的未知固定性运算符直观地解析代码。即使在了解了它们的固定性之后，您也需要时间来熟悉它们以一目了然地解析它们。除非您打算花很多时间在上面，否则它们似乎需要做很多工作。
@mods：我改写了这个问题，以减少基于意见的答案
@rajashekar，根据我的经验，通常有一些约定/模式可以提供很大帮助。示例：类似cons的操作一般为infixr，类似snoc的操作为infixl，方便重复应用。 Cons 和 snoc 将比 append 绑定得更紧密。如果运算形成一个半环，那么“乘法”将比“加法”结合得更紧密。通常避免混合不带括号的不相关运算符以减少混淆。
@MothMan 大多数软件写作都是基于意见的。其余的是试图解决 P 中的 NP-hard 问题的新手。

标签： haskell prolog sml infix-notation

【解决方案1】：

一种可能性是，如果您看到类似x op1 y op2 z 的内容，您不知道它是指op1(x, op2(y, z)) 还是op2(op1(x, y), z)。 Prolog 有write_canonical，它以纯前缀形式写入，因此您始终可以准确地知道某些内容是如何被解析的。

还有从模块中导出操作符声明的问题 (SWI-Prolog seems to have got this right)。

除此之外，我想不出任何缺点。在可读性和一致性方面有巨大的优势。例如，variant of DCGs 定义了一个运算符-->>，类似于现有的--> ...这使得事情比必须使用前缀表示法编写的所有内容更具可读性。

【讨论】：

> 还有从模块中导出操作符声明的问题（我对这些很感兴趣）> 一种可能性是，如果你看到类似 x op1 y op2 z 的东西，你不知道...... （对于模块中的任何功能，不会说相同的类比吗？我相信在使用模块时引用模块签名和文档是开发期间的给定任务。这意味着暴露于中缀签名（如果导出）也是给定的)
在 Prolog 中，x op1 y op2 z 是一个数据结构。 write_canonical 将以前缀形式显示它（不评估任何内容）：？- write_canonical(a+b*c)。 +(a,*(b,c))