英文:
How does the Go1 compiler work?
问题
我已经在学校项目中尝试使用Go语言大约一个月了，我注意到在src/pkg/go文件夹中有go/ast、go/token、go/parser等包。然而，gc编译器是基于src/cmd/gc中的C文件的。
我的问题是关于Go1中的新go命令，它用于构建和运行程序：这个工具是否依赖于我上面提到的包？也就是说，如果我在/go/token/token.go中添加了一个新的标记，新的go编译器会识别它吗？
英文:
I've been dabbling with Go for about a month for a school project and I noticed the go/ast, go/token, go/parser, etc. packages in the src/pkg/go folder. However, the gc compiler was based on C files located in src/cmd/gc.
My question regards the new go command in Go1 that builds and runs programs: does this tool depend on the packages I referenced above? i.e. if I added a new token to /go/token/token.go, would it be recognized by the new go compiler?
答案1
得分: 5
Go编译器是用纯C编写的，不使用go/下的包。在Go源代码树中，它的词法分析器位于src/cmd/gc/lex.c，Bison语法位于src/cmd/gc/go.y。
go/包在像godoc、gofmt和各种go工具子命令中使用。也许有一天它们也可以用来用Go编写Go编译器，但目前还没有人在这条路上取得很大进展。
英文:
The Go compiler is written in pure C and does not use the packages under go/. In the Go source tree, its lexer lives in src/cmd/gc/lex.c and its Bison grammar is src/cmd/gc/go.y.
The go/ packages are used in tools like godoc, gofmt, and various go tool subcommands. Maybe someday they can be used to write a Go compiler in Go as well, but no one's gotten very far on that path yet.
答案2
得分: 2
注意（2013年12月18日），计划将编译器从C移植到Go本身：
>“Go 1.3+编译器改进”（Russ Cox）
在这种情况下，像go/parser这样的包将会参与，并且“第5阶段”提到：
>用最新（也许是新的）版本的go/parser和go/types替换前端。Robert Griesemer曾经讨论过设计新的go/parser和go/types API的可能性，这是基于对当前API的经验（并且使用新的名称，以保持与Go 1的兼容性）。将它们与编译器后端连接的工作可能有助于指导新API的设计。
这可能是对语言稳定性的证明，因为之前在2012年6月提到的旧的“Go之旅”明确指出：
>Go不是用自身编写的，这使得进行重大语言更改变得容易得多。在最初发布之前，我们经历了一些全面的语法变革，我很高兴我们不必担心如何重新引导编译器或在这些变化期间确保某种向后兼容性。
当时提到的问题“有没有计划用Go引导Go，用Go编写Go编译器？”（再次是2012年6月）：
>目前没有立即的计划。Go附带了一个用Go编写的Go程序解析器，所以第一部分已经完成了，还有一个实验性的类型检查器正在开发中，但这些主要是用于编写程序分析工具。
>
>我过去曾经从事过引导语言的工作，我发现引导并不一定适用于经常变化的语言。这让我想起了攀登悬崖并不时在悬崖上螺丝钩上，以防你摔下来。
英文:
Note (December 18th, 2013), there are plans to move the compiler from C to Go itself:
> "Go 1.3+ Compiler Overhaul" (Russ Cox)
In that context packages like go/parser will be involved, and the "Phase 5" mentions:
> Replace the front end with the latest (perhaps new) versions of go/parser and go/types.
Robert Griesemer has discussed the possibility of designing new go/parser and go/types APIs at some point, based on experience with the current ones (and under new names, to preserve Go 1 compatibility).
The work of connecting them to a compiler back end may help guide design of new APIs.
This is probably a testimony on how stable the language has become, since the old "A Tour of Go" (June 2012) mentioned before clearly stated:
> The fact that Go wasn’t written in itself also made it much easier to make significant language changes.
Before the initial release we went through a handful of wholesale syntax upheavals, and I’m glad we didn’t have to worry about how we were going to rebootstrap the compiler or ensure some kind of backwards compatibility during those changes.
The question "Is there any plan to bootstrap Go in Go, to write the Go compiler in Go?" mentioned at the time (again, June 2012):
> There’s no immediate plan. Go does ship with a Go program parser written in Go, so the first piece is already done, and there’s an experimental type checker in the works, but those are mainly for writing program analysis tools.
>
> I’ve worked on bootstrapped languages in the past, and I found that bootstrapping is not necessarily a good fit for languages that are changing frequently. It reminded me of climbing a cliff and screwing hooks into the cliff once in a while to catch you if you fall.
答案3
得分: 1
这个工具是否依赖于我上面提到的包？
"go"工具确实依赖于那些包。
如果我在/go/token/token.go中添加了一个新的标记，新的go编译器会识别它吗？
不会。
英文:
does this tool depend on the packages I referenced above?
The 'go' tool does depend on those packages
if I added a new token to /go/token/token.go, would it be recognized by the new go compiler?
No.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论