ABNF 中的替代运算符是可交换的吗？
Is the alternative operator in ABNF commutative?
Augmented Backus-Naur Form 中的替代运算符 (/) 是可交换的吗？
例如，s = a / b和s = b / a一样吗？
我还没有在 BNF 或 ABNF 上找到任何明确指定 / 双方产生有效匹配的语义的主要来源。他们也没有提到上下文无关语法及其对非确定性的允许。如果有人知道澄清参考，请分享。
编辑：Tony 在 2003 年的 points out RFC 3501 指定了 ABNF 交替的语义，至少在该文档中是这样。
RFC 5234: Augmented BNF for Syntax Specifications: ABNF (2008)
介绍对比BNF和ABNF（这里强调）：
Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. It balances compactness and simplicity with reasonable representational power. In the early days of the Arpanet, each specification contained its own definition of ABNF. This included the email specifications, RFC733 and then RFC822 , which came to be the common citations for defining ABNF. The current document separates those definitions to permit selective reference.
The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges.
“选择性引用”和“顺序无关”可能与交替排序语义有关，但尚不清楚。
RFC 822: Standard for the Format of ARPA Internet Text Messages (1982)
除非我遗漏了什么，否则引用的 RFC 也没有指定 / 语义。 2.2节回避问题
2.2. RULE1 / RULE2: ALTERNATIVES
Elements separated by slash ("/") are alternatives. There-
fore "foo / bar" will accept foo or bar.
各种规则定义表明他们认识到避免歧义的实际重要性。例如，这是 RFC 822 定义 optional-field 及其依赖项的方式：
optional-field =
/ "Message-ID" ":" msg-id
/ "Resent-Message-ID" ":" msg-id
/ "In-Reply-To" ":" *(phrase / msg-id)
/ "References" ":" *(phrase / msg-id)
/ "Keywords" ":" #phrase
/ "Subject" ":" *text
/ "Comments" ":" *text
/ "Encrypted" ":" 1#2word
/ extension-field ; To be defined
/ user-defined-field ; May be pre-empted
extension-field =
<Any field which is defined in a document
published as a formal extension to this
specification; none will have names beginning
with the string "X-">
user-defined-field =
<Any field which has not been defined
in this specification or published as an
extension to this specification; names for
such fields must be unique and may be
pre-empted by published extensions>
The Syntax and Semantics of the Proposed International Algebraic Language of the Zurich ACM-GAMM Conference（巴科斯 1958）
BNF 来自 IAL 表示法。文中引入了̅o̅r“元语言连接词”，直观上与/相关。不过也避开了二义性选择问题，估计只是慎重使用而已。
推荐
由于未指定的语义，我的建议是 将 alternation 规则中的每个可能匹配都视为有效 。如果未仔细设计语法以避免歧义，则此解释可能会导致同一输入的多个有效解析树。在出现歧义解析时对其进行处理比使用无意中有效的解析树更安全。
或者，如果您对语法的指定方式有影响，您可以考虑使用语义更清晰的符号。例如，Parsing Expression Grammar: A Recognition-Based Syntactic Foundation（Ford 2004）给出了确定性的替代方案优先选择语义（最左边的匹配获胜）。
一些 RFC 明确阐明了这一点，例如 IMAPv4 的 RFC3501 在 RFC 3501 section 9:
中包含了类似 PEG 行为的规范
In the case of alternative or optional rules in which a later rule
overlaps an earlier rule, the rule which is listed earlier MUST take
priority. For example, "\Seen" when parsed as a flag is the \Seen
flag name and not a flag-extension, even though "\Seen" can be parsed
as a flag-extension. Some, but not all, instances of this rule are
noted below.
不过，我不知道这种消歧 (hah) 有多常见。我看过的许多其他 RFC（最近几天我一直在实现一个 ABNF 解析器库）只是没有指定。许多 RFC ABNF 语法是明确的（例如 RFC8259 (JSON)）；然而，许多是模棱两可的（例如 RFC5322（Internet 消息））并且需要修正才能与保留歧义的解析器一起工作:-(
Augmented Backus-Naur Form 中的替代运算符 (/) 是可交换的吗？
例如，s = a / b和s = b / a一样吗？
我还没有在 BNF 或 ABNF 上找到任何明确指定 / 双方产生有效匹配的语义的主要来源。他们也没有提到上下文无关语法及其对非确定性的允许。如果有人知道澄清参考，请分享。
编辑：Tony 在 2003 年的
RFC 5234: Augmented BNF for Syntax Specifications: ABNF (2008)
介绍对比BNF和ABNF（这里强调）：
Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. It balances compactness and simplicity with reasonable representational power. In the early days of the Arpanet, each specification contained its own definition of ABNF. This included the email specifications, RFC733 and then RFC822 , which came to be the common citations for defining ABNF. The current document separates those definitions to permit selective reference.
The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges.
“选择性引用”和“顺序无关”可能与交替排序语义有关，但尚不清楚。
RFC 822: Standard for the Format of ARPA Internet Text Messages (1982)
除非我遗漏了什么，否则引用的 RFC 也没有指定 / 语义。 2.2节回避问题
2.2. RULE1 / RULE2: ALTERNATIVES
Elements separated by slash ("/") are alternatives. There- fore "foo / bar" will accept foo or bar.
各种规则定义表明他们认识到避免歧义的实际重要性。例如，这是 RFC 822 定义 optional-field 及其依赖项的方式：
optional-field =
/ "Message-ID" ":" msg-id
/ "Resent-Message-ID" ":" msg-id
/ "In-Reply-To" ":" *(phrase / msg-id)
/ "References" ":" *(phrase / msg-id)
/ "Keywords" ":" #phrase
/ "Subject" ":" *text
/ "Comments" ":" *text
/ "Encrypted" ":" 1#2word
/ extension-field ; To be defined
/ user-defined-field ; May be pre-empted
extension-field =
<Any field which is defined in a document
published as a formal extension to this
specification; none will have names beginning
with the string "X-">
user-defined-field =
<Any field which has not been defined
in this specification or published as an
extension to this specification; names for
such fields must be unique and may be
pre-empted by published extensions>
The Syntax and Semantics of the Proposed International Algebraic Language of the Zurich ACM-GAMM Conference（巴科斯 1958）
BNF 来自 IAL 表示法。文中引入了̅o̅r“元语言连接词”，直观上与/相关。不过也避开了二义性选择问题，估计只是慎重使用而已。
推荐
由于未指定的语义，我的建议是 将 alternation 规则中的每个可能匹配都视为有效 。如果未仔细设计语法以避免歧义，则此解释可能会导致同一输入的多个有效解析树。在出现歧义解析时对其进行处理比使用无意中有效的解析树更安全。
或者，如果您对语法的指定方式有影响，您可以考虑使用语义更清晰的符号。例如，Parsing Expression Grammar: A Recognition-Based Syntactic Foundation（Ford 2004）给出了确定性的替代方案优先选择语义（最左边的匹配获胜）。
一些 RFC 明确阐明了这一点，例如 IMAPv4 的 RFC3501 在 RFC 3501 section 9:
中包含了类似 PEG 行为的规范In the case of alternative or optional rules in which a later rule overlaps an earlier rule, the rule which is listed earlier MUST take priority. For example, "\Seen" when parsed as a flag is the \Seen flag name and not a flag-extension, even though "\Seen" can be parsed as a flag-extension. Some, but not all, instances of this rule are noted below.
不过，我不知道这种消歧 (hah) 有多常见。我看过的许多其他 RFC（最近几天我一直在实现一个 ABNF 解析器库）只是没有指定。许多 RFC ABNF 语法是明确的（例如 RFC8259 (JSON)）；然而，许多是模棱两可的（例如 RFC5322（Internet 消息））并且需要修正才能与保留歧义的解析器一起工作:-(