精读《syntax-parser 源码》

[ascoders]

syntax-parser 是笔者写的 JS 版语法分析器生成工具，最近其上层封装的 SQL 智能编辑器 因为有所应用，所以写一篇底层库的源码分析文章，供合作者参考。

---

精读《syntax-parser 源码》

[xuhongbo]

请问一下如何贡献文章？

[ascoders]

@xuhongbo

如果是贡献题材，可以在 周刊参考池 添加，一般是一个持续更新的周刊地址，最好是英文的（质量相对更高）。如果是单一文章，可以在每周 Open 的 Issue 下评论下期期望的话题。

如果是贡献精读文章：

1. 先开个 ISSUE，如果话题有意思可以吸引一些讨论。
2. 写作结束后直接提 PR，如果质量可以就作为当日下期的精读。
3. 因为贡献者文章结束时间无法保证，因此合 PR 的时间为提交后的下一个周一。

[xuhongbo]

@ascoders 好的，谢谢

[muzea]

重新做一套 “JS 执行引擎” 这一节没看明白，有没有课外补习 :)

所以需要模拟一个执行引擎，在遇到分叉路口时，将 functionB2 保存下来，随时可以回到这个节点重新执行。

这里是指匹配失败时的回溯吗？

[ascoders]

@muzea 指的是回溯，具体原因文章在 重做 JS 执行引擎 有举例介绍。

没有啥资料，因为 JS 没有 fork 堆栈功能，因此只能自己模拟啦。

[muzea]

这个地方不明白为什么回溯要做这么多事情，是因为 parser 里面会保存一些状态吗？那 parser 做成 fp 的风格不是更好一点，只需要保存已匹配的 ast 和剩余字符串，在需要解析的东西不是很大的时候成本并不是太高。

[ascoders]

@muzea 如果保存了 ast 与剩余 tokenIndex 是可以恢复执行，这个逻辑和我写的基本一致。

我想说明的是，不能用 JS 堆栈直接执行 Match，因为这样错误后无法恢复，必须先转成节点一块一块执行。其实用 fp 风格和链表都可以进行回溯，但在遇到解析稍大一点的字符串内存可能就爆了。