EBNF - 其他角色或空间角色?

时间:2017-12-21 23:30:59

标签: ebnf

我想知道在EBNF中是否有任何方法可以知道某个角色是否是其他角色或空格角色?现在我在源字符串中的每个位置都使用了每个可能的变量,但是让我有点头疼必须尝试所有可能的解释,特别是如果我必须尝试所有可能的生产规则之前知道它是否是另一个字符或空格字符。

澄清:空格键,''是空格字符和其他字符,如果在ISO / IEC 14977中查看,我想知道是否有可能检查哪一个比粗暴强制每个可能的解释源字符串。

2018年1月6日: 也许6.1的歧义可以解决?文本隐含地说,gap-separators比终端字符串之外的其他字符具有更高的优先级,因为否则它们将成为语法的一部分?或者它可能定义了语法的等价类,模空间字符或类似的东西......

1 个答案:

答案 0 :(得分:1)

  

我想知道是否有办法知道一个字符是否是另一个字符   或预先在EBNF中使用空格字符?

是的,other-character(包括空格)可能出现在terminal-string(4.17、4.18),special-sequence(4.20)或bracketed-textual-comment(6.6)中。除此之外,spacegap-separator(6.4,7.6)。

这可以通过用不同的other-character代替#来看到。在上述情况下:spaceterminal-stringspecial-sequence; EBNF的自动处理没有任何有效的更改-尽管结果令人不满意。但是,用bracketed-textual-comment中的#代替space在EBNF的自动处理中会显示为错误。

  

也许模棱两可可以用6.1解决吗?

不,6.1表示意图,但没有定义或规则。

考虑到6.2将gap-separator定义为包括terminal-character。这意味着other-character#中的每一个都是space。在6.3中,terminal characterterminal-character,但是gap-free-symbol与6.2中的其他符号不同,在标准中没有意义。此外,在6.3和6.4中,#既是space又是gap-free-symbol。 6.3中包含gap-separator似乎是标准中的缺陷,但不是唯一的缺陷。

在8.1“扩展BNF的语法”中,存在一些缺陷。

以下未在6.5中定义:

terminal-character

以下没有6.9:

(* see 6.5 *) syntax 
  = (gap separator}, 
    gap free symbol, {gap separator}, 
    {gap free symbol, {gap separator}}; 

从6.6到6.8的引用编号错误,应分别为6.5到6.7。

相关问题