X语言解析器C++实现(不知所言篇)
一、为什么不知所言
纠结了很久，要不要写这一篇文章，因为最近一直在写解析AST代码，距离写完解析AST代码还需要一小段时间，没有成果输出，也不知道说些什么好。可最近确实也遇到一些问题，也多了一些思考，如果不把这些问题、思考记录下来，等时间过了，我怕我会忘记。虽然是问题，但却是宝贵的。
二、X语言关键字
编号 | 分类 | 关键字 | 说明 |
1 | 包 | package | 声明包 |
import | 导入包 | ||
2 | 条件 | if | 判断语句 |
else | 判断语句 | ||
else if | 判断语句 | ||
3 | 循环 | for | 循环语句 |
continue | 跳过当前到下一次循环执行 | ||
break | 跳出整个循环 | ||
in | 增强for循环遍历for in | ||
4 | 分支 | switch | 分支语句 |
case | 匹配分支条件 | ||
break | 跳出分支条件 | ||
default | 默认分支 | ||
5 | 变量修饰 | const | 不可变常量声明 |
let | 变量声明 | ||
static | 静态成员（变量/常量/函数） | ||
private | 仅内部可访问（包内/引用类型内） | ||
6 | 引用类型 | class | 定义类型 |
interface | 接口 | ||
implement | 实现接口 | ||
this | 对象自身 | ||
function | 成员函数定义 | ||
trait | 组合composition | ||
7 | 并发 | go | 并发入口定义 |
wait | 等待并发完成 |
三、X语言包管理
首先，X语言支持包，比如一个项目目录结构如下：
project | 项目名，root根包所在，每个项目都有一个root根包 | |||||
package.meta | 包声明文件，每个包下面都必须有一个包声明文件 | |||||
main.x | 包入口文件，每个包都必须有一个main.x包入口文件，入口文件可声明包内变量、常量和函数，包含始化执行代码 | |||||
package_a | 目录，包含package.meta包声明文件，即为一个包 | |||||
package.meta | 包声明文件 | |||||
main.x | 包入口文件 | |||||
class_a.x | 除main.x外，其他包内.x文件均为类型定义文件，不允许包含包含始化执行代码，所有加载包时立即执行的代码都应在main.x中定义 | |||||
class_b.x | 其他类定义 | |||||
... | 更多类定义 | |||||
package_x | 更多包定义 | |||||
四、X语言操作符
优先级 | 操作符 | 说明 |
1 | . | 点，主要用于访问对象的成员（如属性和方法）、调用类的方法或静态成员、以及用于包和子包的分隔 |
[] | 顺序容器下标访问 | |
() | 函数调用或括号提升优先级 | |
2 | ~ | 按位取反 |
! | 逻辑非 | |
++ | 前缀/后缀自增 | |
-- | 前缀/后缀自减 | |
3 | * | 乘 |
/ | 除 | |
% | 求余 | |
4 | + | 加 |
- | 减 | |
5 | << | 左移动 |
>> | 右移动 | |
6 | > | 大于 |
>= | 大于等于 | |
< | 小于 | |
<= | 小于等于 | |
7 | == | 等于 |
!= | 不等于 | |
8 | & | 按位与 |
9 | ^ | 按位异或 |
10 | | | 按位或 |
11 | && | 逻辑与 |
12 | || | 逻辑或 |
13 | = += -= *= /= ... | 赋值及复合形式 |
不支持C语言中的`(type)`, `*`, `&`, `sizeof`,`?:`,`,`，即类型转换、解引用、取地址、求大小、三目条件操作符、逗号操作符，另外也不支持++或--操作出现在组合表达式中，即只能单独x++,++x,x--,--xx耽于语句。
五、遇到的问题
第一个问题：
目前边写代码边重构代码，其中重构最大的就是需要把原来的函数支持递归操作。在整个解析过程中，最复杂的部分在于表达式的解析。先看一段国际C语言混乱代码大赛的混乱代码：
#include
#include <sys/time.h>
#include <X11/Xlib.h>
#include <X11/keysym.h>
double L ,o ,P
,_=dt,T,Z,D=1,d,
s[999],E,h= 8,I,
J,K,w[999],M,m,O
,n[999],j=33e-3,i=
1E3,r,t, u,v ,W,S=
74.5,l=221,X=7.26,
a,B,A=32.2,c, F,H;
int N,q, C, y,p,U;
Window z; char f[52]
; GC k; main(){ Display*e=
XOpenDisplay( 0); z=RootWindow(e,0); for (XSetForeground(e,k=XCreateGC (e,z,0,0),BlackPixel(e,0))
; scanf("%lf%lf%lf",y +n,w+y, y+s)+1; y ++); XSelectInput(e,z= XCreateSimpleWindow(e,z,0,0,400,400,
0,0,WhitePixel(e,0) ),KeyPressMask); for(XMapWindow(e,z); ; T=sin(O)){ struct timeval G={ 0,dt*1e6}
; K= cos(j); N=1e4; M+= H*_; Z=D*K; F+=_*P; r=E*K; W=cos( O); m=K*W; H=K*T; O+=D*_*F/ K+d/K*E*_; B=
sin(j); a=B*T*D-E*W; XClearWindow(e,z); t=T*E+ D*B*W; j+=d*_*D-_*F*E; P=W*E*B-T*D; for (o+=(I=D*W+E
*T*B,E*d/K *B+v+B/K*F*D)*_; p<y; ){ T=p[s]+i; E=c-p[w]; D=n[p]-L; K=D*m-B*T-H*E; if(p [n]+w[ p]+p[s
]== 0|K K)N=1e4; else{ q=W/K *4E2+2e2; C= 2E2+4e2/ K
*D; N-1E4&& XDrawLine(e ,z,k,N ,U,q,C); N=q; U=C; } ++p; } L+=_* (X*t +P*M+m*l); T=X*X+ l*l+M *M;
XDrawString(e,z,k ,20,380,f,17); D=v/l*15; i+=(B *l-M*r -X*Z)*_; for(; XPending(e); u *=CS!=N){
XEvent z; XNextEvent(e ,&z);
++*((N=XLookupKeysym
(&z.xkey,0))-IT?
N-LT? UP-N?& E:&
J:& u: &h); --*(
DN -N? N-DT ?N==
RT?&u: & W:&h:&J
); } m=15*F/l;
c+=(I=M/ l,l*H
+I*M+a*X)*_; H
=A*r+v*X-F*l+(
E=.1+X*4.9/l,t
=T*m/32-I*T/24
)/S; K=F*M+(
h* 1e4/l-(T+
E*5*T*E)/3e2
)/S-X*d-B*A;
a=2.63 /l*d;
X+=( d*l-T/S
*(.19*E +a
*.64+J/1e3
)-M* v +A*
Z)*_; l +=
K *_; W=d;
sprintf(f,
"%5d %3d"
"%7d",p =l
/1.7,(C=9E3+
O*57.3)%0550,(int)i); d+=T*(.45-14/l*
X-a*130-J* .14)*_/125e2+F*_*v; P=(T*(47
*I-m* 52+E*94 *D-t*.38+u*.21*E) /1e2+W*
179*v)/2312; select(p=0,0,0,0,&G); v-=(
W*F-T*(.63*m-I*.086+m*E*19-D*25-.11*u
)/107e2)*_; D=cos(o); E=sin(o); } } 通过分析以上混乱代码，除了不方便阅读外，一部分一部分解析，会发现，最难解析的部分在于表达式，为什么呢？因为表达式中可包含所有的操作符，是所有的操作符，特别还包括函数调用、数组下标访问、自增/自减++--加号减号可以无限长，这意味这在解析过程中，按从字符串开始到字符串结束一次遍历就能得出AST，变得不可能。
所以，不能一次遍历得出AST，这不符合我的初衷，所以要简化特性，我就把右结合性的操作尽量去掉了，包括：
1、三元条件运算符 (?:)
2、单目操作符自增/自减，必须独立语句
然后，我突然意识到Go也是做了这两个限制，真的只有在写具体解析器代码，才深刻意识到别人为什么要做某件事情的意图所在，因为别人遇到问题了，然后可能想用最简单的办法来解决了。
第二个问题：
泛型支持，目前我还没真正写到这部分，但稍微思考了下，一方面，我不想像Java那种把类型擦除，但我也不想像C++那样如此复杂，C++甚至还支持元编程，我的想法是参考Java，但不要像Java那样类型擦除，Java的泛型类型擦除，在我看来就是一个失败的设计，虽然简单，但牺牲了细微性能和未来拓展型。
第三个问题：
AST解析完成后，采用何种方案执行代码，我想过这几种：
1、直接调用C++对应函数执行
2、根据AST生成对应的c++源代码，再调用gcc编译c++源代码
3、根据AST生成自定义的字节码，采用有栈式解析调用， 后期加上JIT
4、根据AST生成汇编代码，提供运行时汇编，运行时汇编调用内核提供的系统调用
其中，1/2/4的方案，我都是有思路可以写下去的，3的话，JIT部分目前没思路如何实现。
我最倾向，第一个版本采用1，先用来验证一些问题，然后第2个版本可以使用2或4，这是我最想做的。对于方案2，我发现竟然Nim语言也是这种思路，至于4的话，Go就是这种思路，3的话，python就是这种思路，java应该也是。反正第1种思路，不是常见解决方案，但我认为第1种勉强可接受，可用于第一个版本，用来验证一些问题。
最后想说的是，大家姑且就听听我以上的啰嗦，听听有哪些问题，提出哪些解决方案，总结哪些知识等等就好了。希望一如既往得到您们的关注、点赞、订阅和评论，谢谢。