问题标签 [associativity]

我已经阅读了The Ruby Programming Language中关于操作符的部分，这让我想到了操作符关联性。顺便说一句，这不是一个 Ruby 问题——它适用于所有语言。

我知道操作员必须以一种或另一种方式关联，我可以理解为什么在某些情况下一种方式比另一种更可取，但我很难看到更大的图景。语言设计者是否有一些标准来决定什么应该从左到右，什么应该从右到左？在某些情况下，它“只是有意义”，因为它是一种优于其他方式的方式，而在其他情况下，它只是一个武断的决定？或者这一切背后是否有某种宏大的设计？

（首先这不是硬件，我有所有的答案）

我有一个简单的 BNF 语法

and运算符是左关联（左手递归） or运算符是右关联（这次是右手递归）

给定表达式c and b or not a and ( not b or c )，为什么最正确的“和”在解析树中更高？
方式，我看到c **and** b or not a and ( not b or c )最左边的应该在解析树中更高。

我们的教授给出了这样的答案：

这是 lispy 符号中的解析树。

我试图弄清楚如何做一个左关联表达式，其中递归（不包含在任何东西中）表达式是可能的。例如，我想做：

将 2 个操作解析1 x 2 x 3为(expr OP expr) OP expr结果。

如果我试图防止expr解析无限递归，我可以执行以下操作：

但后来我会得到expr OP (expr OR expr)结果。

如何强制左侧绑定？

编辑：我知道operatorPrecedence但是当操作员是"IS" + Optional("NOT")或类似的时，它似乎不正确匹配。

我知道perlop。我正在寻找的是像 GHCi:info命令这样的快速查找：

我学习的地方(+)是左关联的，并且优先级为 6 infixl 6 +。

一些编译器书籍/文章/论文讨论了语法的设计及其运算符关联性的关系。我是自上而下的忠实粉丝，尤其是递归下降、解析器和迄今为止我编写的大多数（如果不是全部）编译器都使用以下表达式语法：

这是此 BNF 的 EBNF 表示：

根据我读到的内容，一些人认为这种语法是“错误的”，因为运算符关联性的变化（这 4 个运算符从左到右）由向右而不是向左生长的解析树证明。对于通过属性语法实现的解析器，这可能是正确的，因为 l 属性值要求首先创建此值，然后将其传递给子节点。但是，当使用正常的递归下降解析器实现时，由我决定是先构造该节点然后传递给子节点（自上而下）还是先创建子节点然后将返回值添加为该节点的子节点（传递在此节点的构造函数中）（自下而上）。这里应该有一些我想念的东西，因为我不同意这种语法“错误”的说法 并且这种语法已用于多种语言，尤其是。威斯安的。通常（或全部？）说它促进 LR 解析而不是 LL 的阅读。

可能重复：
谁能解释这些未定义的行为（i = i++ + ++i，i = i++ 等……）

我得到 1 的输出！！和 4 在 gcc 中。我用的是 ubuntu linux

Can someone explain to me how this is evaluated ? What I am most confused about is the ! symbol in front of the 3... how to evaluate 2 > !3 ?

换句话说，这有什么不应该编译的充分理由吗？

以下是一些解决方法：

但我的问题主要是关于一般的正确语法。

必须声明“全局友元运算符重载”来进行序列化总是让我觉得很笨拙。必须在类之外声明序列化运算符似乎不是基础。所以我一直在寻找一个可靠的答案来解释为什么。

（注意：如果有人有更好的 Google-Fu 来找到已经写好的好的答案，我很想读一读。）

我怀疑它在技术上是可行的，并且只是一个符号问题。<<如果该库被设计为执行and的成员重载>>，则您必须从右到左构建一系列流操作，而不是从左到右。所以不要写：

您必须将输出行编写为：

需要括号来启动反向链接，因为>>和<<关联从左到右。没有它们，它将尝试为r >> "Your rational number is "before找到匹配项"Your rational number is " >> cout。如果选择了具有从右到左关联性的运算符，则可以避免这种情况：

（注意：在库中，像字符串文字这样的非类类型必须通过全局运算符重载来处理。）

但这是限制吗？对于任何希望将序列化分派到类中的 iostream 风格的设计来说，这种逆转几乎是不可避免的？我错过了任何其他问题吗？

更新也许“问题”的更好措辞是说我开始怀疑以下内容：

对于希望序列化自己的非流对象，iostream 库可以假设已设计为插入器和提取器是类成员而不是全局重载......并且不会（显着）影响运行时属性。然而，这只有在 iostream 作者愿意接受它会迫使客户端从右到左形成流操作时才有效。

但是我缺乏直觉，为什么全局重载运算符与成员可以解锁从左到右（而不是从右到左）表达自己的其他解锁能力。问题是后见之明、模板或 C++11 的某些深奥特性是否可以提供替代方案。或者，“C++ 物理”是否对一个方向有内在的偏见，而全局重载在某种程度上是本书中唯一用于覆盖它的编译时技巧。

与弗莱明的电机左手定则比较

i) if(0) 是什么意思？

每次我用它来测试我会得到什么输出时，它都会返回错误的部分。

它是否等效于 if(0 == 0)，以防它评估真实部分。

ii) 逻辑非的结合性！从右到左。

链接：http ://www.liv.ac.uk/HPC/HTMLF90Course/HTMLF90CourseNotesnode94.html

逻辑运算符链接中的第二个示例：

但根据“包含单子 .NOT. 的两个子表达式首先被有效评估，因为其中有两个最左边，.NOT.A 首先完成，然后是 .NOT.E.”，左边的 NOT 被评估第一个，但是第一个要评估的应该是右边的那个……？？？