Python编写的强大的、通用的解析器

 

Python编写的强大的、通用的解析器

 

Spark 是一种用 Python 编写的强大的、通用的解析器／编译器框架。在某些方面，Spark 所提供的比 SimpleParse 或其它 Python 解析器提供的都要多。然而，因为它完全是用 Python 编写的，所以速度也会比较慢。David 在本文中讨论了 Spark 模块，给出了一些代码样本，解释了它的用途，并对其应用领域提供了一些建议。
　　
　　继“可爱的 Python”系列中专门讲述 SimpleParse 的前一篇文章之后，我将在本文中继续介绍一些解析的基本概念，并对 Spark 模块进行了讨论。解析框架是一个内容丰富的主题，它值得我们多花时间去全面了解；这两篇文章为读者和我自己都开了一个好头。
　　
　　在日常的编程中，我经常需要标识存在于文本文档中的部件和结构，这些文档包括：日志文件、配置文件、定界的数据以及格式更自由的（但还是半结构化的）报表格式。所有这些文档都拥有它们自己的“小语言”，用于规定什么能够出现在文档内。我编写这些非正式解析任务的程序的方法总是有点象大杂烩，其中包括定制状态机、正则表达式以及上下文驱动的字符串测试。这些程序中的模式大概总是这样：“读一些文本，弄清是否可以用它来做些什么，然后可能再多读一些文本，一直尝试下去。”
　　
　　解析器将文档中部件和结构的描述提炼成简明、清晰和说明性的规则，确定由什么组成文档。大多数正式的解析器都使用扩展巴科斯范式（Extended Backus-Naur Form，EBNF）上的变体来描述它们所描述的语言的“语法”。基本上，EBNF 语法对您可能在文档中找到的部件赋予名称；另外，较大的部件通常由较小的部件组成。小部件在较大的部件中出现的频率和顺序由操作符指定。举例来说，清单 1 是 EBNF 语法 typographify.def，我们在 SimpleParse 那篇文章中见到过这个语法（其它工具运行的方式稍有不同）：
　　
　　清单 1. typographify.def
　　para　　　　:= (plain / markup)+
　　plain　　　 := (word / whitespace / punctuation)+
　　whitespace　:= [ tr]+
　　alphanums　 := [a-zA-Z0-9]+
　　word　　　　:= alphanums, (wordpunct, alphanums)*, contraction?
　　wordpunct　 := [-_]
　　contraction := "'", ('am'/'clock'/'d'/'ll'/'m'/'re'/'s'/'t'/'ve')
　　markup　　　:= emph / strong / module / code / title
　　emph　　　　:= '-', plain, '-'
　　strong　　　:= '*', plain, '*'
　　module　　　:= '[', plain, ']'
　　code　　　　:= "'", plain, "'"
　　title　　　 := '_', plain, '_'
　　punctuation := (safepunct / mdash)
　　mdash　　　 := '--'
　　safepunct　 := [!@#$%^&()+=|{}:;<>,.?/"]
　　
　　Spark 简介
　　Spark 解析器与 EBNF 语法有一些共同之处，但它将解析／处理过程分成了比传统的 EBNF 语法所允许的更小的组件。Spark 的优点在于，它对整个过程中每一步操作的控制都进行了微调，还提供了将定制代码插入到过程中的能力。您如果读过本系列的 SimpleParse 那篇文章，您就会回想起我们的过程是比较粗略的：1）从语法（并从源文件）生成完整的标记列表，2）使用标记列表作为定制编程操作的数据。
　　
　　Spark 与标准的基于 EBNF 的工具相比缺点在于，它比较冗长，而且缺少直接的出现计量符（即表示存在的“+”，表示可能性的“*”和表示有限制性的“?”）。计量符可以在 Spark 记号赋予器（tokenizer）的正则表达式中使用，并可以用解析表达式语法中的递归来进行模拟。如果 Spark 允许在语法表达式中使用计量，那就更好了。另一个值得一提的缺点是，Spark 的速度与 SimpleParse 使用的基于 C 的底层 mxTextTools 引擎相比逊色很多。
　　
　　在“Compiling Little Languages in Python”（请参阅参考资料）中，Spark 的创始人 John Aycock 将编译器分成了四个阶段。本文讨论的问题只涉及到前面两个半阶段，这归咎于两方面原因，一是由于文章长度的限制，二是因为我们将只讨论前一篇文章提出的同样的相对来说比较简单的“文本标记”问题。Spark 还可以进一步用作完整周期的代码编译器／解释器，而不是只用于我所描述的“解析并处理”的任务。让我们来看看 Aycock 所说的四个阶段（引用时有所删节）：
　　
　　扫描，也称词法分析。将输入流分成一列记号。
　　解析，也称语法分析。确保记号列表在语法上是有效的。
　　语义分析。遍历抽象语法树（abstract syntax tree，AST）一次或多次，收集信息并检查输入程序 makes sense。
　　生成代码。再次遍历 AST，这个阶段可能用 C 或汇编直接解释程序或输出代码。
　　对每个阶段，Spark 都提供了一个或多个抽象类以执行相应步骤，还提供了一个少见的协议，从而特化这些类。Spark 具体类并不象大多数继承模式中的类那样仅仅重新定义或添加特定的方法，而是具有两种特性（一般的模式与各阶段和各种父模式都一样）。首先，具体类所完成的大部分工作都在方法的文档字符串（docstring）中指定。第二个特殊的协议是，描述模式的方法集将被赋予表明其角色的独特名称。父类反过来包含查找实例的功能以进行操作的内省（introspective）方法。我们在参看示例的时侯会更清楚地认识到这一点。
　　
　　识别文本标记
　　我已经用几种其它的方法解决了这里的问题。我将一种我称之为“智能 ASCII”的格式用于各种目的。这种格式看起来很象为电子邮件和新闻组通信开发的那些协定。出于各种目的，我将这种格式自动地转换为其它格式，如 HTML、XML 和 LaTeX。我在这里还要再这样做一次。为了让您直观地理解我的意思，我将在本文中使用下面这个简短的样本：
　　
　　清单 2. 智能 ASCII 样本文本（p.txt）
　　Text with *bold*, and -itals phrase-, and [module]--this
　　should be a good 'practice run'.
　　
　　除了样本文件中的内容，还有另外一点内容是关于格式的，但不是很多（尽管的确有一些细微之处是关于标记与标点如何交互的）。
　　
　　生成记号
　　我们的 Spark“智能 ASCII”解析器需要做的第一件事就是将输入文本分成相关的部件。在记号赋予这一层，我们还不想讨论如何构造记号，让它们维持原样就可以了。稍后我们会将记号序列组合成解析树。
　　
　　上面的 typographify.def 中所示的语法提供了 Spark 词法分析程序／扫描程序的设计指南。请注意，我们只能使用那些在扫描程序阶段为“原语”的名称。也就是说，那些包括其它已命名的模式的（复合）模式在解析阶段必须被延迟。除了这样，我们其实还可以直接复制旧的语法。
　　
　　清单 3. 删节后的 wordscanner.py Spark 脚本
　　class WordScanner(GenericScanner):
　　　　"Tokenize words, punctuation and markup"
　　　　def tokenize(self, input):
　　　　　　self.rv = []
　　　　　　GenericScanner.tokenize(self, input)
　　　　　　return self.rv
　　　　def t_whitespace(self, s):
　　　　　　r" [ tr]+ "
　　　　　　self.rv.append(Token('whitespace', ' '))
　　　　def t_alphanums(self, s):
　　　　　　r" [a-zA-Z0-9]+ "
　　　　　　print "{word}",
　　　　　　self.rv.append(Token('alphanums', s))
　　　　def t_safepunct(self, s): ...
　　　　def t_bracket(self, s): ...
　　　　def t_asterisk(self, s): ...
　　　　def t_underscore(self, s): ...
　　　　def t_apostrophe(self, s): ...
　　　　def t_dash(self, s): ...
　　
　　class WordPlusScanner(WordScanner):
　　　　"Enhance word/markup tokenization"
　　　　def t_contraction(self, s):
　　　　　　r" (?<=[a-zA-Z])'(am|clock|d|ll|m|re|s|t|ve) "
　　　　　　self.rv.append(Token('contraction', s))
　　　　def t_mdash(self, s):
　　　　　　r' -- '
　　　　　　self.rv.append(Token('mdash', s))
　　　　def t_wordpunct(self, s): ...
　　　　
　　这里有一个有趣的地方。WordScanner 本身是一个完美的扫描程序类；但 Spark 扫描程序类本身可以通过继承进一步特化：子正则表达式模式在父正则表达式之前匹配，而如果需要，子方法／正则表达式可以覆盖父方法／正则表达式。所以，WordPlusScanner 将在 WordScanner 之前对特化进行匹配（可能会因此先获取一些字节）。模式文档字符串中允许使用任何正则表达式（举例来说，.t_contraction() 方法包含模式中的一个“向后插入”）。
　　
　　不幸的是，Python 2.2 在一定程度上破坏了扫描程序继承逻辑。在 Python 2.2 中，不管在继承链中的什么地方定义，所有定义过的模式都按字母顺序（按名称）进行匹配。要修正这个问题，您可以在 Spark 函数 _namelist() 中修改一行代码：
　　
　　清单 4. 纠正后相应的 spark.py 函数
　　def _namelist(instance):
　　　　namelist, namedict, classlist = [], {}, [instance.__class__]
　　　　for c in classlist:
　　　　　　for b in c.__bases__:
　　　　　　　　classlist.append(b)
　　　　　　# for name in dir(c):　 # dir() behavior changed in 2.2
　　　　　　for name in c.__dict__.keys():　# <-- USE THIS
　　　　　　　　if not namedict.has_key(name):
　　　　　　　　　　namelist.append(name)
　　　　　　　　　　namedict[name] = 1
　　　　return namelist
　　　　
　　我已经向 Spark 创始人 John Aycock 通知了这个问题，今后的版本会修正这个问题。同时，请在您自己的副本中作出修改。
　　
　　让我们来看看，WordPlusScanner 在应用到上面那个“智能 ASCII”样本中后会发生什么。它创建的列表其实是一个 Token 实例的列表，但它们包含一个 .__repr__ 方法，该方法能让它们很好地显示以下信息：
　　
　　清单 5. 用 WordPlusScanner 向“智能 ASCII”赋予记号
　　>>> from wordscanner import WordPlusScanner
　　>>> tokens = WordPlusScanner().tokenize(open('p.txt').read())
　　>>> filter(lambda s: s<>'whitespace', tokens)
　　[Text, with, *, bold, *, ,, and, -, itals, phrase, -, ,, and, [,
　　module, ], --, this, should, be, a, good, ', practice, run, ', .]
　　
　　值得注意的是尽管 .t_alphanums() 之类的方法会被 Spark 内省根据其前缀“t_”识别，它们还是正则方法。只要碰到相应的记号，方法内的任何额外代码都将执行。.t_alphanums() 方法包含一个关于此点的很小的示例，其中包含一条 print 语句。
　　
　　生成抽象语法树
　　查找记号的确有一点意思，但真正有意思的是如何向记号列表应用语法。解析阶段在记号列表的基础上创建任意的树结构。它只是指定了表达式语法而已。
　　
　　Spark 有好几种创建 AST 的方法。“手工”的方法是特化 GenericParser 类。在这种情况下，具体子解析器会提供很多方法，方法名的形式为 p_foobar(self, args)。每个这样的方法的文档字符串都包含一个或多个模式到名称的分配。只要语法表达式匹配，每种方法就可以包含任何要执行的代码。
　　
　　然而，Spark 还提供一种“自动”生成 AST 的方式。这种风格从 GenericASTBuilder 类继承而来。所有语法表达式都在一个最高级的方法中列出，而 .terminal() 和 .nonterminal() 方法可以被特化为在生成期间操作子树（如果需要，也可以执行任何其它操作）。结果还是 AST，但父类会为您执行大部分工作。我的语法类和如下所示的差不多：
　　
　　清单 6. 删节后的 markupbuilder.py Spark 脚本
　　class MarkupBuilder(GenericASTBuilder):
　　　　"Write out HTML markup based on matched markup"
　　　　def p_para(self, args):
　　　　　　''
　　　　　　para　 ::= plain
　　　　　　para　 ::= markup
　　　　　　para　 ::= para plain
　　　　　　para　 ::= para emph
　　　　　　para　 ::= para strong
　　　　　　para　 ::= para module
　　　　　　para　 ::= para code
　　　　　　para　 ::= para title
　　　　　　plain　::= whitespace
　　　　　　plain　::= alphanums
　　　　　　plain　::= contraction
　　　　　　plain　::= safepunct
　　　　　　plain　::= mdash
　　　　　　plain　::= wordpunct
　　　　　　plain　::= plain plain
　　　　　　emph　 ::= dash plain dash
　　　　　　strong ::= asterisk plain asterisk
　　　　　　module ::= bracket plain bracket
　　　　　　code　 ::= apostrophe plain apostrophe
　　　　　　title　::= underscore plain underscore
　　　　　　''
　　　　def nonterminal(self, type_, args):
　　　　　　#　Flatten AST a bit by not making nodes if only one child.
　　　　　　if len(args)==1:　return args[0]
　　　　　　if type_=='para': return nonterminal(self, type_, args)
　　　　　　if type_=='plain':
　　　　　　　　args[0].attr = foldtree(args[0])+foldtree(args[1])
　　　　　　　　args[0].type = type_
　　　　　　　　return nonterminal(self, type_, args[:1])
　　　　　　phrase_node = AST(type_)
　　　　　　phrase_node.attr = foldtree(args[1])
　　　　　　return phrase_node
　　　　　　
　　我的 .p_para() 在其文档字符串中应该只包含一组语法规则（没有代码）。我决定专门用 .nonterminal() 方法来稍微对 AST 进行平铺。由一系列“plain”子树组成的“plain”节点将子树压缩为一个更长的字符串。同样，标记子树（即“emph”、“strong”、“module”、“code”和“title”）折叠为一个类型正确的单独节点，并包含一个复合字符串。
　　
　　我们已经提到过，Spark 语法中显然缺少一样东西：没有计量符。通过下面这样的规则，
　　
　　plain ::= plain plain
　　
　　我们可以成对地聚集“plain“类型的子树。不过我更倾向于让 Spark 允许使用更类似于 EBNF 风格的语法表达式，如下所示：
　　
　　plain ::= plain+
　　
　　然后，我们就可以更简单地创建“plain 尽可能多”的 n-ary 子树了。既然这样，我们的树就更容易启动列，甚至不用在 .nonterminal() 中传送消息。
　　
　　使用树
　　Spark 模块提供了几个使用 AST 的类。比起我的目的来说，这些责任比我需要的更大。如果您希望得到它们，GenericASTTraversal 和 GenericASTMatcher 提供了遍历树的方法，使用的继承协议类似于我们为扫描程序和解析器所提供的。
　　
　　但是只用递归函数来遍历树并不十分困难。我在文章的压缩文件 prettyprint.py（请参阅参考资料）中创建了一些这样的示例。其中的一个是 showtree()。该函数将显示一个带有几个约定的 AST。
　　
　　每行都显示下降深度
　　只有子节点（没有内容）的节点开头有破折号
　　节点类型用双层尖括号括起
　　让我们来看看上面示例中生成的 AST：
　　
　　清单 7. 用 WordPlusScanner 向“智能 ASCII”赋予记号
　　>>> from wordscanner import tokensFromFname
　　>>> from markupbuilder import treeFromTokens
　　>>> from prettyprint import showtree
　　>>> showtree(treeFromTokens(tokensFromFname('p.txt')))
　　 0　<<para>>
　　 1 - <<para>>
　　 2 -- <<para>>
　　 3 --- <<para>>
　　 4 ---- <<para>>
　　 5 ----- <<para>>
　　 6 ------ <<para>>
　　 7 ------- <<para>>
　　 8 -------- <<plain>>
　　 9　　　　　 <<plain>>　Text with
　　 8　　　　　<<strong>> bold
　　 7 ------- <<plain>>
　　 8　　　　　<<plain>> , and
　　 6　　　　<<emph>> itals phrase
　　 5 ----- <<plain>>
　　 6　　　　<<plain>> , and
　　 4　　　<<module>> module
　　 3 --- <<plain>>
　　 4　　　<<plain>> --this should be a good
　　 2　　<<code>> practice run
　　 1 - <<plain>>
　　 2　　<<plain>> .
　　　
　　理解树结构很直观，但我们真正要寻找的修改过的标记怎么办呢？幸运的是，只需要几行代码就可以遍历树并生成它：
　　
　　清单 8. 从 AST（prettyprint.py）输出标记
　　def emitHTML(node):
　　　　from typo_html import codes
　　　　if hasattr(node, 'attr'):
　　　　　　beg, end = codes[node.type]
　　　　　　sys.stdout.write(beg+node.attr+end)
　　　　else: map(emitHTML, node._kids)
　　
　　typo_html.py 文件与 SimpleParse 那篇文章中的一样 — 它只是包含一个将名称映射到开始标记／结束标记对的字典。显然，我们可以为标记使用除 HTML 之外的相同方法。如果您不清楚，下面是我们的示例将生成的内容：
　　
　　清单 9. 整个过程的 HTML 输出
　　Text with <strong>bold</strong>, and <em>itals phrase</em>,
　　and <em><code>module</code></em>--this should be a good
　　<code>practice run</code>.
　　
　　结束语
　　很多 Python 程序员都向我推荐 Spark。虽然 Spark 使用的少见的协定让人不太容易习惯，而且文档从某些角度来看可能比较含混不清，但 Spark 的力量还是非常令人惊奇。Spark 实现的编程风格使最终程序员能够在扫描／解析过程中在任何地方插入代码块 — 这对最终用户来说通常是“黑箱”。
　　
　　比起它的所有优点来说，我发现 Spark 真正的缺点是它的速度。Spark 是我使用过的第一个 Python 程序，而我在使用中发现，解释语言的速度损失是其主要问题。Spark 的速度的确很慢；慢的程度不止是“我希望能快一点点”，而是“吃了一顿长时间的午餐还希望它能快点结束”的程度。在我的实验中，记号赋予器还比较快，但解析过程就很慢了，即便用很小的测试案例也很慢。公平地讲，John Aycock 已经向我指出，Spark 使用的 Earley 解析算法比更简单的 LR 算法全面得多，这是它速度慢的主要原因。还有可能的是，由于我经验不足，可能设计出低效的语法；不过就算是这样，大部分用户也很可能会象我一样

 

 

 

可爱的Python: 使用SimpleParse模块进行解析
本文来自编程入门网：http://www.bianceng.cn/Programming/extra/201007/18160.htm

与大多数程序员一样，我经常需要标识存在于文本文档中的部件和结构，这些文档包括：日志文件、配置文件、分隔的数据以及格式更自由的（但还是半结构化的）报表格式。所有这些文档都拥有它们自己的“小语言”，用于规定什么能够出现在文档内。

我编写处理这些非正式解析任务的程序的方法总是有点象大杂烩，其中包括定制状态机、正则表达式以及上下文驱动的字符串测试。这些程序中的模式大概总是这样：“读一些文本，弄清是否可以用它来做些什么，然后可能再多读一些文本，一直尝试下去。”

各种形式的解析器将文档中部件和结构的描述提炼成简明、清晰和 说明性的规则，该规则规定了如何标识文档的组成部分。这里，说明性方面是最引人注目的。我所有的旧的特别的解析器都采用了这种风格：读一些字符、作决定、累加一些变量、清空、重复。正如本专栏关于函数型编程的部分文章中所评述的，程序流的方法风格相对来说容易出错并且难以维护。

正式解析器几乎总是使用扩展巴科斯范式（Extended Backus-Naur Form(EBNF)）上的变体来描述它们所描述语言的“语法”。我们在这里研究的工具是这样做的，流行的编译器开发工具 YACC（及其变体）也是这样做的。基本上，EBNF 语法对您可能在文档中找到的 部件赋予名称；另外，经常将较小的部件组成较大的部件。由运算符 ― 通常和您在正则表达式中看到的符号相同 ― 来指定小部件在较大的部件中出现的频率和顺序。在解析器交谈（parser-talk）中，语法中每个命名的部件称为一个“产品（production）”。

可能读者甚至还不知道 EBNF，却已经看到过运行的 EBNF 描述了。例如，大家熟悉的 Python 语言参考大全（Python Language Reference）定义了浮点数在 Python 中是什么样子：

EBNF 样式的浮点数描述

floatnumber:　　pointfloat | exponentfloat
pointfloat:　　 [intpart] fraction | intpart "."
exponentfloat:　(nonzerodigit digit* | pointfloat) exponent
intpart:　　　　nonzerodigit digit* | "0"
fraction:　　　 "." digit+
exponent:　　　 ("e"|"E") ["+"|"-"] digit+

或者您可能见过以 EBNF 样式定义的 XML DTD 元素。例如，developerWorks 教程的 <body> 类似于：

developerWorks DTD 中 EBNF 样式的描述

<!ELEMENT body　((example-column | image-column)?, text-column) >

拼写稍有不同，但是量化、交替和定序这些一般概念都存在于所有 EBNF 样式的语言语法中。

使用 SimpleParse 构建标记列表

SimpleParse 是一个有趣的工具。要使用这个模块，您需要底层模块 mxTextTools ，它用 C 实现了一个“标记引擎”。 mxTextTools （请参阅本文后面的 参考资料）的功能强大，但是相当难用。一旦在 mxTextTools 上放置了 SimpleParse 后，工作就简单多了。

使用 SimpleParse 确实很简单，因为不需要考虑 mxTextTools 的大部分复杂性。首先，应该创建一种 EBNF 样式的语法，用来描述要处理的语言。第二步是调用 mxTextTools 来创建一个 标记列表，当语法应用于文档时，该列表描述所有成功的产品。最后，使用 mxTextTools 返回的标记列表来进行实际操作。

对于本文，我们要解析的“语言”是“智能 ASCII”所使用的一组标记代码，这些代码用来表示诸如黑体、模块名以及书籍标题之类的内容。这就是先前使用 mxTextTools 来标识的同一种语言，在先前的部分中，使用正则表达式和状态机。该语言比完整的编程语言简单得多，但已经足够复杂而有代表性。

这里，我们可能需要回顾一下。 mxTextTools 提供给我们的“标记列表”是什么东西？这基本上是一个嵌套结构，它只是给出了每个产品在源文本中匹配的字符偏移量。 mxTextTools 快速遍历源文本，但是它不对源文本本身 做任何操作（至少当使用 SimpleParse 语法时不进行任何操作）。让我们研究一个简化的标记列表：

从 SimpleParse 语法生成的标记列表

(1,
[('plain',
　 0,
　 15,
　 [('word', 0, 4, [('alphanums', 0, 4, [])]),
　　('whitespace', 4, 5, []),
　　('word', 5, 10, [('alphanums', 5, 10, [])]),
　　('whitespace', 10, 11, []),
　　('word', 11, 14, [('alphanums', 11, 14, [])]),
　　('whitespace', 14, 15, [])]),
　('markup',
　 15,
　 27,
...
289)

中间的省略号表示了一批更多的匹配。但是我们看到的部分叙述了下列内容。根产品（“para”）取得成功并结束于偏移量 289 处（源文本的长度）。子产品“plain”的偏移量为 0 到 15。“plain”子产品本身由更小的产品组成。在“plain”产品之后，“markup”产品的偏移量为 15 到 27。这里省略了详细信息，但是第一个“markup”由组件组成，并且源文本中稍后还有另外的产品取得成功。

     “智能 ASCII”的 EBNF 样式的语法

我们已经浏览了 SimpleParse + mxTextTools 所能提供的标记列表。但是我们确实需要研究用来生成这个标记列表的语法。实际工作在语法中发生。EBNF 语法读起来几乎不需加以说明（尽管 确实需要一点思考和测试来设计一个语法）：

typographify.def

para           := (plain / markup)+
plain          := (word / whitespace / punctuation)+
whitespace     := [ \t\r\n]+
alphanums      := [a-zA-Z0-9]+
word           := alphanums, (wordpunct, alphanums)*, contraction?
wordpunct      := [-_]
contraction    := "'", ('am'/'clock'/'d'/'ll'/'m'/'re'/'s'/'t'/'ve')
markup         := emph / strong / module / code / title
emph           := '-', plain, '-'
strong         := '*', plain, '*'
module         := '[', plain, ']'
code           := "'", plain, "'"
title          := '_', plain, '_'
punctuation    := (safepunct / mdash)
mdash          := '--'
safepunct      := [!@#$%^&()+=|\{}:;<>,.?/"]这种语法和您口头描述“智能 ASCII”的方式几乎完全相同，非常清晰。段落由一些纯文本和一些标记文本组成。纯文本由某些字、空白和标点符号的集合组成。标记文本可能是强调文本、着重强调文本或模块名等等。着重强调文本由星号环绕。标记文本就是由诸如此类的部分组成的。需要考虑的是几个特性，类似于到底什么是“字”，或者可以用什么符号结束缩写，但是 EBNF 的句法不会成为障碍。

相比之下，使用正则表达式可以更精练地描述同类规则。“智能 ASCII”标记程序的第一个版本就是这样做的。但是编写这种精练难度大得多，并且以后调整也更为困难。下列代码表示了很大程度上（但不精确地）相同的规则集：

智能 ASCII 的 Python regexs

         # [module] names
re_mods =
          r""'([\(\s'/">]|^)\[(.*?)\]([<\s\.\),:;'"?!/-])"""
          # *strongly emphasize* words
re_strong =
          r""'([\(\s'/"]|^)\*(.*?)\*([\s\.\),:;'"?!/-])"""
          # -emphasize- words
re_emph =
          r""'([\(\s'/"]|^)-(.*?)-([\s\.\),:;'"?!/])"""
          # _Book Title_ citations
re_title =
          r""'([\(\s'/"]|^)_(.*?)_([\s\.\),:;'"?!/-])"""
          # 'Function()" names
re_funcs =
          r""'([\(\s/"]|^)'(.*?)'([\s\.\),:;"?!/-])"""如果您发现或发明了该语言的某种经过微小更新的变体，将它和 EBNF 语法一起使用要比和那些正则表达式一起使用简单得多。此外，通常使用 mxTextTools 执行模式操作甚至更快些。

       生成和使用标记列表

对于样本程序，我们将实际语法放置在一个单独的文件中。对于大多数用途而言，这种组织比较好，便于使用。通常，更改语法和更改应用程序逻辑是不同种类的任务；这些文件反映了这一点。但是我们对语法所做的全部处理就是将它作为一个字符串传递给 SimpleParse 函数，因此我们大体上可以将它包括到主应用程序中（或者甚至以某种方式动态生成它）。

让我们研究完整的（简化）标记应用程序：

typographify.py

import
　　　　 os

　　　　　from
　　　　 sys

　　　　　import
　　　　 stdin, stdout, stderr

　　　　　from
　　　　 simpleparse

　　　　　import
　　　　 generator

　　　　　from
　　　　 mx.TextTools

　　　　　import
　　　　 TextTools
input = stdin.read()
decl = open(

　　　　　'typographify.def'
　　　　).read()

　　　　　from
　　　　 typo_html

　　　　　import
　　　　 codes
parser = generator.buildParser(decl).parserbyname(

　　　　　'para'
　　　　)
taglist = TextTools.tag(input, parser)

　　　　　for
　　　　 tag, beg, end, parts

　　　　　in
　　　　 taglist[1]:

　　　　　if
　　　　 tag ==

　　　　　'plain'
　　　　:
　　　　stdout.write(input[beg:end])

　　　　　elif
　　　　 tag ==

　　　　　'markup'
　　　　:
　　　　markup = parts[0]
　　　　mtag, mbeg, mend = markup[:3]
　　　　start, stop = codes.get(mtag, (

　　　　　'<!-- unknown -->'
　　　　,

　　　　　'<!-- / -->'
　　　　))
　　　　stdout.write(start + input[mbeg+1:mend-1] + stop)
stderr.write(

　　　　　'parsed %s chars of %s\n'
　　　　 %　(taglist[-1], len(input)))

    这就是它所做的。首先读入语法，然后根据语法创建一个 mxTextTools 解析器。接下来，我们将标记表／解析器应用于输入源来创建一个标记列表。最后，我们循环遍历标记列表，并且发出一些新的标记文本。当然，该循环可以对遇到的每个产品做我们所期望的任何其它事情。

由于智能 ASCII 所使用的特殊语法，源文本中的任何内容都可归类于“plain”产品或“markup”产品。因此，对于循环遍历标记列表中的单个级别，它已经足够了（除非我们正好寻找比特定标记产品级别低一级的级别，譬如“title”）。但是格式更自由的语法 ― 譬如出现在大多数编程语言中的语法 ― 可以轻松地在标记列表中向下递归，并在每个级别上寻找产品名称。例如，如果一种语法中允许嵌套标记代码，或许可以使用这种递归风格。您可能会喜欢弄清如何调整语法的练习（提示：请记住允许各产品彼此递归）。

转至输出的特殊标记代码还是存储到另一个文件中了，这是由于组织的原因而非本质原因。在这里我们使用了一个技巧，就是用一个字典作为一个 switch 语句（尽管示例中的 otherwise 情况还是太狭窄了）。这个想法就是：将来我们可能希望创建多种“输出格式”的文件，比如说 HTML、DocBook、LaTeX 或者其它格式。用于示例的特殊标记文件类似于：

typo_html.py

codes = \
{

　　　　　'emph'
　　　　　　: (

　　　　　'<em>'
　　　　,

　　　　　'</em>'
　　　　),

　　　　　'strong'
　　　　　: (

　　　　　'<strong>'
　　　　,

　　　　　'</strong>'
　　　　),

　　　　　'module'
　　　　　: (

　　　　　'<em><code>'
　　　　,

　　　　　'</code></em>'
　　　　),

　　　　　'code'
　　　　　　: (

　　　　　'<code>'
　　　　,

　　　　　'</code>'
　　　　),

　　　　　'title'
　　　　　 : (

　　　　　'<cite>'
　　　　,

　　　　　'</cite>'
　　　　),
}

把这种格式扩展到其它输出格式很简单。

结束语

SimpleParse 为含义模糊的 mxTextTools C 模块的基本功能和速度提供了一种简明的并且十分易读的 EBNF 样式的封装器。此外，即使只是顺便学会的，许多程序员也已经相当熟悉 EBNF 语法了。关于什么更容易理解，我不能提供 证明 ― 这一点因各人的直觉而异 ― 但是我可以根据源代码长度给出量化评估。先前手工开发的 mxTypographify 模块的大小如下：

wc mxTypographify.py

199　　 776　　7041 mxTypographify.py

这 199 行中，相当数量的行是注释。这些行中有 18 行是标记函数所包含的正则表达式版本，包含该标记函数是用于计时比较。但是该程序的功能基本上和上面列出的 typographify.py 的功能相同。相比之下，我们的 SimpleParse 程序，包括其支持文件在内，大小如下：

wc typo*.def typo*.py

19　　　79　　 645 typographify.def
20　　　79　　 721 typographify.py
6　　　25　　 205 typo_html.py
45　　 183　　1571 total

换句话说，行数大约只有前者的四分之一。这个版本的注释较少，但是那主要是因为 EBNF 语法的自我描述能力很强。我不希望太过强调代码行数 ― 显然，您可以通过最小化或最大化代码长度做手脚。但是通常对程序员的工作进行研究，少数实际经验结论之一是：“千行代码／人月”相当接近于常数，和语言以及库关系不大。当然，依次地，正则表达式版本是 SimpleParse 版本长度的三分之一 ― 但是我认为其表达式的密度使得它极难维护并且更难编写。总而言之，我认为 SimpleParse 是所考虑的方法中最好的。

转载于:https://my.oschina.net/alphajay/blog/70051

• 点赞
• 收藏
• 分享
• 文章举报

chenqiechun3408 发布了0 篇原创文章 · 获赞 0 · 访问量 581 私信 关注