词法分析：程序美与逻辑美

近日自学《编译原理》偶有所思，遂记之，与大家分享，并希望能对和我一样的初学者有所帮助。不当之处，希望大家给予指正。 

---

考虑在词法分析中，识别一个数串：该串可以以任何数字前导，但必须以非零数字结束。生成该数串的文法可以表示为：G=({S,D,U},{0,1,2,3,4,5,6,7,8,9},P,S) ，其中P由下列产生式组成：

S→DS|U

U→1|2|3|4|5|6|7|8|9

D→0|U

或可描述为正则表达式：D ^*U，其中 *标表示可由任意多个字符组成。

 

很简单不是吗？

但存在一个问题：在编程中，任何可以被该正则表达式识别的句子，其所有字符都将在循环中被D吃掉，而U就被活活饿死！

为了使识别奏效，可以使用如下方案：

【方案1】 

    c = buffer.getc();         // 从缓存中取得字符c
     // D*
     while (D(c))                 // 判断c是否满足D的规则，也即c是否在{0,1,2,3,4,5,7,8,9}中
        c = buffer.getc();     // 从缓存取得下一个字符
     // U
     if (U(buffer.last()))     // 判断缓存中的上一个字符是否满足U的规则，即c是否在{1,2,3,4,5,6,7,8,9}中
        c = buffer.getc();
     else
         return   false ;         // 匹配不成功

     return   true ;             // 匹配成功

挺简洁地解决了问题，但怎么觉得那么别扭呢？不妨换几个标识符看看：

    c = stomach.eat();         // 吃一个字符
     // D*
     while (D(c))                
        c = stomach.eat();     // 不停地吃
     // U
     if (U(stomach.vomit()))     // 吐出来看看
        c = stomach.eat();     // 接着吃……
     else
         return   false ;

     return   true ;

呃，好恶心……

 

分析一下，之所以会出现D吃掉了原本该给U识别的字符，是因为U可以产生的字符集合是D可产生字符集合的子集。一般的，当前后两个非终结符可产生的字符集有交集时，就可能发生这种前面“撑死”后面“饿死”的情况。

将上述文法转换为自动机M ₁描述：

可以看到，这是一个非确定有限自动机（NFA），状态S接到U指令时就傻了，不知道应该去哪了。

可以将其转换为一个确定有限自动机（DFA）M ₂，如图：

此时，什么情况该往哪走就唯一确定了！但如果严格按照这个DFA编程，恐怕就必须使用GOTO了，为了实现结构化，可以先把该DFA转化成正则表达式。

先将其主路径上的回路剪断，得DFA M ₃：

然后可以轻松转换之为正则表达式：0*U(U|(00*U))*。编程实现之：

【方案2】 

    c = buffer.getc();
    
     // 0*
     while (Zero(c))
        c = buffer.getc();
    
     // U
     if (U(c))
     ... {
        c=buffer.getc();

        //(U|00*U)*
        while(U(c) || Zero(c))
        ...{//(U|00*U)
            //U
            if(U(c))
            ...{
                c=buffer.getc();
            }
            //00*U
            else if(Zero(c))
            ...{
                c=buffer.getc();
                //0*
                while(Zero(c))
                    c=buffer.getc();
                //U
                if(U(c))
                ...{
                    c=buffer.getc();
                }
                else
                ...{
                    return false;
                }
            }
        }

    }
     else
     ... {//如果U(c)判别失败
        return false;
    }
     return   true ;

  呃……虽然逻辑上感觉完善了，但程序看起来并不怎么清爽…… 

---

两种方案分别代表了两种 美，

方案1是 程序美，它想法直观，书写简洁，且更易读，执行效率也略高一筹。

方案2是 逻辑美，它更形式化，通用性强，而且不容易在扩展中出错。

选择谁更好呢？当然是根据实际需要，择其善者而从之啦！

我想，大部分学计算机专业和数学专业科班出身的人都会选择方案2，毕竟有形式化的描述让人放心。但如果不需要自动生成词法分析器，又不是Perfectionist的话，何不选择方案1给代码降降压呢？