代币是否应该成为 AST 节点的一部分

各位小伙伴们，大家好呀！看看今天我又给各位带来了什么文章？本文标题是《代币是否应该成为 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学习网公众号，给大家分享更多Golang知识！