eval ast 6

总结

这一系列文章来自写脚本语言的解释器时遇到的困难，即对抽象语法树的求解。

回头来看有以下心得：

问题要从简单到复杂

这里我有如下问题：

一个是因为都说ast要用到visitor设计模式，于是我一开始陷入到底如何用visitor设计模式解决问题的复杂逻辑中， 于是问题就变得复杂了，解决办法是一开始不想什么模式，根据分析逐步实现，慢慢地遇到了需要模式的地方，也就明白了。

另一方面，我一开始在写了一半的解释器上直接思考对ast的求值，这增加了我思考的负担，得考虑很多不相干的问题。 最后还是另开一个小例子，将问题局限在最低层面（只处理整型加法），逐步复杂化来实现。 事实上，实现整型加法后，思路就已经清晰了。

我感觉，如果发现我考虑的太多，就是一个危险的信号，需要重新思考。

还有一点就是有时候问题会很多，就各个击破，从最基本的开始。 比如一开始我对于go的接口、继承（组合）用法不熟悉，这时候用简单例子试一试， 才明白这种继承其实是组合，因为不能用于多态。 一开始我没测试这一点，导致总编译失败。

回归问题的本质，将问题描述出来

正如本文的分析，加上代码测试才逐渐解决问题，一开始的时候我的思路是理解别人的解决办法， 看了各种设计地很复杂的代码，一方面代码复杂度高，也是从简单问题逐步复杂化，但直接看很难看懂。 例如go自带的template的parser用到很多反射，结构也很复杂，看的很痛苦。 另一方面，对AST的求值我也确实没找到合适的代码。 于是最后开始回归到问题本质，靠分析解决。 且当把问题描述出来后，解决思路清晰了很多。

遇到难题放一放

遇到各种没解决的问题会很心烦且受挫， 其实也是因为把问题复杂度弄高了，放一放再回头看或许能找到解决的办法。

所以当明显感觉到很难想清楚时，放松一下，再分析、简化问题。