知也无涯

吾生也有涯,而知也无涯,能学一点算一点…

  • 这是一个系列文章,旨在了解如何使用Flex/Lex和Yacc/Bison进行词法和语法解析。这个系列,分成了几个部分,包括

    • flex的基本用法
    • 使用flex/bison实现一个简单的计算器
    • 实现一个带有条件判断与循环的计算程序

    了解这个系列需要一定的编译原理知识作为背景知识,了解程序如何从字符串先解析成Token,而后使用语法解析器生成解析树,最后执行该解析树。

    概述

    lex/flex可以按照“词法文件”的定义,将文本解析成单个的Token,然后通过执行“词法文件”中定义的Action来完成一些操作,一般,flex的输出会通过函数/变量将结果传递给yacc/bison进行进一步的语法解析。为了简化,本文将仅通过独立的“词法文件”完成一些操作,以了解flex的基础使用。

    这里完成的程序是一个简单的“count”程序,输入是一个文件,程序输出文件中包含的字符数、词语数、以及行数。

    安装flex并编写词法文件

    1. 安装lex: yum/apt-get install flex

    2. 编写如下词法文档:

    %{                                       //
            int characters = 0;              //    %{ ... }% 之间的部分是"Declarations"
            int words = 0;                   //    Declarations 部分声明的变量,是可以在全局使用的
            int lines = 0;                   //    例如,在该示例的main程序中,就通过extern声明的方式
    %}                                       //    使用了这些变量
    %%                                       //
    \n      {                                //    从这里开始是Translations阶段
                    ++lines;                 //    这里定了Token,以及遇到了Token之后
                    ++characters;            //    应该采取/执行什么,例如这里遇到了\n字符
            }                                //    则,将lines/characters变量都加1
    [ \t]+          characters += yyleng;    //
    [^ \t\n]+ {                              //    注释部分的文本需要删除,程序才能正常编译 
                    ++words;                 //    删除注释的vim命令:1,$s/\/\/.*$//g 
                    characters += yyleng;    //
            }                                //
                                             //
    %%

    直接使用如上代码的话,后面就会在gcc编译的时候遇到如下错误:

    $ lex zzx.l
    $ gcc lex.yy.c wc.c -o wc.out
    /tmp/cc1SPYm2.o:In function yylex':
    lex.yy.c:(.text+0x42f):undefined reference toyywrap'
    /tmp/cc1SPYm2.o:In function input':
    lex.yy.c:(.text+0xf73):undefined reference toyywrap'
    collect2: ld returned 1 exit status
    

    如果你也遇到了这个错误,不用担心,你并不孤单,在Stackoverflow上看到解决该失败的的答案一共有150点赞(up),就知道大家都一样了(参考@Stackoverflow)。因为默认的,lex生成的词法解析程序中,在最后是需要调用的yywrap函数的(关于yywrap),如果不打算提供该函数,则可以使用lex选项 %option noyywrap 禁用该调用。那么上面的代码就需要修改为:

    $ cat zzx.l 
    %{
            int characters = 0;
            int words = 0;
            int lines = 0;
    %}
    %option noyywrap
    %%
    \n      {
                    ++lines;
                    ++characters;
            }
    [ \t]+          characters += yyleng;
    [^ \t\n]+ {
                    ++words;
                    characters += yyleng;
            }
    
    %%

    编写入口函数并调用yylex

    词法文件需要使用工具flex将其编译生成一个c语言文件,然后再使用gcc将其编译成一个可执行文件。编译前,我们需要先编写一个简单的main函数. 再编写一个程序的入口函数(main),并调用yylex()就可以了。具体如下:

    $ cat wc.c
    #include <stdio.h>
    
    int yylex(void);
    
    int main(void)
    {
            extern int characters, words, lines;
    
            yylex();
            printf("%d characters, ", characters);
            printf("%d words, ", words);
            printf("%d lines\n", lines);
            return 0;
    }

    这里需要注意:在程序中,我们通过调用yylex()完成了实际的词法解析过程,并获得执行结果。这是一个非常简单的示例,实际过程比这要更加复杂,在词法文件中,每一次rule解析完成后,再起action部分,通常都会有return语句结束本次yylex调用,所以会是一个反复调用yylex的过程。

    编译并执行

    $ lex zzx.l    
    $ gcc lex.yy.c wc.c -o wc.out
    $ chmod +x wc.out
    $ cat s.txt
    this is a input file.
    this is a input file.
    $ ./wc.out < zzx.l
    404 characters, 36 words, 18 lines
    $ ./wc.out < s.txt
    44 characters, 10 words, 2 lines

    好了,至此,我们就完成一个词法解析的任务,因为这个任务不涉及任何语法(yyac)解析,所以比较适合初学者学习词法解析工具lex。

    补充关于Definitions

    为了再略微增强该示例的,这里对上面的示例又做了一个小调整,新增一行“Definitions”,有时候为了增强可读性,会对一些expression定义一个名称,如下,将\n定义为NL:

    %{                                        //
            int characters = 0;               //   %{ ... }% 之间的部分是"Declarations"
            int words = 0;                    //   Declarations 部分声明的变量,是可以在全局使用的
            int lines = 0;                    //   例如,在该示例的main程序中,就通过extern声明的方式
    %}                                        //   使用了这些变量
                                              //
    NL \n                                     //   这里新增了一行,这是一行 Definitions
                                              //   将\n用字母NL定义,所以下面的\n也就可以使用NL
                                              //   试想,如果表达式很复杂用这种方式,可读性会增强很多
    %%                                        //
    NL      {                                 //   从这里开始是Translations阶段
                    ++lines;                  //   这里定了Token,以及遇到了Token之后
                    ++characters;             //   应该采取/执行什么,例如这里遇到了\n字符
            }                                 //   则,将lines/characters变量都加1
    [ \t]+          characters += yyleng;     //
    [^ \t\n]+ {                               //   注释部分的文本需要删除,程序才能正常编译        
                    ++words;                  //   删除注释的vim命令:1,$s/\/\/.*$//g 
                    characters += yyleng;     //
            }                                 //
                                              //
    %%           

    自此,我们就了解一个词法解析文件的几个主要部分:Definitions、Declarations、rule(以及rule对应的Action)。

    参考资料:

    更多说明

    • Flex / Lex程序通常与Yacc/Bison一起使用,flex负责词法解析,bison则负责语法解析
    • flex与bison接口的函数,就是上面的调用 yylex()函数,该函数每次基于某个规则(rule)解析到一个新的Token的时候,则会执行对应的“Action”(也就是每个Token后面的代码)部分的代码。例如,上面的程序中会执行++lines++words代码。
    • 在rule action部分,我们看到使用了一个yyleng的“变量”用于获取当前被解析的原始字符串的长度。类似的“变量”有:yyleng、yytext、yyin等,完整的列表可以参考:Values Available To the User。另外,这些“变量”并不是真的变量,大部分都是一些“宏”,例如,yytext的真实定义可能是这样的:#define yytext (((struct yyguts_t*)yyscanner)->yytext_r)。了解这一点,有利于理解这些”变量”并不能在外部直接引用。
      • yyin yylex函数处理的字符串来源,默认情况是标准输入,在你的程序,例如可以定义为一个打开的文件描述符(在Posix中,一起都是文件)
      • yylength 用于记录,当前读取的Token的长度
      • yytext 用于记录当前读取的文本
    • 一般的,flex的“Action部分”,会包含一个return,例如如果遇到一个整数,可能会看到类似这样的代码:return INTEGER; 这时候,yylex()遇到一个对应的字符就会返回INTEGER
    • 在实践中,则是按照如下方式实现:
      • 在 yacc/bison的语法文件中定义Token,例如整数为 INTEGER,语法为 %token INTEGER
      • 使用yacc/bison命令生成对应的头文件,头文件则会包含关于 INTEGER的预定义:#define INTEGER 257
      • 只需要在flex词法文件中包含该头文件,就可以使用这里的预定义 INTEGER
      • 那么较为完整的代码看起来就是这样
    cat cal.y
    ...
    %token INTEGER
    ...
    cat cal.tab.h //这是bison生成的文件
    ...
    #define INTEGER 257
    ...
    cat cal.l
    ...
    [[:digit:]]+  { return INTEGER; }
    ...
    • 我们在考虑另一个问题:在lex的rule action可以使用本地的“变量”(其实是“宏”),也会通过return语句给yyparse()中调用yylex时,返回当前Token的类型。如果一个Token是一个[:digit:]+的时候,我们除了需要知道这个Token是一个整数之外,至少yyparse()还需要知道这个是一个什么整数,具体数值是多少,当然并不是所有的token都需要,一般identifier都是需要的。而,前面的yytext都是yylex本地的“变量”。这时候,通常会使用yylvalyylval是一个由yacc/bison定义的变量(默认是int类型),用于存储词法解析需要传递给yyparse的数据,在yacc/bison的语句处理的Action阶段,可以使用变量,以获得词法解析阶段的一些值。例如,一个Token是一个整数、字符串(并非keyword)的时候,我们会将对应的值存储在yylval中。所以,yylval通常会被定义为一个联合体(union类型),用于存储不同类型的值。

    关于这几个概念的更详细细致的解释可以参考最前面提到的“IBM的z/OS系统的文档中关于lex和yacc的介绍”(参考:Tutorial on using lex and yacc)。

  • SQL Server中的Schema、dbo

    ·

    MySQL已经流行了非常长时间,已经有一代数据库从业者最初就是从MySQL起接触数据库。再重新了解其他数据库的时候,虽然底层原理很多类似,但是上层实现、接口与使用上还是有非常大的不同。本文,就简单的介绍一下SQL Server中的Schema、dbo概念。

    参考阅读:

    Schema or dbo or Database?

    这是一个问题。也有很多人做了很多深入的讨论,关于这一点可以参考这篇文章,以及这篇文章后面的100个评论: Why Use Schemas?

    有几个观点吧:

    • 使用Schema的想法是”美好的”,但是实际的情况往往并不理想,甚至是还不如统一使用dbo。文章作者说,随着时间推移,他看到的实际情况是,使用了多个Schema之后,往往不同Schema中存储的内容并是逻辑上在一起的,而是由于各种历史原因,各个业务的数据表都会混杂在一起,这时候,由于修改应用的成本太高,大家也往往也不会去移动Schema下的表,去让他们在逻辑上更加合理。所以,基于此,作者并不赞同使用Schema,而是倾向于在需要的时候使用不同的Database去隔离逻辑上没什么关系的数据表。
    • 很多的第三方的应用,都是使用一个数据库、一个用户访问所有的数据表,因此Schema方式虽然很理想,但是现实世界并不常用。
    • 另一方观点是在于,在一个设计较好的数据库中,Schema可以很好的对不同的数据表进行分组,例如,用户相关的表,库存相关的表,店铺相关的表等。另外,在基于这样设计下,权限系统也会更加好管理。另外,否则可能会使用大量的前缀的方式(例如,user_开头代表用户,shop_开头代表店铺相关业务)来区分这些表,看起来并不整齐,整体的授权管理也会比较难一些。
    • 比较多人,认为虽然多Schema的设计,前期是比较理想的,但是随着业务和需求的变化,表的业务属性也会发生变化,按照多Schema设计来说,这时候是需要将表移动到合适的Schema下面,但是因为代码的SQL中都带有Schema,这就到这个”移动”的操作变得异常困难,所以也就会最终一定会破坏当初使用Schema的初衷。
    • 很多人认为,所有表放在dbo中,从业务角度来说,其实问题是最少的。
    • 有人提到,他这样使用schema,将所有的基础表都放在dbo中,但是某些特殊用户的表或者对象放在特定的schema中。例如,一些特定用途的视图、存储过程等。这样,更加便于权限管理。(个人注:这似乎是一种非常适合schema的场景)
    • (Mark Broadbent)提到,相比Oracle数据库的Schema,SQL Server权限系统设计更加面向的是Database,而不是Schema。用户通常都有多个Schema的访问权限。
    • Ben Thul提到,在大量存储过程的权限管理过程中,schema应该是非常有效的。这和前面的观点是有一定的相似的。Brent Ozar则认为,权限管理更多是通过用户角色组来管理,就可以了。Ben Thul也反驳到,当你已经有100个存储过程的时候,当写101个存储过程,如果没有schema,那么还是要单独管理这个存储过程的访问权限,这时候如果通过以schema为单位的权限管理,确实是高效的。
    • 有来曾经在MSFT PMs相关项目的员工(Clifford Dibble),回忆schema设计的初衷如下:
      • 在单个数据库中,提供一种命名空间隔离的方式
      • 在使用GRANT语句授权时,大大简化对一组对象进行授权管理
      • 微软公司内部”WinFS”团队需要该功能
      • 与ANSI/ISO SQL有更好的兼容性
      • SQL Server自己需要一个系统使用schema:sys
      • 让用户删除更加简单(有一些明确的客户需要)
      • 允许让角色组作为schema的owner
      • 允许多个用户都有某个特定的默认schema
    • vinod jain在2021年给出回答(是的,这个帖子是2010年发的,这个讨论延续了11年)有一定代表性,也是两种观点的一个中间形态:
      • 所有的核心表全部都放在dbo中
      • 其他的辅助功能表都独立放在不同的schema中,例如结构记录变更时用到的临时表和数据、导入导出时的中间表、用户日志表
  • 关于云数据库行业动态

    ·

    “云数据库行业动态”是一个每周五发布的行业发展动态的聚合,包括各个云数据库最新的工作进展、数据库版本发布、融资概况、行业案例等信息。

    该系列最早起源于2020年左右的工作周报。当时,需要每周/双周通过“周报”形式汇报最近的工作情况,周报的一部分就是“行业动态”,当时自己主要负责PolarDB产品体系管理、云数据库生态发展、云数据库品牌运营、文档建设等工作,所以,“行业动态”部分主要会关注行业主要的云原生数据进展情况,并以简报形式记录在公司内部的知识库中。

    2021年10月,从阿里云离开后,这个习惯一直保持了,并以公众号的形式对外发布汇总的结果。也因为对外了,所以,对于内容的要求也更高了一些,包括要求更加及时、结构化和系统等。于是就有了当前的每周云数据库行业动态。

    因为需要每周坚持,有时候还是挺困难的,再早期的时候也会花非常多的时间进行汇总和总结。最近,最近,通过了自动化的程序把汇总的工作都自动完成了,不过还是有些人工进行总结和润色。具体的程序参考:链接

    具体的,自动化程序使用php/curl模块自动化的获取文章内容更新,此外还使用了Google Cloud提供的Translation API服务对海外英文进行自动化的翻译。也曾尝试了ChatGPT做一些Summary,不过效果并不是很好,所以放弃了。

  • 学习的误区

    ·

    小时候,就被一直教育,要独立完成所有的寒假作业。不能有任何的“参考”,这个参考定义非常广,甚至查阅资料、字典、与同学讨论等等都算是抄袭。

    这就留下有一类永远都做不完的作业。例如,那时候作业有一类是填写歇后语,有一题是“猪八戒照镜子–”填写后面的内容。以现在的生活经验,这道题目当然简单,但对一个初中生,在不允许任何“参考”,所以知道坐在那里瞎想,现在想想,也是醉了。

    优点,我的数学训练比较好,所以初高中数学成绩都算不错,只是没有天赋,只能算是不错。

    生活的复杂和人类社会这么多的积累,单单靠这样的”空明的思考”之于很多知识的学习是非常不适合的。学习的正确方法,应该是先学习当前的人类已经掌握的知识,然后再去尝试探索边界,有时候完全独立的思考的目的并不是想出什么新想法,而更多的时候一种思维的锻炼。

    文科则通常更加辩证,没有简单的对错,也没有简单的唯一的答案,可以更有创造力一些。

  • 编写一个shell脚本,做一些事;改进这个脚本,更好做这件事;再改进这个脚本,帮自己做些其他的事情;再改进这个脚本帮助其他人做一些事……

    简单的脚本处理,一般使用变量$0 $1 $2 …就可以依次获得全部参数,还可以通过$#获得这个脚本一共有多少个参数。如果你需要处理的情况(或者分支)更多的时候,这个方法就不凑效了,这时候,就可以考虑使用getopts了(man getopts)。

    (more…)