当前位置： > > > > 代币是否应该成为 AST 节点的一部分
来源：stackoverflow
2024-04-27 18:48:47
0浏览
收藏
各位小伙伴们，大家好呀！看看今天我又给各位带来了什么文章？本文标题是《代币是否应该成为 AST 节点的一部分》，很明显是关于Golang的文章哈哈哈，其中内容主要会涉及到等等，如果能帮到你，觉得很不错的话，欢迎各位多多点评和分享！
问题内容
我问这个问题的一些背景。
我正在阅读《writing an interpreter in go》，在书中，token 结构位于 ast 节点内部。 node 是一种可以通过实现 tokenliteral() 和 string() 来实现的类型
type integerliteral struct {
token token.token
value int64
}
type node interface {
tokenliteral() string
string() string
}
我知道在现实生活中，编译器必须提供错误的行和列位置，而词法分析器无法检测到错误，因此必须将此信息传递给解析器。例如，go 编译器使用下面的 ast 节点。
type Pos int
// All node types implement the Node interface.
type Node interface {
Pos() token.Pos // position of first character belonging to the node
End() token.Pos // position of first character immediately after the node
}
我的问题的长版本
据我所知，编译前端的工作方式如下：chars -> 标记流 -> ast。在每个级别中，“一些事物”都是抽象的。在我看来， token 不应该是 ast node 的一部分
- 令牌是否应该是
ast node的一部分 - 您能否举例说明 pl 选择哪种方式
正确答案
AST 的确切本质是编译器（或解析库）的实现细节，不同的 AST 实现将具有不同的字段，甚至同一语言的不同 AST 实现也是如此。
几乎总是存在某种机制从 AST 节点提取源位置信息，包括错误消息和嵌入在编译输出中的调试信息。这可以通过向每个 AST 节点类型添加一个（或多个）位置对象来完成。或者，位置信息可以保存在可从 AST 节点以某种方式发现的令牌对象中。或者混合使用这些策略并提供 Location getter 方法。
我想不出一个好的理由来坚持或禁止 AST 中的令牌对象。引用单令牌文字或标识符的 AST 节点很可能保存在 Token 对象中。为什么不呢？
好了，本文到此结束，带大家了解了《代币是否应该成为 AST 节点的一部分》，希望本文对你有所帮助！关注公众号，给大家分享更多Golang知识！
