【问题标题】:Is this conversion from BNF to EBNF correct?这种从 BNF 到 EBNF 的转换是否正确?
【发布时间】:2021-04-01 22:36:00
【问题描述】:

作为上下文,我的教科书将这种风格用于 EBNF:

Sebesta, Robert W. 《编程语言概念》第 11 版,Pearson,2016 年,第 150 页。

问题: 将以下具有三个 RHS 的 BNF 规则转换为具有单个 RHS 的 EBNF 规则。

注意:转换为 EBNF 应删除所有显式递归并生成单个 RHS EBNF 规则。

A ⟶ B + A | B – A |乙

我的解决方案:

A ⟶ B [ (+ | –) A ]

我的教授告诉我:

"首先,您应该使用 { } 而不是 [ ], 其次,根据 BNF 规则, 是 B。"(他指的是上面贴的样式指南)

他说的对吗?我想是的,但我读过其他 EBNF 风格,想知道我是否有权获得信用。

【问题讨论】:

    标签: grammar context-free-grammar bnf ebnf


    【解决方案1】:

    明确要求您删除显式递归,而您提出的解决方案没有这样做; A 仍然是根据自身定义的。因此,与命名问题无关,您未能进行请求的转换,并且您的教授正确地标记了您。所提出的问题的正确解决方案,忽略非终结符的名称,是 A ⟶ B { (+ | –) B },使用无限重复 ({…}) 而不是可选性 ([ …])。使用此解决方案,A 的产生式右侧仅引用 B,因此没有递归(至少在这个特定产生式中)。

    现在,对于命名:显然,您的教科书的 EBNF 风格是在非终结符名称周围使用尖括号。这是一种常见的风格,许多人会说它比使用对人类读者毫无意义的单个大写字母更具可读性。现在,我想您的教授认为您应该将 B 的名称更改为 ,因为那是非终端代表的“教科书”名称加法运算符的操作数。您被要求转换的原始 BNF 确实显示了两个加法运算符。但是,它使它们具有右关联性,这绝对是非标准的。因此,您可能能够构建一个论点,即没有理由假设这些运算符是可加的,并且它们的操作数应该称为“术语”[注 1]。但即使在此基础上,您也应该使用一些用小写字母书写并用尖括号括起来的名称。对我来说,这与第一期相比是次要的,但您的教授可能有自己的标准。

    总而言之,恐怕我不得不说,我认为您无权获得该解决方案的功劳。


    注意事项

    1. 如果您真的提出了这个解释,那么您的教授可能有理由建议将专业改为法律。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2011-01-28
      • 1970-01-01
      • 2021-11-29
      • 2020-02-05
      • 1970-01-01
      • 2015-05-21
      相关资源
      最近更新 更多