Electronic Joint Business

Solution for E-Business

ast

利用 Python 工具和库实现语法解析

想用 Python 来解析编程语言或者文档,一般有三种做法:1

  • 利用现成的库来支持语言的解析,如 XML 类库:对于那些使用广泛的语言如 XML 和 HTML,这是无疑是最好的选择。好的类库通常还会包括创建或修改语言的可编程 API,这要比基础解析器的功能多得多。不过只有最常见的语言才有这种类库。
  • 从头构造一个解析器:有时候你可能要自己构造解析器。比如语言无法用传统的解析器生成器来解析,或者生成器的功能无法满足性能需求或者无法和其他组件深度集成。
  • 利用工具或者库来帮助生成解析器,例如 ANTLR 可以为任何语言生成解析器。

在前两种选项之外的场合,生成器应该是默认的选择,因为它既灵活又可以大大缩短开发时间。这就是为什么本文重点关注此种类库和工具的原因。

用工具创建解析器
在后续的章节中我们会看到:

  • 利用工具来生成 Python 可用(或其他语言可用)的解析器
  • 用来创建解析器的 Python 类库

生成解析器代码的工具称一般为解析器生成器(parser generators)或者编译器的编译器(compiler compiler)。生成解析器的类库则称为解析器组合器(parser combinator)。

不管是生成器还是组合器都不是易上手的工具,你需要花时间学习它们的使用方法。请注意并不是所有生成器都适用于所有的语言。在这里, 我们列出了一些最常见的生成器并对它们逐一进行简单介绍。并且我们的目标语言定为 Python。这意味一般来说这些工具和库自身也是用 Python 编写的。

>>> 阅读全文

 

, , , , , ,

LLVM 简介

本文将讨论让 LLVM 成型的一些设计策略。LLVM 是个一揽子项目(a umbrella project),用于支持和开发一系列紧密相关的底层工具组件(例如汇编器、编译器、调试器等等),从设计之初,LLVM 就考虑兼容现在广泛使用的 Unix 系统工具。 起初 “LLVM” 这个名字是个缩写,现在则是这个一揽子项目的品牌。虽然 LLVM 提供了独特的功能,并因其强大的工具而闻名(例如 Clang 编译器, 一个比 GCC 更强大的 C/C++/Objective-C 编译器),但真正让 LLVM 有别于其他编译器的地方是在其内部架构。

从诞生之初(2000年12月),LLVM 就被设计成一组具有定义良好接口的、可重用的库。当时,开源的编程语言的实现通常按专用工具来设计的,一般只能不可分割地运行(monolithic executables)。比方说,很难从类似 GCC 这样的静态编译器中将解析器分离出来用在静态分析或者重构。而脚本语言大多都提供了将运行时或解释器嵌入大型应用的方法,该运行时也是一个完整的、不可分割的可以被嵌入或者单独使用的代码块。不同语言实现项目之间根本无法重用部件,代码也很难共享。

除了编译器本身的组成外,围绕流行语言的社区往往呈现出很强的两极化倾向:有些实现提供了传统的静态编译器(如 GCC, Free Pascal 和 FreeBasic), 而有的实现则以解释器或JIT(Just-In-Time)编译器的形式提供了运行时编译器。但是很少有实现同时提供两者,即使有的话,两者也极少共享代码。

过去十多年中,LLVM 慢慢改变了这种困境。现在,LLVM 被作为一个通用的基础框架实现了很多静态编译或运行时编译的语言(例如,GCC 支持的语言族、Java、.NET、Python、Ruby、Scheme、Haskell、D语言以及许多的知名度稍低的语言)。它也取代了很多专用编译器,像苹果公司 OpenGL 栈中的运行时特化引擎(runtime specialization engine)以及 Adobe 公司 After Effects 产品中的图形处理库。最后,LLVM 也用来创建各种新产品,最出名的应该算是 OpenCL GPU 编程语言和运行时了。

传统编译器设计简介
传统的静态编译器设计(如大多数 C 编译器)中采用的最普遍的方案就是三阶段编译,该设计主要由三个组件组成,分别是前端、优化器和后端(如图1-1所示)。前端负责解析源代码,检查错误,并构建语言相关的抽象语法树(AST)。AST 可根据情况转换为便于优化的新表示方式, 优化器和后端针对这种新表示而运行。

>>> 阅读全文

 

, , , , , ,