guoyaxiang / craftinginterpreters_zh Goto Github PK

你好，请问有意愿做一个类似于gitbook的在线网站显示这些翻译内容吗，感觉这样会比较方便阅读些。

munificent/craftinginterpreters#1114

中英对照的形式很好，有些中文没翻译到位的，可以直接查看英文，我本来也想翻译这篇文章，但是一直没有时间。如果需要人手，我可以帮忙翻译一些章节

如题，原仓库作者提供生成html的工具，可以很方面的生成静态页面网站。搭配 codespaces 开发 预览效果如下：

原翻译为：事实证明，相对那些解析器能够处理的严格语法来说，人类语言太混乱了；但对于编程语言中更简单的人工语法来说，人类语言却是完美的。
个人感觉应该翻译为：事实证明，对于那些语法严格的解析器来说，人类语言太混乱了，但是对于处理那些语法简单的编程语言来说，他们是再合适不过的了。

3.9.1 第一段里面， 8轨音乐这玩意是说的磁带...

在**大陆，通常“磁带”或者“录音带”一词都指紧凑音频盒带，因为它的应用非常广泛。在****，reel-to-reel tape被称为盘式录音带、紧凑音频盒带（Compact audio cassette）被称为卡式录音带、8轨软片（8-track cartridges)）被称为匣式录音带。

有中文的, 让我可以摆脱机翻, 很感谢你

eg:

After the parser produces the syntax tree, but before the interpreter starts executing it, we’ll do a single walk over the tree to resolve all of the variables it contains.
在解析器生成语法树之后，解释器执行语法树之前，我们会对语法树再进行一次遍历，以解析其中包含的变量。

parse一般指代对语法做解析，指通过token构建语法树的过程。而resolve指代的是类似“分析使用某物”的含义。

这里期待能用其他词汇替换一下，或者对于有歧义的位置对原有英文词汇予以保留。

（这种也算是中文的编译解释器相关内容的一个常见谬误了

这个语法实际上是有歧义的，我们在解析它时就会看到这一点。但现在这已经足够了。

## 5 . 2 Implementing Syntax Trees

> Finally, we get to write some code. That little expression grammar is our skeleton. Since the grammar is recursive—note how `grouping`, `unary`, and `binary` all refer back to `expression`—our data structure will form a tree. Since this structure represents the syntax of our language, it’s called a **syntax tree**.

最后，我们要写一些代码。这个小小的表达式语法就是我们的骨架。由于语法是递归的——请注意`grouping`, `unary`, 和 `binary` 都是指回`expression`的——我们的数据结构将形成一棵树。因为这个结构代表了我们语言的语法，所以叫做**语法树**[^9]。

5.2的小标题漏掉了

这个里面的 peek 函数的 ，
private char peek() {
if (isAtEnd()) return '\0';
return source.charAt(current);
}

应该是 if (isAtEnd()) return '\n' ; 吗？

Just like in jlox, it steps forward through the token stream. It asks the scanner for the next token and stores it for later use. Before doing that, t takes the old current token and stashes that in a previous field.That will come in handy later so that we can get at the lexeme after we match a token.

就像在jlox中一样，该函数向前通过标识流。它会向扫描器请求下一个词法标识，并将其存储起来以供后面使用。在此之前，它会获取旧的current标识，并将其存储中previous字段中。这在以后会派上用场，让我们可以在匹配到标识之后获得词素。

• 加粗部分修改并将其存储在previous字段中

此处的pdf似乎为半成品，期待完整版的pdf😋

26.垃圾回收 Garbage Collection 中的习题部分有一处翻译错误

原文的片段为：

three fields: type, isMarked, and next

译文对应的片段为：

三个字段：type，type和next

• 译文中的第二次出现的type应该改为isMarked，即：

三个字段：type，isMarked和next

我最近刚发现这本书，看了前边一部分觉得很不错，目前在github上看到您好像是唯一还在坚持翻译的人，我对编译器和语言也比较感兴趣，也曾参与过英文书籍的翻译，请问是否需要帮忙？

首先非常感谢作者的辛勤付出。让我等英语渣渣能比较便利的阅读这本书。
最近看到 15 章时发现图片无法显示。我看了下 markdown 中，使用了绝对路径。比如：
(D:\翻译学习\CraftingInterpreters\15.虚拟机\ast-16511998979731.png)
16章也是如此。
麻烦老兄修改一下。🙏
一键 replace 就好了。😄
如果需要的话我也可以提一个 pr.

#79

“Though the area explored by language designers is vast, the trails they’ve carved through it are few. Not every language takes the exact same path—some take a shortcut or two—but otherwise they are reassuringly similar from Rear Admiral Grace Hopper’s first COBOL compiler all the way to some hot new transpile-to-JavaScript language whose “documentation” consists entirely of a single poorly-edited README in a Git repository somewhere.”
尽管语言设计师所探索的领域辽阔，但他们所走过的路却很少。 并非每种语言都采用完全相同的路径（有些采用一种或两种捷径），但除此之外，从海军少将Grace Hopper的第一个COBOL编译器，一直到一些热门的新移植到JavaScript的语言，它们的 "文档 "完全是由Git仓库中一个编辑得很差的README组成的

原文中这段话主要是体现从古至今编程语言的变化相对较小，无论是古老的语言还是新兴语言，都采用了非常类似的结构。我建议这段修改为：
尽管语言设计师探索的领域辽阔，但是往往都走到相似的几条路上。虽然说并非所有语言都采用了相同的模式（有一些语言会采取一些捷径），但是无论是海军少将Grace Hopper的第一个COBOL语言还是近年来热门的JavaScript的语言（js的文档甚至完全是由git仓库中的一个编辑的很差的README组成的），都呈现出相似的特征，这十分令人欣慰。