开发者:
- 李唯聪
- 傅奕博
- 伊合拉斯
- 实现语言:node.js
- token命名
- RESERVED
- ID
- SEPERATOR
- ASSIGN
- UNDERANGE
- CHARC
- NUMBER
- EOF
语法分析与词法分析相互独立,作用在词法分析过之后,解析词法分析产生的token序列,生成语法树。
语法树由语法分析程序按照文法规则解析token序列生成,其中绝大部分的文法规则遵从书本上的内容。实现语言与作者使用语言不同,递归下降的分析方法使用Go语言实现。因此一些具体的实现也因为语法特性不同与书本上的实现方式不同。
对于语法错误处理,策略与词法分析不同。当出现错误时终止语法分析过程,返回错误调用栈。
编写程序过程中,遇到了书本上的一些问题,在实现的过程中进行了一些处理,因此并非全部的文法都与书上一样,之后会在罗列出来我们遇到的问题。
有关语法树的数据结构,基本上是原样复用了书上的结构,一些具体的结构根据开发语言特性做了修改:
- 递归下降分析
- 子节点使用切片Slice存储,放弃了指针链表的格式
- 表达式节点构造的时候遇到连减或连除,需要对节点本身进行递归左旋
- Minus对非括号Minus,左旋
- Over对非括号Over,左旋
- 标志节点
- ProK
- PheadK
- TypeK
- VarK
- ProcDecK
- StmLK
- 具体节点
- DecK
- ArrayK
- CharK
- IntegerK
- RecordK
- IdK
- StmtK
- IfK
- WhileK
- AssignK
- ReadK
- WriteK
- CallK
- ReturnK
- ExpK
- OpK
- ConstK
- IdK
- DecK
- ProcDeclaration过程定义语句末尾加分号,84页没加
- ProcDeclaration过程定义以ProcDecMore结尾,84页未体现
由于语法树的输出格式主要作用在于完整表达语法树包含的语法信息,本身格式具有灵活性且书上仅有示例程序,并未明确指定输出格式。为了便于两种语法分析算法结果比对以及之后步骤的处理,有必要对语法树的输出格式进行约定:
- 每个节点占一行
- 跟节点在第一行起始处
- 子节点相对于父节点向内缩进一个制表符
- 内容格式:
- 节点格式:
- NodeKind (Kind) (Name) (typeName) (Attr)
- Name格式:
- name1 name2 ...(空格分割)
- Attr格式:
- low high childType (ArrayAttr)
- paramt (ProcAttr)
- op val varkind (ExpAttr)
- 节点格式:
- 确定整体开发时间3.13-4.17
- 确定总体测试和报告撰写时间4.17-4.20
- 确定开发任务
- 词法分析
- 基础框架
- 内容填充
- 两种语法分析(并行开发)
- 递归下降
- LL(1)
- 语义分析
- 编译日志和错误的产生和收集
- 展示和交互平台(前端页面)
- 编译流程控制(后端服务)
- 格式化程序再生成(支线任务)
- 词法分析
- TODO
- 熟悉C/C++语言
- 阅读《设计与实现》的简介和词法分析部分
- 构思词法分析框架
- 重新确认开发语言
- 词法分析 js
- 语法分析 java | python | go
- 语义分析待定
- web后端服务待定
- 中间产物输出格式
- 词法分析token序列
- json[{"type":"typename(string)", "name":"name(string", "line":"line_num(int)" },{}...]
- 词法分析token序列
- DONE
- 更改git仓库权限
- 粗读词法分析部分,掌握原理
- TODO
- 完善脚手架,多加注释
- 编写DFA节点,增加Token和error
- 尝试测试一个完整的从输入到输入
- 近期安排
- @yhls 编写DFA节点
- @lwc 准备语法分析递归下降部分
- @fyb 语法分析LL1
- TODO
- 约定token类型的命名
- DONE
- 词法分析大部
- TODO
- 测试词法分析
- 约定语法分析输出格式
- 开发语法分析模块
- DONE
- 词法分析的完善和测试
- TODO
- 理解语法树数据结构
- 语法分析LL1和递归下降的结构设计
- 确定语法树输出格式
- DONE
- 语法分析递归下降的开发和简单测试
- 语法树输出结构确定
- 语法树数据结构分析