登录
首页 >  Golang >  Go问答

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

来源:stackoverflow

时间:2024-04-27 18:48:47 219浏览 收藏

各位小伙伴们,大家好呀!看看今天我又给各位带来了什么文章?本文标题《代币是否应该成为 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知识!

声明:本文转载于:stackoverflow 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>