数据库原理与OracleSQL语言.pptVIP

数据库原理与Oracle——SQL语言 属性文法和语法制导翻译 授课：胡静 语义分析——面向语法的定义 所处位置 分析技术 LL分析方法 计算最左推导 自顶向下的构造推导 LL的分析表指出要对最左边的非终结符进行扩展时，所选的产生式。 LR分析方法 计算最右推导 自底向上的构造推导 使用LR的状态集合和符号栈 LR分析表指出针对每一个状态，采用何种动作（移进/归约），并且下一个转入的状态是什么。 我们可以使用这些技术来构造 AST AST 复习 推导：使用的产生式的序列 S ? E + S ? 1 + S ? 1 + E ? 1 + 2 分析树：描述推导的图 并不能表示产生式使用的顺序 抽象语法树 (AST)：从分析树中去掉了那些不必要的信息。 AST的数据结构 潜在的AST构造 LL/LR分析技术都潜在的构造出了AST 分析树在推导过程中可以得到 LL parsing: 应用产生式的序列潜在的描述了AST LR parsing：应用归约的序列潜在的描述了AST 我们希望从分析过程中明确的创建AST： 在分析器中添加一定的代码来明确的创建AST AST 的构造 LL分析: 对非终结符进行扩展 ? Example: AST的构造 LR分析 我们也需要添加一些代码使得AST可以明确的被构造出来。 LR分析中AST的构造方法： 将树的一部分存放在堆栈里 对每个在堆栈中的非终结符B，将以B作为根节点的自树也存放在堆栈里 当分析器使用产生式B →γ实施一个归约操作时，为B构造一个AST的结点 LR分析中AST的构造 问题 代码的结构混乱：进行语法分析的代码和构造AST的代码混在一起 语法分析器的生成器： 产生的语法分析器需要包含AST的构造代码 如何使用语法分析器的自动生成器构造不同的AST数据结构？ 我们需要在分析阶段同时的进行其他的动作。 比如，语义检查 Syntax-Directed Definition 解决方法: syntax-directed definition 扩展每个文法的产生式，使得每个产生式都和语义动作（代码）相关联： S → E+S { action } 语法分析器的生成器将这些代码加入到生成的语法分析器中。 当使用产生式进行归约时，对应的动作就会被执行。 语义动作 动作：用程序设计语言编写的代码 和语法分析器的生成器的程序设计语言相同 例如： Yacc = actions written in C CUP = actions written in Java 动作需要访问语法分析栈！ 语法分析器的生成器将状态栈进行扩展，用那些用户定义的结构（分析树）去替换原先的符号 动作代码应该可以引用状态 需要一套命名机制 命名机制 我们需要对那些在语义动作代码中可能用到的文法的符号进行命名。 需要分别引用出现在不同地方的同一个非终结符号 E → E1 + E2 需要对左边/右边的符号进行区别 E0 → E + E 命名机制：Yacc Yacc: 使用关键字: $1引用右边的第一个符号，$2引用右边的第二个符号，以此类推 关键字$$引用左边的非终结符 Yacc的例子 expr ::= expr PLUS expr { $$ = $1 + $3; } 构造 AST 使用语义动作构造AST AST在分析过程中自底向上的构造 例子 分析栈保存了每个非终结符的值 AST的设计 保证AST的抽象性 并不是对每个分析树中的结点都要引入一个AST的结点。 AST 的设计 不要使用一个单一的类AST_node 例如对于像if, while, +, *, ID, NUM： class AST_node { int node_type; AST_node[ ] children; String name; int value; …etc… } 问题：必须要为每个不同的结点保留不同fields来保存其特性。 不可扩展，对Java的类型检查没有帮助 使用类的继承 使用子类解决问题 对每一个“感兴趣的”文法中非终结符的集合使用一个抽象类， (例如，产生式) E → E+E | E*E | -E | (E) 另一个例子 可以使用syntax-directed定义在语法分析的时候进行语义检查 例如，类型检查 好处：有效率 一个简单的编译过程可以完成多个任务 坏处：代码结构混乱 将语法分析和语义检查过程混在一起 当AST结构改变的时候进行检查 只能是自底向上的过程中 类型声明的例子 值的传递 当创建AST的时候，也要把值属性进行传递。 另一个例子 值的传递 值要两个方向传递：自顶向下和自底向上 构造方法 从语义检查阶段可以单独的构造AST 反复检查AST并且进行语义检查 (或其他动作)只有当树被建立