C# 词法分析器(七)总结
系列导航
在之前的六篇文章中,我比较详细的介绍了与词法分析器相关的算法。它们都比较关注于实现的细节,感觉上可能比较凌乱,本篇就从整体上介绍一下如何定义词法分析器,以及如何实现自己的词法分析器。
第二节完整的介绍了如何定义词法分析器,可以当作一个词法分析器使用指南。如果不关心词法分析器的具体实现的话,可以只看第二节。
一、类库的改变
首先需要说明一下我对类库做的一些修改。词法分析部分的接口,与当初写《C# 词法分析器》系列时相比,已经发生了不小的改变,有必要做一下说明。
1. 词法单元的标识符
词法单元(token)最初的定义是一个 Token 结构,使用一个 int 属性作为词法单元的标识符,这也是很多词法分析器的通用做法。
但后来做语法分析的时候,感觉这样非常不方便。因为目前还不支持从定义文件生成词法分析器代码,只能在程序里面定义词法分析器。而 int 本身是不具有语义的,作为词法单元的标识符来使用,不但不方便还容易出错。
后来尝试过使用字符串作为标识符,虽然解决了语义的问题,但仍然容易出错,实现上也会复杂些(需要保存字符串字典)。
而既简单,又具有语义的解决方案,就是使用枚举了。枚举名称提供了语义,枚举值又可以转换为整数,而且还能够提供编译期检查,完全避免了拼写错误,所以现在的词法单元便定义为 Token<T> 类,与之相关的很多类也同样带上了泛型参数 T。
2. 命名空间
之前的命名空间是 Cyjb.Compiler 和 Cyjb.Compiler.Lexer,现在被改成了 Cyjb.Compilers 和 Cyjb.Compilers.Lexers,毕竟命名空间名称还是比较适合使用复数。
3. 词法分析器上下文
之前对词法分析器上下文的切换,可以使用上下文的索引、标签或 LexerContext 实例本身。但现在只能够通过标签进行切换,这样实现起来更简单些,使用上也不会受到过多影响。
4. DFA 的表示
原先 LexerRule 类中对 DFA 的表示有些简单粗暴,对于不了解具体实现的人来说,很难理解 DFA 的表示。现在重新规划了 LexerRule<T> 类中的接口,理解起来会更容易些。
二、定义词法分析器
这一节是 Cyjb.Compilers 类库中词法分析器的使用指南,包含了完整的文档、实例以及相关注意事项。类库的源码可以从 Cyjb.Compilers 项目找到,类库文档请参见 wiki。
1. 定义词法单元的标识符
前面说到,目前是使用枚举类型作为词法单元的标识符,这个枚举类型中的字段可以任意定义,没有任何限制。不过,为了方便之后的语法分析部分,特别要求枚举值必须是从 0 开始的整数,枚举值最好是连续的,因为不连续的枚举值会导致语法分析部分浪费更多的空间。
使用特殊的值 -1 来表示文件结束(EndOfFile),该值可以从 Token<T>.EndOfFile 字段得到,也可以通过 Token<T>.IsEndOfFile 属性获取词法单元是否表示文件结束。
这里仍然使用计算器作为示例,以下代码便定义了作为标识符的枚举:
在使用的时候,显然会比整数更加方便。
2. 定义词法分析器的上下文
词法分析器的所有定义都是从 Cyjb.Compilers.Grammar<T> 类开始的,因此首先需要实例化一个 Grammar<T> 类的实例:
词法分析器的上下文,可以用来控制规则是否生效。上下文有两种类型:包含型或者排除型。
- 如果当前是包含型上下文,那么会激活当前上下文的所有规则,同时会激活所有没有指定任何上下文的规则。
- 如果当前是排除型上下文,那么只会激活当前上下文的所有规则,其它任何规则都不会被激活。
使用以下的方法来分别定义排除型和包含型的词法分析器上下文,label 参数即为上下文的标签:
默认的词法分析器上下文是 "Initial",通过该标签可以切换到默认的上下文中。需要特别注意的是,由于实现上的原因,上下文必须先于所有终结符定义。
例如,以下的代码定义了一个包含型上下文 Inc,以及一个排除型上下文 Exc。
3. 定义正则表达式
使用以下的方法来定义正则表达式:
正则表达式可以通过 Cyjb.Compilers.RegularExpressions.Regex 类的相关方法构造得到,也可以直接使用表示正则表达式的字符串,相关定义的规则可以参考《C# 词法分析器(三)正则表达式》。
注意,这里定义的正则表达式仅仅用于简化终结符定义,方便重复使用一些通用或复杂的正则表达式,并没有其它的作用。这里定义的正则表达式也不可以包含向前看符号(/)、行首限定符(^)、行尾限定符($)或者上下文(<context>)。
例如,以下代码定义了一个名为 digit 的正则表达式,以后需要表示数字的时候,就可以直接通过 “{digit}” 来引入,而不需要每次都写 “[0-9]+”。
4. 定义终结符
使用 Grammar<T>.DefineSymbol 方法的相关重载来定义终结符,如以下代码所示:
这些重载被分成了三组。第一组重载,接受 T id 作为与词法单元对应的标识符,和相应的正则表达式及其上下文。当相应的终结符被匹配后,自动返回标识符为 id 的 Token<T> 实例。
第二组重载,具有额外的参数 action,这是只包含一个 ReaderController<T> 参数的委托,当匹配了相应的终结符时,就会被调用。通过 ReaderController<T> 的相应属性和方法,可以对词法分析过程进行一些控制。
最后一组重载,缺少了标识符 id,也就无法自动返回 Token<T> 实例,因此必须指定匹配到相应终结符时要执行的方法。
终结符的动作
在成功匹配某个终结符时,就会执行相应的动作,该动作是一个 Action<ReaderController<T>> 类型的委托。
ReaderController<T> 类包含了与当前匹配的终结符相关的信息,包括上下文、标识符、源文件和文本。主要的方法有 Accept、More、Reject 以及操纵上下文的方法 BeginContext、PopContext 和 PushContext。
Accept 方法会接受当前的匹配,词法分析器会返回表示当前匹配的 Token<T> 实例。
More 方法会通知词法分析器,保留本次匹配的文本。假设本次匹配的文本是 "foo",下次匹配的文本是 "bar",如果本次匹配时调用了 More 方法,下次匹配的文本就会变成 "foobar"。
Reject 方法会拒绝当前的匹配,转而使用次优的规则继续尝试匹配。详细信息请参考《C# 词法分析器(六)构造词法分析器》的 2.4 节“支持 Reject 动过的词法分析器”。
Accept 方法和 Reject 方法不能够在一次匹配中同时调用,因为它们是互斥的动作。如果在一次匹配中两个方法都没有调用,那么词法分析器会什么都不做——丢弃本次匹配的结果,直接进行下一次匹配。
对于词法分析器上下文的控制,简单的用法就是利用上下文来切换匹配的规则集,以实现一些“次级语法”,可以参考《C# 词法分析器(六)构造词法分析器》的 3.3 节给出的示例“转义的字符串”。
下面给出计算器的终结符定义。其中,Id 的定义是通过引入正则表达式 digit 来完成的,而且它定义了自己的动作,会将自己对应的文本转换为 double 类型,并保存到 Token<T>.Value 属性中。最后一条语句,通过定义空的动作,使得匹配到的空白被丢弃。
5. 构造词法分析器
以上四步便完成了词法分析器的定义,接下来就是构造词法分析器。使用以下四个方法,就可以直接构造出相应的词法单元读取器(TokenReader<T> 的子类的实例):
如果调用的是 GetReader 方法重载,则认为动作中不包含拒绝(Reject),会返回比较简单但更高效的词法分析器实现。如果调用的是 GetRejectableReader 方法重载,则认为动过中包含拒绝(Reject),会返回功能更强大但效率略低的词法分析器实现。
其规则是:
- 如果不包含向前看和拒绝动作,则返回 SimpleReader<T> 的实例。
- 如果只包含定长的向前看(不包含变长的向前看或拒绝动作),则返回 FixedTrailingReader<T> 的实例。
- 如果只包含拒绝动作(不包含向前看),则返回 RejectableReader<T> 的实例。
- 如果包含变长的向前看,或者同时包含拒绝动作和向前看(无论是否变长),则返回 RejectableTrailingReader<T> 的实例。
关于其中实现的细节,请参考《C# 词法分析器(六)构造词法分析器》。
所有的词法单元读取器,都继承自 TokenReader<T> 类,主要包含两个方法:PeekToken 和 ReadToken,与字面意义相同,就是读取输入流中的下一个词法单元,不更改(Peek)或提升(Read)输入流的字符位置。
TokenReader<T> 类还实现了 IEnumerable<T> 接口,因此可以使用 foreach 语句从中读取词法单元。但是,TokenReader<T> 本身并不会储存之前读取过的词法单元,在被枚举的时候,实际上还是会调用 ReadToken 方法,因此只能在一个位置枚举 TokenReader<T>,而且只能枚举一次,枚举完毕后,TokenReader<T> 也同样到达了流的结尾。如果希望多次枚举,还请缓存到数组中再进行操作。
以下是构造出计算器的词法单元读取器,并输出所有读取到的词法单元的代码:
最后是完整的构造计算器的代码:
代码的输出结果如下图所示:
可以看到,最后总是会以特殊值 -1 结束,表示文件结束。
三、自定义词法分析器
Cyjb.Compilers 项目中,提供了完整的词法分析器实现。但是,在实际的使用中,难免会遇到各种各样的需求,可能已实现的词法分析器是无法满足的,此时就必须自己完成词法分析器了。
在完成定义词法分析器后,可以从 Grammar<T>.LexerRule 属性获取到一个 Cyjb.Compilers.Lexers.LexerRule<T> 对象,该实例中存储了一个词法分析器所需的全部信息,并且不会依赖于原始的 Grammar<T> 对象。它就是自定义词法分析器的核心。
下图是与 LexerRule<T> 对象相关的类图。这四个类表示了词法分析器的核心信息,即生成的 DFA 的数据。
图 1 与 LexerRule<T> 相关的类图
LexerRule<T>.CharClass 属性保存了与字符类相关的数据,这是一个长度为 65536 的数组,保存了每个字符所属的字符类。使用从 0 开始的连续整数表示不同的字符类,所有包含的字符类的数量可从 LexerRule<T>.CharClassCount 属性获取。关于字符类的详细信息,请参考《C# 词法分析器(四)构造 NFA》的第三节“划分字符类”。
LexerRule<T>.Contexts 属性保存了与词法分析器的上下文相关的数据,这是一个字典,其键为上下文的标签,值为相应的 DFA 头节点索引。LexerRule<T>.ContextCount 属性表示了上下文的数量。
LexerRule<T>.Symbols 属性是定义的终结符的列表,列表的每一项都是一个 SymbolData<T> 结构,包含终结符的标识符、动作和向前看信息。
LexerRule<T>.States 属性是词法分析器的 DFA 状态的列表,列表的每一项都是一个 StateData 结构,包含相应 DFA 状态的转移和对应的终结符索引。这个列表中实际上包含 ContextCount×2 个 DFA,这些 DFA 的首节点索引是从 0 到 ContextCount×2-1,其中每个上下文对应 2 个 DFA,前一个 DFA 对应于当前上下文中的所有非行首规则,用于从非行首位置进行匹配;后一个 DFA 对应于当前上下文中的所有规则,用于从行首位置进行匹配。索引为 i 的上下文,对应的两个 DFA 就是 i*2 和 i*2+1。关于行首和非行首规则的详细信息,请参考《C# 词法分析器(四)构造 NFA》的第四节“多条正则表达式、限定符和上下文”。
以上就是词法分析器所需的信息,只要获取了这些信息,就可以根据需要,构造自己的词法分析器。详细的实现,请参考《C# 词法分析器(六)构造词法分析器》中提供的算法,甚至可以将数据写入 .cs 文件中(甚至可以使用其它语言实现,因为数据本身是不影响实现的),实现词法分析器的生成(虽然现在我还仍未实现这点)。
以上的数据,全部是以比较容易理解的形式存储的,未进行压缩,所以可能会占用比较多的空间。在具体的实现中,可以根据需要改变数据存储格式,或选用一些压缩算法(如使用四数组压缩 DFA 状态)。
C# 词法分析器(七)总结的更多相关文章
- C# 词法分析器(五)转换 DFA
系列导航 (一)词法分析介绍 (二)输入缓冲和代码定位 (三)正则表达式 (四)构造 NFA (五)转换 DFA (六)构造词法分析器 (七)总结 在上一篇文章中,已经得到了与正则表达式等价的 NFA ...
- C# 词法分析器(一)词法分析介绍 update 2014.1.8
系列导航 (一)词法分析介绍 (二)输入缓冲和代码定位 (三)正则表达式 (四)构造 NFA (五)转换 DFA (六)构造词法分析器 (七)总结 虽然文章的标题是词法分析,但首先还是要从编译原理说开 ...
- C# 词法分析器(二)输入缓冲和代码定位
系列导航 (一)词法分析介绍 (二)输入缓冲和代码定位 (三)正则表达式 (四)构造 NFA (五)转换 DFA (六)构造词法分析器 (七)总结 一.输入缓冲 在介绍如何进行词法分析之前,先来说说一 ...
- C# 词法分析器(三)正则表达式
系列导航 (一)词法分析介绍 (二)输入缓冲和代码定位 (三)正则表达式 (四)构造 NFA (五)转换 DFA (六)构造词法分析器 (七)总结 正则表达式是一种描述词素的重要表示方法.虽然正则表达 ...
- C# 词法分析器(四)构造 NFA
系列导航 (一)词法分析介绍 (二)输入缓冲和代码定位 (三)正则表达式 (四)构造 NFA (五)转换 DFA (六)构造词法分析器 (七)总结 有了上一节中得到的正则表达式,那么就可以用来构造 N ...
- C# 词法分析器(六)构造词法分析器
系列导航 (一)词法分析介绍 (二)输入缓冲和代码定位 (三)正则表达式 (四)构造 NFA (五)转换 DFA (六)构造词法分析器 (七)总结 现在最核心的 DFA 已经成功构造出来了,最后一步就 ...
- C# 词法分析器
当前标签: 编译原理 C# 词法分析器(七)总结 CYJB 2014-01-09 12:46 阅读:582 评论:1 C# 词法分析器(六)构造词法分析器 CYJB 2013-05-07 01 ...
- 写一个简单的C词法分析器
写一个简单的C词法分析器 在写本文过程中,我参考了<词法分析器的实现>中的一些内容.这里我们主要讨论写一个C语言的词法分析器. 一.关键字 首先,C语言中关键字有: auto.break. ...
- C# 词法分析器(一)词法分析介绍
系列导航 (一)词法分析介绍 (二)输入缓冲和代码定位 (三)正则表达式 (四)构造 NFA (五)转换 DFA (六)构造词法分析器 (七)总结 虽然文章的标题是词法分析,但首先还是要从编译原理说开 ...
随机推荐
- 在springMVC的controller层获取view层的参数的方式
方法一:request.getParameter("name") 方法二:注解@RequestParam @RequestMapping("testRequestPara ...
- CSS3与页面布局学习总结——Box Model、边距折叠、内联与块标签、CSSReset
目录 一.盒子模型(Box Model) 1.1.宽度测试 1.2.溢出测试 1.3.box-sizing属性 1.4.利用CSS画图 二.边距折叠 2.1.概要 2.2.垂直方向外边距合并计算 三. ...
- Google 如何修复 TrustManager 实施方式不安全的应用
引用谷歌市场的帮助说明:https://support.google.com/faqs/answer/6346016 本文面向的是发布的应用中 X509TrustManager 接口实施方式不安全的开 ...
- 三、jQuery--jQuery插件--jQuery插件——Validation Plugin
简介: 客户端验证:现代网站填写表单时,几乎一定会采用的方式. 优点:1.可以减少服务器压力 2.缩短用户等待时间和提升用户体验 jQuery有很多表单验证插件:https://plugins.jqu ...
- C#学习笔记----栈与堆的知识
http://my.oschina.net/lichaoqiang/blog/291906 当我们对.NET Framework的一些基本面了解之后,实际上,还是很有必要了解一些更底层的知识.比如.N ...
- SQL错误级别 状态 怎么定义
关于SQL Server的错误严重性级别的说明,强烈认真看一下下面的两个链接 脱机帮助 ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.zh-CHS/sqlerrm9/html/ ...
- ubuntu 下使用 putty 调试
转自:http://blog.csdn.net/wh_19910525/article/details/39313457 Ubuntu的机子上,插上USB2COM线,准备开工. 检查USB2COM在本 ...
- impdp导入job
结论: 10g to 10g:整个用户导出,无法正常导入JOB 10g to 11g:impdp时加SCHEMAS参数会导致无法正常导入JOB 11g to 11g:可以正常导入JOB 参见:http ...
- golang json 包简单分析
首先上代码: func main() { b := true a1, _ := json.Marshal(b) a2, _ := Marshal(b) fmt.Println(string(a1)) ...
- VS2015上又一必备免费插件:Refactoring Essentials
(此文章同时发表在本人微信公众号"dotNET每日精华文章",欢迎右边二维码来关注.) 题记:Refactoring Essentials是一款用于代码分析和重构的开源免费VS20 ...