NLTK的文档和来自同一文件的CFG之间的'正则表达式'之间的权力是否存在实际差异？肯定应该有，因为有无上下文的语言不常规，但我找不到CFG方法优于正则表达式的具体例子。
答案 0 :(得分：4)
来自RegexpParser的文档：
子句的模式按顺序执行。早一点 pattern可能会引入一个阻止后来的块边界 执行模式。有时单个模式会 匹配输入的多个重叠范围。和。一样 正则表达式替换更普遍，chunker会 确定可能的第一场比赛，然后继续寻找比赛 在这一个结束之后。
语法的子句也按顺序执行。一个级联 块解析器是一个具有多个子句的解析器。最大深度 由此块解析器创建的解析树的结构与 语法中的条款数量。
即，每个子句/模式执行一次。因此，只要您需要后一个子句的输出与之前的子句匹配，您就会遇到麻烦。
一个实际的例子就是可以将一个完整的句子本身的东西用作更大句子中的一个句子：
猫扑了一下。他听说那只猫发出了声音。
她看到他听到那只猫发出的声音。
正如我们可以从上面的文档中读到的，当你构造一个RegexpParser时，你正在为这种句子的“深度”设置一个任意限制。对于无上下文的语法没有“递归限制”。
文档提到您可以使用循环来缓解这种情况 - 如果您运行两到三次或两次合适的语法，则可以进行更深入的解析。你可以添加外部逻辑来循环你的语法很多次，或者直到没有其他东西可以被解析。
然而，正如文档还指出的那样，这个解析器的基本方法仍然是“贪婪的”。对于固定或可变数量的步骤，它会像这样进行：
这是天真的，因为如果早期的步骤出错，这将破坏整个解析。
想想一个“花园路径句子”：
马跑过谷仓了。
一个类似的字符串，但是一个完全不同的句子：
那匹马跑过谷仓。
可能很难构造一个将解析这两个句子的RegexpParser，因为该方法依赖于初始组块是正确的。正确的初始分块对于另一个可能是不正确的初始分块，但是在解析逻辑中处于较晚级别之前，你无法知道“你所处的句子”。
例如，如果“谷仓倒塌”在早期被拆分，那么解析就会失败。
当你最终得到一个“差”的解析时，你可以添加外部逻辑来回溯，看看你是否能找到更好的解析。但是，我认为你会发现，在那时，解析算法的更多重要部分都在你的外部逻辑中，而不是在RegexpParser中。