解析 2.0.4

该解析模块实现了LR(1)解析生成器，以及通过Lr和Glr解析驱动程序使用生成的解析器的运行时支持。没有特殊的解析生成器输入文件格式，但解析生成器仍然需要知道哪些类/方法对应于解析器的各个方面。这些信息通过文档字符串指定，解析生成器通过这些文档字符串进行内省以生成解析器。每个模块只能嵌入一个解析规范，但可以在解析规范之间共享模块，例如，多个解析规范可以使用相同的标记定义。

解析表是LR(1)类型的，但它们是通过一个快速算法生成的，该算法避免了使用通用LR(1)算法时产生的重复状态。创建时间和表的大小与LALR(1)算法相当。然而，LALR(1)可能会创建真实LR(1)解析器中不存在的reduce/reduce冲突。有关算法的更多信息，请参阅

A Practical General Method for Constructing LR(k) Parsers
David Pager
Acta Informatica 7, 249-268 (1977)

对于大型文法，解析表生成需要相当多的时间，但仍然相当快。内部支持将最近版本的解析表缓存到磁盘上，并在当前解析器规范仍然与用于生成缓存解析表的规范兼容的情况下使用该表。由于兼容性检查相当快，即使对于大型文法，这也消除了使用大多数解析器生成器使用的标准代码生成方法的需求。

解析器规范由Spec类封装。解析器实例使用Spec实例，但它们自身基于单独的类。这允许同时存在多个解析器实例，而不需要多个解析表的副本。有两个独立的解析器驱动类

Lr

基于无歧义LR(1)解析表的常规字符有限状态机（CFSM）驱动程序。此驱动程序比Glr驱动程序更快，但不能处理Glr驱动程序可以处理的所有解析表。

Glr

广义LR驱动程序，如果使用%split优先级标记歧义操作，则可以同时跟踪多个解析树。此驱动程序的设计紧密基于Elkhound，这在一份技术报告中进行了描述

Elkhound: A Fast, Practical GLR Parser Generator
Scott McPeak
Report No. UCB/CSD-2-1214 (December 2002)
http://www.cs.berkeley.edu/~smcpeak/elkhound/

解析器生成器指令嵌入在文档字符串中，必须以一个'%'字符开头，后跟以下关键字之一

优先级

%fail %nonassoc %left %right %split

令牌

%token

非终结符

%start %nonterm

产生式

%reduce

所有这些指令都与类相关，除了%reduce。%reduce与非终结符类中的方法相关。解析模块提供了必须从中派生优先级、令牌和非终结符的基本类。这并不像听起来那么严格，因为没有阻止，例如，创建一个子类Parsing.Token的Token主类，然后所有实际的令牌类型都从这个类派生。此外，没有阻止使用多重继承。

以下是需要由解析器规范子类化的基本类

• 优先级

• 令牌

• 非终结符

解析模块实现了以下异常类

• SpecError - 当语法规范存在问题

• ParsingException - 解析过程中发生的任何问题

• UnexpectedToken - 当输入序列包含语法不允许的令牌时（包括输入结束）

为了与旧代码保持兼容，解析模块定义了以下别名。新代码应使用上面不覆盖Python内置异常的异常。

• Exception - 可引发的所有异常的超类

• SyntaxError - UnexpectedToken的别名

尝试设置私有属性可能会引发

• AttributeError

作者：Jason Evans jasone@canonware.com

Github仓库：http://github.com/MagicStack/parsing