我经常听到有人说c++是一种上下文敏感的语言。举个例子:
a b(c);
这是变量定义还是函数声明?这取决于符号c的含义。如果c是一个变量,则ab (c);定义一个名为b的类型为a的变量。它直接用c初始化。但如果c是类型,则ab (c);声明一个名为b的函数,该函数接受c并返回a。
如果您查找上下文无关语言的定义,它基本上会告诉您,所有语法规则的左侧必须恰好包含一个非终结符。另一方面,上下文敏感语法允许在左侧使用任意的终结符和非终结符字符串。
浏览“c++程序设计语言”的附录A,我找不到一条语法规则,它的左边除了一个非终结符之外,还有其他任何东西。这意味着c++是上下文无关的。(当然,每一种与上下文无关的语言也是与上下文相关的,因为与上下文无关的语言构成了与上下文相关的语言的一个子集,但这不是重点。)
那么,c++是上下文无关的还是上下文敏感的?
首先,你正确地观察到c++标准末尾的语法中没有上下文敏感的规则,因此语法与上下文无关。
然而,这种语法并不能精确地描述c++语言,因为它生成的是非c++程序,例如
int m() { m++; }
or
typedef static int int;
c++语言被定义为“一组格式良好的c++程序”,它不是与上下文无关的(可以证明,仅仅要求声明变量就可以做到这一点)。理论上,您可以在模板中编写图灵完备程序,并根据其结果使程序具有病态形式,因此它甚至不是上下文敏感的。
现在,(无知的)人们(通常不是语言理论家,而是解析器设计者)通常在以下一些含义中使用“not context-free”
模棱两可的
不能用Bison解析
而不是LL(k) LR(k) LALR(k)或任何他们选择的解析器定义的语言类
标准后面的语法不满足这些类别(即它是模糊的,不是LL(k)…),所以c++语法对他们来说“不是上下文无关的”。从某种意义上说,他们是对的,要创建一个工作的c++解析器是非常困难的。
注意,这里使用的属性只与上下文无关的语言有微弱的联系——歧义与上下文无关没有任何关系(事实上,上下文敏感的规则通常有助于消除歧义),另外两个只是上下文无关语言的子集。解析与上下文无关的语言不是一个线性过程(尽管解析确定性语言是)。
这里的一个大问题是术语“上下文无关”和“上下文敏感”在计算机科学中有点不直观。对于c++,上下文敏感性看起来很像歧义,但在一般情况下不一定是这样。
在C/ c++中,if语句只允许在函数体中使用。这似乎是上下文敏感的,对吧?嗯,没有。与上下文无关的语法实际上不需要这样的属性,即您可以提取某一行代码并确定它是否有效。这实际上并不是context-free的意思。它实际上只是一个标签,模糊地暗示了一些与它的发音相关的东西。
现在,如果函数体中的语句根据直接语法祖先之外的定义而被不同地解析(例如,标识符是描述类型还是变量),如a * b;大小写,那么它实际上是上下文敏感的。这里没有实际的歧义;如果a是类型,则解析为指针声明,否则解析为乘法声明。
Being context-sensitive does not necessarily mean "hard to parse". C is actually not that hard because the infamous a * b; "ambiguity" can be resolved with a symbol table containing typedefs encountered previously. It doesn't require any arbitrary template instantiations (which have been proven to be Turing Complete) to resolve that case like C++ does on occasion. It's not actually possible to write a C program that will not compile in a finite amount of time even though it has the same context-sensitivity that C++ does.
Python (and other whitespace-sensitive languages) is also context-dependent, as it requires state in the lexer to generate indent and dedent tokens, but that doesn't make it any harder to parse than a typical LL-1 grammar. It actually uses a parser-generator, which is part of why Python has such uninformative syntax error messages. It's also important to note here that there is no "ambiguity" like the a * b; problem in Python, giving a good concrete example of a context-sensitive language without "ambiguous" grammar (as mentioned in the first paragraph).