语言的精确度量化标准是什么呢？
Closed this issue · 7 comments
| 工具 | 精准度 | 开发难度 | 跨语言学习成本 | 添加新语言成本 | 可自动化重构 |
|---|---|---|---|---|---|
| 语言编译器 | 完美 | 低 | 高 | - | Yes |
| Antlr | 极高 | 中 | 中 | 中 | Yes |
| Ctags | 中 | 低 | 低 | 高 | Yes（成本高） |
| TreeSitter | 高 | 高 | 中 | 高 | Yes（成本高） |
| Doxygen | 中 | 低 | 低 | 高 | No |
| CodeQuery | 高 | 中 | 中 | 高 | Yes |
语言编译器 我可以理解，可能是因为携带类型以及其他的语义信息。
antlr，tree-sitter 这两种 parser generator 最后生成的都是 AST 或者 CST 吧？这其中为什么会有区别呢？
如果硬要说的话，CST 不是应该携带更多的信息吗？
欢迎给精准度来给 PR，改为 精确度量化。
现在这里凭的是感觉，之前大概看过 TreeSitter 的实现，好像与 TMLanguage 一样，使用的是正则匹配，编写成本也相对比较高。当然，这可能是我的误解。
tree-sitter 也是一个 parser generator ， 只不过为了降低学习门槛，用的javascript来定义 语言的语法。
正则表达式也不奇怪啊，他是把 tokenize 和 parse 的过程合并到一起了，正则表达式实际上是为了方便定义 token.
嗯，嗯，那来个 PR，改为一致的 准确度量化 ？
关于自动化重构这一点其实 成本高 这里指的是 修改 AST 吗？ 那倒确实 tree-sitter 的CST 是immutable 的，虽然也不是说不能修改CST， 这主要是为了做 incremental parsing. 不过 tree-sitter 可以使用 S-expression 来做很方便的 查询还是很好用的，这一点上总体来说我感觉和ANTLR 不相上下
主要是编写自动化重构的时候，要构建出语法的上下文以及完整的 AST ，用 S-expression 来实现的成本，反而更高了。比如说，我要 rename 一个方法的时候，就需要完整的 Call Graph，这个时候 S-expression 就会越来越复杂。
s-expression 只是用来辅助你快速定位到一个比较具体的Ast 节点 eslint 也有一个类似的库叫 esquery，你说的rename 这都需要建立程序的语义信息了吧 像什么 call-graph, reference graph，这都不是在 parse 阶段来做的吧。个人观点简单的仅仅从语法层面的重构 s-expression 来辅助 查询是很有帮助的，你说的那种比较复杂的重构在 和 parser 层面没有什么关系了。
嗯，这个重要是从整个功能来考虑，标题里的 “自动化重构” ，理论上那个 CodeQuery 也是成本高，就是忘了写了~。
简单来说，就是从目的来考虑，如果选择上要做重构，那么就不建议，这么 Ctags、TreeSitter 等。