I. WELCOME

This may be the beginning of a grand adventure. Programming languages encompass a huge space to explore and play in. Plenty of room for your own creations to share with others or just enjoy yourself. Brilliant computer scientists and software engineers have spent entire careers traversing this land without ever reaching the end. If this book is your first entry into the country, welcome.

這也許是一場大冒險的開始。編程語言包含了一個巨大的探索和遊戲空間。在其中，你有足夠的空間與他人分享自己的創作，或者只是自娛自樂。傑出的計算機科學家和軟件工程師窮盡整個職業生涯都在穿越這片土地，卻從未到達終點。如果這是你第一次進入這個國度，歡迎你。

The pages of this book give you a guided tour through some of the world of languages. But before we strap on our hiking boots and venture out, we should familiarize ourselves with the territory. The chapters in this part introduce you to the basic concepts used by programming languages and how they are organized.

本書的內容為你提供了一些語言世界的導覽。但是，在我們穿上登山靴開始冒險之前，我們應該先熟悉一下這片土地。本部分的章節將向你介紹編程語言所使用的基本概念以及它們的組織方式。

We will also get acquainted with Lox, the language we’ll spend the rest of the book implementing (twice). Let’s go!

我們以後還會熟悉Lox，這門語言我們將用本書的其餘部分來實現（兩次）。讓我們開始吧!

1. 前言 Introduction

Fairy tales are more than true: not because they tell us that dragons exist, but because they tell us that dragons can be beaten.

​ —— Neil Gaiman, Coraline

童話故事是無比真實的：不是因為它告訴我們龍的存在，而是因為它告訴我們龍可以被擊敗。

I’m really excited we’re going on this journey together. This is a book on implementing interpreters for programming languages. It’s also a book on how to design a language worth implementing. It’s the book I wish I had when I first started getting into languages, and it’s the book I’ve been writing in my head for nearly a decade.

我真的很興奮我們能一起踏上這段旅程。這是一本關於為編程語言實現解釋器的書。它也是一本關於如何設計一種值得實現的語言的書。我剛開始接觸編程語言的時候就希望我可以寫出這本書，這本書我在腦子裡已經寫了將近十年了。

In these pages, we will walk step by step through two complete interpreters for a full-featured language. I assume this is your first foray into languages, so I’ll cover each concept and line of code you need to build a complete, usable, fast language implementation.

在本書中，我們將一步一步地介紹一種功能齊全的語言的兩個完整的解釋器實現。我假設這是您第一次涉足編程語言，因此我將介紹構建一個完整、可用、快速的語言所需的每個概念和代碼。

In order to cram two full implementations inside one book without it turning into a doorstop, this text is lighter on theory than others. As we build each piece of the system, I will introduce the history and concepts behind it. I’ll try to get you familiar with the lingo so that if you ever find yourself in a cocktail party full of PL (programming language) researchers, you’ll fit in.

為了在一本書中塞進兩個完整的實現，而且避免這變成一個門檻，本文在理論上比其他文章更輕。在構建系統的每個模塊時，我將介紹它背後的歷史和概念。我會盡力讓您熟悉這些行話，即便您在充滿PL（編程語言）研究人員的雞尾酒會中，也能快速融入其中。

But we’re mostly going to spend our brain juice getting the language up and running. This is not to say theory isn’t important. Being able to reason precisely and formally about syntax and semantics is a vital skill when working on a language. But, personally, I learn best by doing. It’s hard for me to wade through paragraphs full of abstract concepts and really absorb them. But if I’ve coded something, run it, and debugged it, then I get it.

但我們主要還是要花費精力讓這門語言運轉起來。這並不是說理論不重要。在學習一門語言時，能夠對語法和語義進行精確而公式化的推理¹是一項至關重要的技能。但是，就我個人而言，我在實踐中學習效果最好。對我來說，要深入閱讀那些充滿抽象概念的段落並真正理解它們太難了。但是，如果我（根據理論）編寫了代碼，運行並調試完成，那麼我就明白了。

That’s my goal for you. I want you to come away with a solid intuition of how a real language lives and breathes. My hope is that when you read other, more theoretical books later, the concepts there will firmly stick in your mind, adhered to this tangible substrate.

這就是我對您的期望。我想讓你們直觀地理解一門真正的語言是如何生活和呼吸的。我希望當你以後閱讀其他理論性更強的書籍時，這些概念會牢牢地留在你的腦海中，依附於這個有形的基礎之上。

1.1 Why Learn This Stuff？

1.1 為什麼要學習這些？

Every introduction to every compiler book seems to have this section. I don’t know what it is about programming languages that causes such existential doubt. I don’t think ornithology books worry about justifying their existence. They assume the reader loves birds and start teaching.

每本編譯器書籍的導言似乎都有這一部分。我不知道到底是編程語言的哪一點讓人產生這樣的質疑。我不認為鳥類學書籍會擔心如何證明自己的存在。它們假定讀者喜歡鳥類，然後開始教學。

But programming languages are a little different. I suppose it is true that the odds of any of us creating a broadly successful general-purpose programming language are slim. The designers of the world’s widely-used languages could fit in a Volkswagen bus, even without putting the pop-top camper up. If joining that elite group was the only reason to learn languages, it would be hard to justify. Fortunately, it isn’t.

但是編程語言有一點不同。我認為，對我們中的任何一個人來說，能夠創建一種廣泛成功的通用編程語言的可能性都很小，這是事實。設計這個世界上被廣泛使用的語言的設計師們，一輛大眾旅遊巴士就能裝得下，甚至不用把頂上的帳篷加上。如果加入這個精英群體是學習語言的唯一原因，那麼就很難證明其合理性。幸運的是，事實並非如此。

1.1.1 Little languages are everywhere

1.1.1 小型語言無處不在

For every successful general-purpose language, there are a thousand successful niche ones. We used to call them “little languages”, but inflation in the jargon economy led today to the name “domain-specific languages”. These are pidgins tailor-built to a specific task. Think application scripting languages, template engines, markup formats, and configuration files.

對於每一種成功的通用語言，都有上千種成功的小眾語言。我們過去稱它們為“小語言”，但術語氾濫的今天它們有了“領域特定語言（即DSL）”的名稱。這些是為特定任務量身定做的洋涇浜語言²，如應用程序腳本語言、模板引擎、標記格式和配置文件。

Almost every large software project needs a handful of these. When you can, it’s good to reuse an existing one instead of rolling your own. Once you factor in documentation, debuggers, editor support, syntax highlighting, and all of the other trappings, doing it yourself becomes a tall order.

幾乎每個大型軟件項目都需要一些這樣的工具。如果可以的話，最好重用現有的工具，而不是自己動手實現。一旦考慮到文檔、調試器、編輯器支持、語法高亮顯示和所有其他可能的障礙，自己實現就成了一項艱鉅的任務。

But there’s still a good chance you’ll find yourself needing to whip up a parser or something when there isn’t an existing library that fits your needs. Even when you are reusing some existing implementation, you’ll inevitably end up needing to debug and maintain it and poke around in its guts.

但是，當現有的庫不能滿足您的需要時，您仍然很有可能發現自己需要一個解析器或其他東西。即使當您重用一些現有的實現時，您也不可避免地需要調試和維護，並在其內部進行探索。

1 . 1 . 2 Languages are great exercise

1.1.2 語言是很好的鍛鍊

Long distance runners sometimes train with weights strapped to their ankles or at high altitudes where the atmosphere is thin. When they later unburden themselves, the new relative ease of light limbs and oxygen-rich air enables them to run farther and faster.

長跑運動員有時會在腳踝上綁上重物，或者在空氣稀薄的高海拔地區進行訓練。當他們卸下自己的負擔以後，輕便的肢體和富氧的空氣帶來了新的相對舒適度，使它們可以跑得更遠，更快。

Implementing a language is a real test of programming skill. The code is complex and performance critical. You must master recursion, dynamic arrays, trees, graphs, and hash tables. You probably use hash tables at least in your day-to-day programming, but how well do you really understand them? Well, after we’ve crafted our own from scratch, I guarantee you will.

實現一門語言是對編程技能的真正考驗。代碼很複雜，而且性能很關鍵。您必須掌握遞歸、動態數組、樹、圖和哈希表。您在日常編程中至少使用過哈希表，但到底您對它們的理解程度有多高呢？嗯，等我們從頭完成我們的作品之後，我相信您會理解的。

While I intend to show you that an interpreter isn’t as daunting as you might believe, implementing one well is still a challenge. Rise to it, and you’ll come away a stronger programmer, and smarter about how you use data structures and algorithms in your day job.

雖然我想說明解釋器並不像您想的那樣令人生畏，但實現一個好的解釋器仍然是一個挑戰。學會了它，您就會成為一個更強大的程序員，並且在日常工作中也能更加聰明地使用數據結構和算法。

1 . 1 . 3 One more reason

1.1.3 另一個原因

This last reason is hard for me to admit, because it’s so close to my heart. Ever since I learned to program as a kid, I felt there was something magical about languages. When I first tapped out BASIC programs one key at a time I couldn’t conceive how BASIC itself was made.

這最後一個原因我很難承認，因為它是很私密的理由。自從我小時候學會編程以來，我就覺得語言有種神奇的力量。當我第一次一個鍵一個鍵地輸入BASIC程序時，我無法想象BASIC語言本身是如何製作出來的。

Later, the mixture of awe and terror on my college friends’ faces when talking about their compilers class was enough to convince me language hackers were a different breed of human—some sort of wizards granted privileged access to arcane arts.

後來，當我的大學朋友們談論他們的編譯器課程時，臉上那種既敬畏又恐懼的表情足以讓我相信，語言黑客是另一種人，某種可以操控奧術的巫師。

It’s a charming image, but it has a darker side. I didn’t feel like a wizard, so I was left thinking I lacked some in-born quality necessary to join the cabal. Though I’ve been fascinated by languages ever since I doodled made up keywords in my school notebook, it took me decades to muster the courage to try to really learn them. That “magical” quality, that sense of exclusivity, excluded me.

這是一個迷人的形象，但它也有黑暗的一面。我感覺自己不像個巫師，所以我認為自己缺乏加入秘社所需的先天品質。 儘管自從我在學校筆記本上拼寫關鍵詞以來，我一直對語言著迷，但我花了數十年的時間鼓起勇氣嘗試真正地學習它們。那種“神奇”的品質，那種排他性的感覺，將我擋在門外。

When I did finally start cobbling together my own little interpreters, I quickly learned that, of course, there is no magic at all. It’s just code, and the people who hack on languages are just people.

當我最終開始拼湊我自己的小解釋器時，我很快意識到，根本就沒有魔法。它只是代碼，而那些玩弄語言的人也只是普通人。

There are a few techniques you don’t often encounter outside of languages, and some parts are a little difficult. But not more difficult than other obstacles you’ve overcome. My hope is that if you’ve felt intimidated by languages, and this book helps you overcome that fear, maybe I’ll leave you just a tiny bit braver than you were before.

有一些技巧您在語言之外不會經常遇到，而且有些部分有點難。但不會比您克服的其他障礙更困難。我希望，如果您對語言感到害怕，而這本書能幫助您克服這種恐懼，也許我會讓您比以前更勇敢一點。

And, who knows, maybe you will make the next great language. Someone has to.

而且，說不準，你也許會創造出下一個偉大的語言，畢竟總要有人做。

1 . 2 How the Book is Organized

1.2 本書的組織方式

This book is broken into three parts. You’re reading the first one now. It’s a couple of chapters to get you oriented, teach you some of the lingo that language hackers use, and introduce you to Lox, the language we’ll be implementing.

這本書分為三個部分。您現在正在讀的是第一部分。這部分用了幾章來讓您進入狀態，教您一些語言黑客使用的行話，並向您介紹我們將要實現的語言Lox。

Each of the other two parts builds one complete Lox interpreter. Within those parts, each chapter is structured the same way. The chapter takes a single language feature, teaches you the concepts behind it, and walks through an implementation.

其他兩個部分則分別構建一個完整的Lox解釋器。在這些部分中，每個章節的結構都是相同的。 每一章節挑選一個語言功能點，教您背後對應的概念，並逐步介紹實現方法。

It took a good bit of trial and error on my part, but I managed to carve up the two interpreters into chapter-sized chunks that build on the previous chapters but require nothing from later ones. From the very first chapter, you’ll have a working program you can run and play with. With each passing chapter, it grows increasingly full-featured until you eventually have a complete language.

我花了不少時間去試錯，但我還是成功地把這兩個解釋器按照章節分成了一些小塊，每一小塊的內容都會建立在前面幾章的基礎上，但不需要後續章節的知識。從第一章開始，你就會有一個可以運行和使用的工作程序。隨著章節的推移，它的功能越來越豐富，直到你最終擁有一門完整的語言。

Aside from copious, scintillating English prose, chapters have a few other delightful facets:

除了大量妙趣橫生的英文段落，章節中還會包含一些其它的驚喜：

1.2.1 The code

1.2.1 代碼

We’re about crafting interpreters, so this book contains real code. Every single line of code needed is included, and each snippet tells you where to insert it in your ever-growing implementation.

本書是關於製作解釋器的，所以其中會包含真正的代碼。所需要的每一行代碼都需要包含在內，而且每個代碼片段都會告知您需要插入到實現代碼中的什麼位置。

Many other language books and language implementations use tools like Lex and Yacc, so-called compiler-compilers that automatically generate some of the source files for an implementation from some higher level description. There are pros and cons to tools like those, and strong opinions—some might say religious convictions—on both sides.

許多其他的語言書籍和語言實現都使用Lex和Yacc³這樣的工具，也就是所謂的編譯器-編譯器，可以從一些更高層次的（語法）描述中自動生成一些實現的源文件。這些工具有利有弊，而且雙方都有強烈的主張--有些人可能將其說成是信仰。

We will abstain from using them here. I want to ensure there are no dark corners where magic and confusion can hide, so we’ll write everything by hand. As you’ll see, it’s not as bad as it sounds and it means you really will understand each line of code and how both interpreters work.

我們這裡不會使用這些工具。我想確保魔法和困惑不會藏在黑暗的角落，所以我們會選擇手寫所有代碼。正如您將看到的，這並沒有聽起來那麼糟糕，因為這意味著您將真正理解每一行代碼以及兩種解釋器的工作方式。

A book has different constraints from the “real world” and so the coding style here might not always reflect the best way to write maintainable production software. If I seem a little cavalier about, say, omitting private or declaring a global variable, understand I do so to keep the code easier on your eyes. The pages here aren’t as wide as your IDE and every character counts.

為了寫書，書中代碼和“真實世界”的代碼是有區別的，因此這裡的代碼風格可能並不是編寫可維護的生產型軟件的最佳方式。可能我的某些寫法是不太準確的，比如省略private或者聲明全局變量，請理解我這樣做是為了讓您更容易看懂代碼。書頁不像IDE窗口那麼寬，所以每一個字符都很珍貴。

Also, the code doesn’t have many comments. That’s because each handful of lines is surrounded by several paragraphs of honest-to-God prose explaining it. When you write a book to accompany your program, you are welcome to omit comments too. Otherwise, you should probably use // a little more than I do.

另外，代碼也不會有太多的註釋。這是因為每一部分代碼前後，都使用了一些真的很簡潔的文字來對其進行解釋。當你寫一本書來配合你的程序時，歡迎你也省略註釋。否則，你可能應該比我使用更多的 //。

While the book contains every line of code and teaches what each means, it does not describe the machinery needed to compile and run the interpreter. I assume you can slap together a makefile or a project in your IDE of choice in order to get the code to run. Those kinds of instructions get out of date quickly, and I want this book to age like XO brandy, not backyard hooch.

雖然這本書包含了每一行代碼，並教授了每一行代碼的含義，但它沒有描述編譯和運行解釋器所需的機制。我假設你可以簡單地拼湊出一個makefile，或者創建一個心儀的IDE中的一個工程，來讓代碼運行起來。 那種類型的說明很快就會過時，我希望這本書能像XO白蘭地一樣醇久，而不是像家釀酒（一樣易過期）。

1.2.2 Snippets

1.2.2 片段

Since the book contains literally every line of code needed for the implementations, the snippets are quite precise. Also, because I try to keep the program in a runnable state even when major features are missing, sometimes we add temporary code that gets replaced in later snippets.

因為這本書包含了實現所需的每一行代碼，所以代碼片段相當精確。此外，即使是在缺少主要功能的時候，我也嘗試將程序保持在可運行狀態。因此我們有時會添加臨時代碼，這些代碼將在後面被其他的代碼片段替換。

A snippet with all the bells and whistles looks like this:

一個完整的代碼片段可能如下所示：

In the center, you have the new code to add. It may have a few faded out lines above or below to show where it goes in the existing surrounding code. There is also a little blurb telling you in which file and where to place the snippet. If that blurb says “replace _ lines”, there is some existing code between the faded lines that you need to remove and replace with the new snippet.

中間是要添加的新代碼。這部分代碼的上面或下面可能有一些淡出的行，以顯示它在周圍代碼中的位置。還會附有一小段介紹，告訴您在哪個文件中以及在哪裡放置代碼片段。如果簡介說要“replace _ lines”，表明在淺色的行之間有一些現有的代碼需要刪除，並替換為新的代碼片段。

1.2.3 Asides

1.2.3 題外話

Asides contain biographical sketches, historical background, references to related topics, and suggestions of other areas to explore. There’s nothing that you need to know in them to understand later parts of the book, so you can skip them if you want. I won’t judge you, but I might be a little sad.

題外話中包含傳記簡介、歷史背景、對相關主題的引用以及對其他要探索的領域的建議。 您無需深入瞭解就可以理解本書的後續部分，因此可以根據需要跳過它們。 我不會批評你，但我可能會有些難過。【注：由於排版原因，在翻譯的時候，將有用的旁白信息作為腳註附在章節之後】

1.2.4 Challenge

1.2.4 挑戰

Each chapter ends with a few exercises. Unlike textbook problem sets which tend to review material you already covered, these are to help you learn more than what’s in the chapter. They force you to step off the guided path and explore on your own. They will make you research other languages, figure out how to implement features, or otherwise get you out of your comfort zone.

每章結尾都會有一些練習題。 不像教科書中的習題集那樣用於回顧已講述的內容，這些習題是為了幫助您學習更多的知識，而不僅僅是本章中的內容。 它們會迫使您走出文章指出的路線，自行探索。 它們將要求您研究其他語言，弄清楚如何實現功能，換句話說，就是使您走出舒適區。

Vanquish the challenges and you’ll come away with a broader understanding and possibly a few bumps and scrapes. Or skip them if you want to stay inside the comfy confines of the tour bus. It’s your book.

克服挑戰，您將獲得更廣泛的理解，也可能遇到一些挫折。 如果您想留在旅遊巴士的舒適區內，也可以跳過它們。 都隨你便⁴。

1.2.5 Design notes

1.2.5 設計筆記

Most “programming language” books are strictly programming language implementation books. They rarely discuss how one might happen to design the language being implemented. Implementation is fun because it is so precisely defined. We programmers seem to have an affinity for things that are black and white, ones and zeroes.

大多數編程語言書籍都是嚴格意義上的編程語言實現書籍。他們很少討論如何設計正在實現的語言。實現之所以有趣，是因為它的定義是很精確的。我們程序員似乎很喜歡黑白、1和0這樣的事物⁵。

Personally, I think the world only needs so many implementations of FORTRAN 77. At some point, you find yourself designing a new language. Once you start playing that game, then the softer, human side of the equation becomes paramount. Things like what features are easy to learn, how to balance innovation and familiarity, what syntax is more readable and to whom.

就個人而言，我認為世界只需要這麼多的FORTRAN 77實現。在某個時候，您會發現自己正在設計一種新的語言。 一旦開始這樣做，方程式中較柔和，人性化的一面就變得至關重要。 諸如哪些功能易於學習，如何在創新和熟悉度之間取得平衡，哪種語法更易讀以及對誰有幫助⁶。

All of that stuff profoundly affects the success of your new language. I want your language to succeed, so in some chapters I end with a “design note”, a little essay on some corner of the human aspect of programming languages. I’m no expert on this—I don’t know if anyone really is—so take these with a large pinch of salt. That should make them tastier food for thought, which is my main aim.

所有這些都會對您的新語言的成功產生深遠的影響。 我希望您的語言取得成功，因此在某些章節中，我以一篇“設計筆記”結尾，這些是關於編程語言的人文方面的一些文章。我並不是這方面的專家——我不確定是否有人真的精通這些，因此，請您在閱讀這些文字的時候仔細評估。這樣的話，這些文字就能成為您思考的食材，這也正是我的目標。

1 . 3 The First Interpreter

1.3 第一個解釋器

We’ll write our first interpreter, jlox, in Java. The focus is on concepts. We’ll write the simplest, cleanest code we can to correctly implement the semantics of the language. This will get us comfortable with the basic techniques and also hone our understanding of exactly how the language is supposed to behave.

我們將用Java編寫第一個解釋器jlox。（這裡的）主要關注點是概念。 我們將編寫最簡單，最乾淨的代碼，以正確實現該語言的語義。 這樣能夠幫助我們熟悉基本技術，並磨練對語言表現形式的確切理解。

Java is a great language for this. It’s high level enough that we don’t get overwhelmed by fiddly implementation details, but it’s still pretty explicit. Unlike scripting languages, there tends to be less complex machinery hiding under the hood, and you’ve got static types to see what data structures you’re working with.

Java是一門很適合這種場景的語言。它的級別足夠高，我們不會被繁瑣的實現細節淹沒，但代碼仍是非常明確的。與腳本語言不同的是，它的底層沒有隱藏太過複雜的機制，你可以使用靜態類型來查看正在處理的數據結構。

I also chose Java specifically because it is an object-oriented language. That paradigm swept the programming world in the 90s and is now the dominant way of thinking for millions of programmers. Odds are good you’re already used to organizing code into classes and methods, so we’ll keep you in that comfort zone.

我選擇Java還有特別的原因，就是因為它是一種面向對象的語言。 這種範式在90年代席捲了整個編程世界，如今已成為數百萬程序員的主流思維方式。 很有可能您已經習慣了將代碼組織到類和方法中，因此我們將讓您在舒適的環境中學習。

While academic language folks sometimes look down on object-oriented languages, the reality is that they are widely used even for language work. GCC and LLVM are written in C++, as are most JavaScript virtual machines. Object-oriented languages are ubiquitous and the tools and compilers for a language are often written in the same language.

雖然學術語言專家有時瞧不起面嚮對象語言，但事實上，它們即使在語言工作中也被廣泛使用。GCC和LLVM是用C++編寫的，大多數JavaScript虛擬機也是這樣。 面向對象的語言無處不在，並且針對該語言的工具和編譯器通常是用同一種語言編寫的⁷。

And, finally, Java is hugely popular. That means there’s a good chance you already know it, so there’s less for you to learn to get going in the book. If you aren’t that familiar with Java, don’t freak out. I try to stick to a fairly minimal subset of it. I use the diamond operator from Java 7 to make things a little more terse, but that’s about it as far as “advanced” features go. If you know another object-oriented language like C# or C++, you can muddle through.

最後，Java非常流行。 這意味著您很有可能已經瞭解它了，所以你要學習的東西就更少了。 如果您不太熟悉Java，也請不要擔心。 我儘量只使用它的最小子集。我使用Java 7中的菱形運算符使代碼看起來更簡潔，但就“高級”功能而言，僅此而已。 如果您瞭解其它面向對象的語言（例如C＃或C++），就沒有問題。

By the end of part II, we’ll have a simple, readable implementation. What we won’t have is a fast one. It also takes advantage of the Java virtual machine’s own runtime facilities. We want to learn how Java itself implements those things.

在第二部分結束時，我們將得到一個簡單易讀的實現。 但是我們得到的不會是一個執行效率高的解釋器。它還是利用了Java虛擬機自身的運行時工具。我們想要學習Java本身是如何實現這些東西的。

1 . 4 The Second Interpreter

1.4 第二個解釋器

So in the next part, we start all over again, but this time in C. C is the perfect language for understanding how an implementation really works, all the way down to the bytes in memory and the code flowing through the CPU.

所以在下一部分，我們將從頭開始，但這一次是用C語言。C語言是理解實現編譯器工作方式的完美語言，一直到內存中的字節和流經CPU的代碼。

A big reason that we’re using C is so I can show you things C is particularly good at, but that does mean you’ll need to be pretty comfortable with it. You don’t have to be the reincarnation of Dennis Ritchie, but you shouldn’t be spooked by pointers either.

我們使用C語言的一個重要原因是，我可以向您展示C語言特別擅長的東西，但這並不意味著您需要非常熟練地使用它。您不必是丹尼斯·裡奇（Dennis Ritchie）的轉世，但也不應被指針嚇倒。

If you aren’t there yet, pick up an introductory book on C and chew through it, then come back here when you’re done. In return, you’ll come away from this book an even stronger C programmer. That’s useful given how many language implementations are written in C: Lua, CPython, and Ruby’s MRI, to name a few.

如果你（對C的掌握）還沒到那一步，找一本關於C的入門書，仔細閱讀，讀完後再回來。作為回報，從這本書中你將成為一個更優秀的C程序員。可以想想有多少語言實現是用C完成的: Lua、CPython和Ruby 的 MRI等，這裡僅舉幾例。

In our C interpreter, clox, we are forced to implement for ourselves all the things Java gave us for free. We’ll write our own dynamic array and hash table. We’ll decide how objects are represented in memory, and build a garbage collector to reclaim it.

在我們的C解釋器clox中⁸，我們不得不自己實現那些Java免費提供給我們的東西。 我們將編寫自己的動態數組和哈希表。 我們將決定對象在內存中的表示方式，並構建一個垃圾回收器來回收它。

Our Java implementation was focused on being correct. Now that we have that down, we’ll turn to also being fast. Our C interpreter will contain a compiler that translates Lox to an efficient bytecode representation (don’t worry, I’ll get into what that means soon) which it then executes. This is the same technique used by implementations of Lua, Python, Ruby, PHP, and many other successful languages.

我們的Java版實現專注於正確性。 既然我們已經完成了，那麼我們就要變快。 我們的C解釋器將包含一個編譯器⁹，該編譯器會將Lox轉換為有效的字節碼形式（不用擔心，我很快就會講解這是什麼意思）之後它會執行對應的字節碼。 這與Lua，Python，Ruby，PHP和許多其它成功語言的實現所使用的技術相同。

We’ll even try our hand at benchmarking and optimization. By the end, we’ll have a robust, accurate, fast interpreter for our language, able to keep up with other professional caliber implementations out there. Not bad for one book and a few thousand lines of code.

我們甚至會嘗試進行基準測試和優化。 到最後，我們將為lox語言提供一個強大，準確，快速的解釋器，並能夠不落後於其他專業水平的實現。對於一本書和幾千行代碼來說已經不錯了。

CHALLENGES

習題

1、There are at least six domain-specific languages used in the little system I cobbled together to write and publish this book. What are they?

在我編寫的這個小系統中，至少有六種特定領域語言（DSL），它們是什麼？

2、Get a “Hello, world!” program written and running in Java. Set up whatever Makefiles or IDE projects you need to get it working. If you have a debugger, get comfortable with it and step through your program as it runs.

使用Java編寫並運行一個“Hello, world!”程序，配置一個你需要的makefile或IDE項目讓它跑起來。如果您有調試器，請先熟悉一下，並在程序運行時對代碼逐步調試。

3、Do the same thing for C. To get some practice with pointers, define a doubly-linked list of heap-allocated strings. Write functions to insert, find, and delete items from it. Test them.

對C也進行同樣的操作。為了練習使用指針，可以定義一個堆分配字符串的雙向鏈表。編寫函數以插入，查找和刪除其中的項目。 測試編寫的函數。

DESIGN NOTE: WHAT’S IN A NAME?

設計筆記：名稱是什麼？

One of the hardest challenges in writing this book was coming up with a name for the language it implements. I went through pages of candidates before I found one that worked. As you’ll discover on the first day you start building your own language, naming is deviously hard. A good name satisfies a few criteria:

1. It isn’t in use. You can run into all sorts of trouble, legal and social, if you inadvertently step on someone else’s name.
2. It’s easy to pronounce. If things go well, hordes of people will be saying and writing your language’s name. Anything longer than a couple of syllables or a handful of letters will annoy them to no end.
3. It’s distinct enough to search for. People will Google your language’s name to learn about it, so you want a word that’s rare enough that most results point to your docs. Though, with the amount of AI search engines are packing today, that’s less of an issue. Still, you won’t be doing your users any favors if you name your language “for”.
4. It doesn’t have negative connotations across a number of cultures. This is hard to guard for, but it’s worth considering. The designer of Nimrod ended up renaming his language to “Nim” because too many people only remember that Bugs Bunny used “Nimrod” (ironically, actually) as an insult.

If your potential name makes it through that gauntlet, keep it. Don’t get hung up on trying to find an appellation that captures the quintessence of your language. If the names of the world’s other successful languages teach us anything, it’s that the name doesn’t matter much. All you need is a reasonably unique token.

寫這本書最困難的挑戰之一是為它所實現的語言取個名字。我翻了好幾頁的備選名才找到一個合適的。當你某一天開始構建自己的語言時，你就會發現命名是非常困難的。一個好名字要滿足幾個標準：

1. 尚未使用。如果您不小心使用了別人的名字，就可能會遇到各種法律和社會上的麻煩。
2. 容易發音。如果一切順利，將會有很多人會說和寫您的語言名稱。 超過幾個音節或幾個字母的任何內容都會使他們陷入無休止的煩惱。
3. 足夠獨特，易於搜索。人們會Google你的語言的名字來瞭解它，所以你需要一個足夠獨特的單詞，以便大多數搜索結果都會指向你的文檔。不過，隨著人工智能搜索引擎數量的增加，這已經不是什麼大問題了。但是，如果您將語言命名為“ for”，那對用戶基本不會有任何幫助。
4. 在多種文化中，都沒有負面的含義。這很難防範，但是值得深思。Nimrod的設計師最終將其語言重命名為“ Nim”，因為太多的人只記得Bugs Bunny使用“ Nimrod”作為一種侮辱（其實是諷刺）。

如果你潛在的名字通過了考驗，就保留它吧。不要糾結於尋找一個能夠抓住你語言精髓的名稱。如果說世界上其他成功的語言的名字教會了我們什麼的話，那就是名字並不重要。您所需要的只是一個相當獨特的標記。

1. 靜態類型系統尤其需要嚴格的形式推理。破解類型系統就像證明數學定理一樣。事實證明這並非巧合。 上世紀初，Haskell Curry和William Alvin Howard證明瞭它們是同一枚硬幣的兩個方面：Curry-Howard同構。 ↩

2. pidgins，洋涇浜語言，一種混雜的英語 ↩

3. Yacc是一個工具，它接收語法文件並生成編譯器的源文件，因此它有點像一個輸出“編譯器”的編譯器，在術語中叫作“compiler-compiler”，即編譯器的編譯器。Yacc並不是同類工具中的第一個，這就是為什麼它被命名為“Yacc”—Yet Another Compiler-Compiler(另一個Compiler-Compiler)。後來還有一個類似的工具是Bison，它的名字源於Yacc和yak的發音，是一個雙關語。 ↩

4. 警告:挑戰題目通常要求您對正在構建的解釋器進行更改。您需要在代碼副本中實現這些功能。後面的章節都假設你的解釋器處於原始(未解決挑戰題)狀態。 ↩

5. 我知道很多語言黑客的職業就基於此。您將一份語言規範塞到他們的門下，等上幾個月，代碼和基準測試結果就出來了。 ↩

6. 希望您的新語言不會將對打孔卡寬度的假設硬編碼到語法中。 ↩

7. 編譯器以一種語言讀取文件。 翻譯它們，並以另一種語言輸出文件。 您可以使用任何一種語言（包括與目標語言相同的語言）來實現編譯器，該過程稱為“自舉”。你現在還不能使用編譯器本身來編譯你自己的編譯器，但是如果你用其它語言為你的語言寫了一個編譯器，你就可以用那個編譯器編譯一次你的編譯器。現在，您可以使用自己的編譯器的已編譯版本來編譯自身的未來版本，並且可以從另一個編譯器中丟棄最初的已編譯版本。 這就是所謂的“自舉”，通過自己的引導程序將自己拉起來。 ↩

8. 我把這個名字讀作“sea-locks”，但是你也可以讀作“clocks”，如果你願意的話可以像希臘人讀“x”那樣將其讀作“clochs”， ↩

9. 你以為這只是一本講解釋器的書嗎?它也是一本講編譯器的書。買一送一。 ↩

2.領土地圖 A Map of the Territory

You must have a map, no matter how rough. Otherwise you wander all over the place. In “The Lord of the Rings” I never made anyone go farther than he could on a given day.

​ ——J.R.R. Tolkien

你必須要有一張地圖，無論它是多麼粗糙。否則你就會到處亂逛。在《指環王》中，我從未讓任何人在某一天走得超出他力所能及的範圍。

We don’t want to wander all over the place, so before we set off, let’s scan the territory charted by previous language implementers. It will help us understand where we are going and alternate routes others take.

我們不想到處亂逛，所以在我們開始之前，讓我們先瀏覽一下以前的語言實現者所繪製的領土。它能幫助我們瞭解我們的目的地和其他人採用的備選路線。

First, let me establish a shorthand. Much of this book is about a language’s implementation, which is distinct from the language itself in some sort of Platonic ideal form. Things like “stack”, “bytecode”, and “recursive descent”, are nuts and bolts one particular implementation might use. From the user’s perspective, as long as the resulting contraption faithfully follows the language’s specification, it’s all implementation detail.

首先，我先做個簡單說明。本書的大部分內容都是關於語言的實現，它與語言本身這種柏拉圖式的理想形式有所不同。諸如“堆疊”，“位元組碼”和“遞迴下降”之類的東西是某個特定實現中可能使用的基本要素。從使用者的角度來說，只要最終產生的裝置能夠忠實地遵循語言規範，這些都是東西不過是他們不關心的實現細節罷了。

We’re going to spend a lot of time on those details, so if I have to write “language implementation” every single time I mention them, I’ll wear my fingers off. Instead, I’ll use “language” to refer to either a language or an implementation of it, or both, unless the distinction matters.

我們將會花很多時間在這些細節上，所以如果我每次提及的時候都寫“語言實現”，我的手指都會被磨掉。相反，除非有重要的區別，否則我將使用“語言”來指代一種語言或該語言的一種實現，或兩者皆有。

2 . 1 The Parts of a Language

2.1 語言的各部分

Engineers have been building programming languages since the Dark Ages of computing. As soon as we could talk to computers, we discovered doing so was too hard, and we enlisted their help. I find it fascinating that even though today’s machines are literally a million times faster and have orders of magnitude more storage, the way we build programming languages is virtually unchanged.

自計算機的黑暗時代以來，工程師們就一直在構建程式語言。當我們可以和計算機對話的時候，我們發現這樣做太難了，於是我們尋求電腦的幫助。我覺得很有趣的是，即使今天的機器確實快了一百萬倍，儲存空間也大了幾個數量級，但我們構建程式語言的方式幾乎沒有改變。

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的語言（JS的 "文件 "甚至完全是由Git倉庫中一個編輯得很差的README組成的¹），都呈現出相似的特徵，這令人十分欣慰。

I visualize the network of paths an implementation may choose as climbing a mountain. You start off at the bottom with the program as raw source text, literally just a string of characters. Each phase analyzes the program and transforms it to some higher-level representation where the semantics—what the author wants the computer to do—becomes more apparent.

我把一個語言實現可能選擇的路徑網路類比為爬山。你從最底層開始，程式是原始的源文字，實際上只是一串字元。每個階段都會對程式進行分析，並將其轉換為更高層次的表現形式，從而使語義（作者希望計算機做什麼）變得更加明顯。

Eventually we reach the peak. We have a bird’s-eye view of the users’s program and can see what their code means. We begin our descent down the other side of the mountain. We transform this highest-level representation down to successively lower-level forms to get closer and closer to something we know how to make the CPU actually execute.

最終我們達到了峰頂。我們可以鳥瞰使用者的程式，可以看到他們的程式碼含義是什麼。我們開始從山的另一邊下山。我們將這個最高階的表示形式轉化為連續的較低階別的形式，從而越來越接近我們所知道的如何讓CPU真正執行的形式。

Let’s trace through each of those trails and points of interest. Our journey begins on the left with the bare text of the user’s source code:

讓我們追隨著這一條條路徑和點前進吧。我們的旅程從左邊的使用者原始碼的純文字開始：

2.1.1 Scanning

2.1.1 掃描

The first step is scanning, also known as lexing, or (if you’re trying to impress someone) lexical analysis. They all mean pretty much the same thing. I like “lexing” because it sounds like something an evil supervillain would do, but I’ll use “scanning” because it seems to be marginally more commonplace.

第一步是掃描，也就是所謂的詞法分析 ( lexing 或者強調寫法 lexical analysis )。掃描和詞法分析的意思相近。我喜歡詞法分析這個描述，因為這聽起來像是一個邪惡的超級大壞蛋會做的事情，但我還是用掃描，因為它似乎更常見一些。

A scanner (or lexer) takes in the linear stream of characters and chunks them together into a series of something more akin to “words”. In programming languages, each of these words is called a token. Some tokens are single characters, like ( and ,. Others may be several characters long, like numbers (123), string literals ("hi!"), and identifiers (min).

掃描器(或詞法解析器)接收線性字元流，並將它們切分成一系列更類似於“單詞”的東西。在程式語言中，這些詞的每一個都被稱為詞法單元。有些詞法單元是單個字元，比如(和 ,。其他的可能是幾個字元長的，比如數字（123）、字串字元（"hi!"）和識別符號（min）。

Some characters in a source file don’t actually mean anything. Whitespace is often insignificant and comments, by definition, are ignored by the language. The scanner usually discards these, leaving a clean sequence of meaningful tokens.

原始檔中的一些字元實際上沒有任何意義。空格通常是無關緊要的，而註釋，從定義就能看出來，會被變成語言忽略。掃描器通常會丟棄這些字元，留下一個乾淨的有意義的詞法單元序列。

2.1.2 Parsing

2.1.2 語法分析

The next step is parsing. This is where our syntax gets a grammar—the ability to compose larger expressions and statements out of smaller parts. Did you ever diagram sentences in English class? If so, you’ve done what a parser does, except that English has thousands and thousands of “keywords” and an overflowing cornucopia of ambiguity. Programming languages are much simpler.

下一步是解析。 這就是我們從句法中得到語法的地方——語法能夠將較小的部分組成較大的表示式和語句。你在英語課上做過語法圖解嗎？如果有，你就做了解析器所做的事情，區別在於，英語中有成千上萬的“關鍵字”和大量的歧義，而程式語言要簡單得多。

A parser takes the flat sequence of tokens and builds a tree structure that mirrors the nested nature of the grammar. These trees have a couple of different names—“parse tree” or “abstract syntax tree”—depending on how close to the bare syntactic structure of the source language they are. In practice, language hackers usually call them “syntax trees”, “ASTs”, or often just “trees”.

解析器將扁平的詞法單元序列轉化為樹形結構，樹形結構能更好地反映語法的巢狀本質。這些樹有兩個不同的名稱:解析樹或抽象語法樹，這取決於它們與源語言的語法結構有多接近。在實踐中，語言駭客通常稱它們為“語法樹”、“AST”，或者乾脆直接說“樹”。

Parsing has a long, rich history in computer science that is closely tied to the artificial intelligence community. Many of the techniques used today to parse programming languages were originally conceived to parse human languages by AI researchers who were trying to get computers to talk to us.

解析在電腦科學中有著悠久而豐富的歷史，它與人工智慧界有著密切的聯絡。今天用於解析程式語言的許多技術最初被人工智慧研究人員用於解析人類語言，人工智慧研究人員試圖透過這些技術讓計算機能與我們對話。

It turns out human languages are too messy for the rigid grammars those parsers could handle, but they were a perfect fit for the simpler artificial grammars of programming languages. Alas, we flawed humans still manage to use those simple grammars incorrectly, so the parser’s job also includes letting us know when we do by reporting syntax errors.

事實證明，人類語言對於只能處理僵化語法的解析器來說太混亂了，但面對程式語言這種簡單的人造語法時，解析器表現得十分合適。唉，可惜我們這些有缺陷的人類在使用這些簡單的語法時，仍然會不停地出錯，因此解析器的工作還包括透過報告語法錯誤讓我們知道出錯了。

2 . 1 . 3 Static analysis

2.1.3 靜態分析

The first two stages are pretty similar across all implementations. Now, the individual characteristics of each language start coming into play. At this point, we know the syntactic structure of the code—things like which expressions are nested in which others—but we don’t know much more than that.

在所有實現中，前兩個階段都非常相似。 現在，每種語言的個性化特徵開始發揮作用。 至此，我們知道了程式碼的語法結構（諸如哪些表示式巢狀在其他表示式中）之類的東西，但是我們知道的也就僅限於此了。

In an expression like a + b, we know we are adding a and b, but we don’t know what those names refer to. Are they local variables? Global? Where are they defined?

在a + b這樣的表示式中，我們知道我們要把a和b相加，但我們不知道這些名字指的是什麼。它們是區域性變數嗎？全域性變數？它們在哪裡被定義？

The first bit of analysis that most languages do is called binding or resolution. For each identifier we find out where that name is defined and wire the two together. This is where scope comes into play—the region of source code where a certain name can be used to refer to a certain declaration.

大多數語言所做的第一點分析叫做繫結或決議。對於每一個識別符號，我們都要找出定義該名稱的地方，並將兩者連線起來。這就是作用域的作用——在這個原始碼區域中，某個名字可以用來引用某個宣告。

If the language is statically typed, this is when we type check. Once we know where a and b are declared, we can also figure out their types. Then if those types don’t support being added to each other, we report a type error.

如果語言是靜態型別的，這就是我們進行型別檢查的時機。一旦我們知道了a和b的宣告位置，我們也可以弄清楚它們的型別。然後如果這些型別不支援相加，我們就會報告一個型別錯誤²。

Take a deep breath. We have attained the summit of the mountain and a sweeping view of the user’s program. All this semantic insight that is visible to us from analysis needs to be stored somewhere. There are a few places we can squirrel it away:

• Often, it gets stored right back as attributes on the syntax tree itself—extra fields in the nodes that aren’t initialized during parsing but get filled in later.
• Other times, we may store data in a look-up table off to the side. Typically, the keys to this table are identifiers—names of variables and declarations. In that case, we call it a symbol table and the values it associates with each key tell us what that identifier refers to.
• The most powerful bookkeeping tool is to transform the tree into an entirely new data structure that more directly expresses the semantics of the code. That’s the next section.

深吸一口氣。 我們已經到達了山頂，並對使用者的程式有了全面的瞭解。從分析中可見的所有語義資訊都需要儲存在某個地方。我們可以把它儲存在幾個地方：

• 通常，它會被直接儲存在語法樹本身的屬性中——屬性是節點中的額外欄位，這些欄位在解析時不會初始化，但在稍後會進行填充。
• 有時，我們可能會將資料儲存在外部的查詢表中。 通常，該表的關鍵字是識別符號，即變數和宣告的名稱。 在這種情況下，我們稱其為符號表，並且其中與每個鍵關聯的值告訴我們該識別符號所指的是什麼。
• 最強大的記錄工具是將樹轉化為一個全新的資料結構，更直接地表達程式碼的語義。這是下一節的內容。

Everything up to this point is considered the front end of the implementation. You might guess everything after this is the back end, but no. Back in the days of yore when “front end” and “back end” were coined, compilers were much simpler. Later researchers invented new phases to stuff between the two halves. Rather than discard the old terms, William Wulf and company lumped them into the charming but spatially paradoxical name middle end.

到目前為止，所有內容都被視為實現的前端。 你可能會猜至此以後是後端，其實並不是。 在過去的年代，當“前端”和“後端”被創造出來時，編譯器要簡單得多。 後來，研究人員在兩個半部之間引入了新階段。 威廉·沃爾夫（William Wulf）和他的同伴沒有放棄舊術語，而是新添加了一個迷人但有點自相矛盾的名稱“中端”。

2 . 1 . 4 Intermediate representations

2.1.4 中間碼

You can think of the compiler as a pipeline where each stage’s job is to organize the data representing the user’s code in a way that makes the next stage simpler to implement. The front end of the pipeline is specific to the source language the program is written in. The back end is concerned with the final architecture where the program will run.

你可以把編譯器看成是一條流水線，每個階段的工作是把代表使用者程式碼的資料組織起來，使下一階段的實現更加簡單。管道的前端是針對程式所使用的源語言編寫的。後端關注的是程式執行的最終架構。

In the middle, the code may be stored in some intermediate representation (or IR) that isn’t tightly tied to either the source or destination forms (hence “intermediate”). Instead, the IR acts as an interface between these two languages.

在中間階段，程式碼可能被儲存在一些中間程式碼（intermediate representation， 也叫IR）中，這些中間程式碼與原始檔或目的檔案形式都沒有緊密的聯絡（因此叫作 "中間"）。相反，IR充當了這兩種語言之間的介面³。

This lets you support multiple source languages and target platforms with less effort. Say you want to implement Pascal, C and Fortran compilers and you want to target x86, ARM, and, I dunno, SPARC. Normally, that means you’re signing up to write nine full compilers: Pascal→x86, C→ARM, and every other combination.

這可以讓你更輕鬆地支援多種源語言和目標平臺。假設你想在x86、ARM、SPARC 平臺上實現Pascal、C和Fortran編譯器。通常情況下，這意味著你需要寫九個完整的編譯器：Pascal→x86，C→ARM，以及其他各種組合⁴。

A shared intermediate representation reduces that dramatically. You write one front end for each source language that produces the IR. Then one back end for each target architecture. Now you can mix and match those to get every combination.

一個共享的中間程式碼可以大大減少這種情況。你為每個產生IR的源語言寫一個前端。然後為每個目標平臺寫一個後端。現在，你可以將這些混搭起來，得到每一種組合。

There’s another big reason we might want to transform the code into a form that makes the semantics more apparent…

我們希望將程式碼轉化為某種語義更加明確的形式，還有一個重要的原因是。。。

2 . 1 . 5 Optimization

2.1.5 最佳化

Once we understand what the user’s program means, we are free to swap it out with a different program that has the same semantics but implements them more efficiently—we can optimize it.

一旦我們理解了使用者程式的含義，我們就可以自由地用另一個具有相同語義但實現效率更高的程式來交換它——我們可以對它進行最佳化。

A simple example is constant folding: if some expression always evaluates to the exact same value, we can do the evaluation at compile time and replace the code for the expression with its result. If the user typed in:

一個簡單的例子是常量摺疊：如果某個表示式求值得到的始終是完全相同的值，我們可以在編譯時進行求值，並用其結果替換該表示式的程式碼。 如果使用者輸入：

pennyArea = 3.14159 * (0.75 / 2) * (0.75 / 2);

We can do all of that arithmetic in the compiler and change the code to:

我們可以在編譯器中完成所有的算術運算，並將程式碼更改為：

pennyArea = 0.4417860938;

Optimization is a huge part of the programming language business. Many language hackers spend their entire careers here, squeezing every drop of performance they can out of their compilers to get their benchmarks a fraction of a percent faster. It can become a sort of obsession.

最佳化是程式語言業務的重要組成部分。許多語言駭客把他們的整個職業生涯都花在了這裡，竭盡所能地從他們的編譯器中擠出每一點效能，以使他們的基準測試速度提高百分之幾。有的時候這也會變成一種痴迷, 無法自拔。

We’re mostly going to hop over that rathole in this book. Many successful languages have surprisingly few compile-time optimizations. For example, Lua and CPython generate relatively unoptimized code, and focus most of their performance effort on the runtime.

我們在本書中通常會跳過這些棘手問題。令人驚訝的是許多成功的語言只有很少的編譯期最佳化。 例如，Lua和CPython生成沒怎麼最佳化過的程式碼，並將其大部分效能工作集中在執行時上⁵。

2 . 1 . 6 Code generation

2.1.6 程式碼生成

We have applied all of the optimizations we can think of to the user’s program. The last step is converting it to a form the machine can actually run. In other words generating code (or code gen), where “code” here usually refers to the kind of primitive assembly-like instructions a CPU runs and not the kind of “source code” a human might want to read.

我們已經將所有可以想到的最佳化應用到了使用者程式中。 最後一步是將其轉換為機器可以實際執行的形式。 換句話說，生成程式碼（或程式碼生成），這裡的“程式碼”通常是指CPU執行的類似於彙編的原始指令，而不是人類可能想要閱讀的“原始碼”。

Finally, we are in the back end, descending the other side of the mountain. From here on out, our representation of the code becomes more and more primitive, like evolution run in reverse, as we get closer to something our simple-minded machine can understand.

最後，我們到了後端，從山的另一側開始向下。 從現在開始，隨著我們越來越接近於思維簡單的機器可以理解的東西，我們對程式碼的表示變得越來越原始，就像逆向進化。

We have a decision to make. Do we generate instructions for a real CPU or a virtual one? If we generate real machine code, we get an executable that the OS can load directly onto the chip. Native code is lightning fast, but generating it is a lot of work. Today’s architectures have piles of instructions, complex pipelines, and enough historical baggage to fill a 747’s luggage bay.

我們需要做一個決定。 我們是為真實CPU還是虛擬CPU生成指令？ 如果我們生成真實的機器程式碼，則會得到一個可執行檔案，作業系統可以將其直接載入到晶片上。 原生程式碼快如閃電，但生成它需要大量工作。 當今的體系結構包含大量指令，複雜的管線和足夠塞滿一架747行李艙的歷史包袱。

Speaking the chip’s language also means your compiler is tied to a specific architecture. If your compiler targets x86 machine code, it’s not going to run on an ARM device. All the way back in the 60s, during the Cambrian explosion of computer architectures, that lack of portability was a real obstacle.

使用晶片的語言也意味著你的編譯器是與特定的架構相繫結的。如果你的編譯器以x86機器程式碼為目標，那麼它就無法在ARM裝置上執行。追朔到上世紀60年代計算機體系結構 “寒武紀大爆發” 期間，這種缺乏可移植性的情況是一個真正的障礙⁶。

To get around that, hackers like Martin Richards and Niklaus Wirth, of BCPL and Pascal fame, respectively, made their compilers produce virtual machine code. Instead of instructions for some real chip, they produced code for a hypothetical, idealized machine. Wirth called this “p-code” for “portable”, but today, we generally call it bytecode because each instruction is often a single byte long.

為瞭解決這個問題，專家開始讓他們的編譯器生成虛擬機器程式碼，包括BCPL的設計者Martin Richards以及Pascal設計者Niklaus Wirth。他們不是為真正的晶片編寫指令，而是為一個假設的、理想化的機器編寫程式碼。Wirth稱這種p-code為“可移植程式碼”，但今天，我們通常稱它為位元組碼，因為每條指令通常都是一個位元組長。

These synthetic instructions are designed to map a little more closely to the language’s semantics, and not be so tied to the peculiarities of any one computer architecture and its accumulated historical cruft. You can think of it like a dense, binary encoding of the language’s low-level operations.

這些合成指令的設計是為了更緊密地對映到語言的語義上，而不必與任何一個計算機體系結構的特性和它積累的歷史錯誤繫結在一起。你可以把它想象成語言底層操作的密集二進位制編碼。

2 . 1 . 7 Virtual machine

2.1.7 虛擬機器

If your compiler produces bytecode, your work isn’t over once that’s done. Since there is no chip that speaks that bytecode, it’s your job to translate. Again, you have two options. You can write a little mini-compiler for each target architecture that converts the bytecode to native code for that machine. You still have to do work for each chip you support, but this last stage is pretty simple and you get to reuse the rest of the compiler pipeline across all of the machines you support. You’re basically using your bytecode as an intermediate representation.

如果你的編譯器產生了位元組碼，你的工作還沒有結束。因為沒有晶片可以解析這些位元組碼，因此你還需要進行翻譯。同樣，你有兩個選擇。你可以為每個目標體系結構編寫一個小型編譯器，將位元組碼轉換為該機器的本機程式碼⁷。你仍然需要針對你支援的每個晶片做一些工作，但最後這個階段非常簡單，你可以在你支援的所有機器上重複使用編譯器流水線的其餘部分。你基本上是把你的位元組碼作為一種中間程式碼。

Or you can write a virtual machine (VM), a program that emulates a hypothetical chip supporting your virtual architecture at runtime. Running bytecode in a VM is slower than translating it to native code ahead of time because every instruction must be simulated at runtime each time it executes. In return, you get simplicity and portability. Implement your VM in, say, C, and you can run your language on any platform that has a C compiler. This is how the second interpreter we build in this book works.

或者，你可以編寫虛擬機器（VM）⁸，該程式可在執行時模擬支援虛擬架構的虛擬晶片。在虛擬機器中執行位元組碼比提前將其翻譯成原生代碼要慢，因為每條指令每次執行時都必須在執行時模擬。作為回報，你得到的是簡單性和可移植性。用比如說C語言實現你的虛擬機器，你就可以在任何有C編譯器的平臺上執行你的語言。這就是我們在本書中構建的第二個直譯器的工作原理。

2 . 1 . 8 Runtime

2.1.8 執行時

We have finally hammered the user’s program into a form that we can execute. The last step is running it. If we compiled it to machine code, we simply tell the operating system to load the executable and off it goes. If we compiled it to bytecode, we need to start up the VM and load the program into that.

我們終於將使用者程式錘鍊成可以執行的形式。最後一步是執行它。如果我們將其編譯為機器碼，我們只需告訴作業系統載入可執行檔案，然後就可以運行了。如果我們將它編譯成位元組碼，我們需要啟動VM並將程式載入到其中。

In both cases, for all but the basest of low-level languages, we usually need some services that our language provides while the program is running. For example, if the language automatically manages memory, we need a garbage collector going in order to reclaim unused bits. If our language supports “instance of” tests so you can see what kind of object you have, then we need some representation to keep track of the type of each object during execution.

在這兩種情況下，除了最基本的底層語言外，我們通常需要我們的語言在程式執行時提供一些服務。例如，如果語言自動管理記憶體，我們需要一個垃圾收集器去回收未使用的位元位。如果我們的語言支援用 "instance of "測試我們擁有什麼型別的物件，那麼我們就需要一些表示方法來跟蹤執行過程中每個物件的型別。

All of this stuff is going at runtime, so it’s called, appropriately, the runtime. In a fully compiled language, the code implementing the runtime gets inserted directly into the resulting executable. In, say, Go, each compiled application has its own copy of Go’s runtime directly embedded in it. If the language is run inside an interpreter or VM, then the runtime lives there. This is how most implementations of languages like Java, Python, and JavaScript work.

所有這些東西都是在執行時進行的，所以它被恰當地稱為，執行時。在一個完全編譯的語言中，實現執行時的程式碼會直接插入到生成的可執行檔案中。比如說，在Go中，每個編譯後的應用程式都有自己的一份Go的執行時副本直接嵌入其中。如果語言是在直譯器或虛擬機器內執行，那麼執行時將駐留於虛擬機器中。這也就是Java、Python和JavaScript等大多數語言實現的工作方式。

2 . 2 Shortcuts and Alternate Routes

2.2 捷徑和備選路線

That’s the long path covering every possible phase you might implement. Many languages do walk the entire route, but there are a few shortcuts and alternate paths.

這是一條漫長的道路，涵蓋了你要實現的每個可能的階段。許多語言的確走完了整條路線，但也有一些捷徑和備選路徑。

2 . 2 . 1 Single-pass compilers

2.2.1 單遍編譯器

Some simple compilers interleave parsing, analysis, and code generation so that they produce output code directly in the parser, without ever allocating any syntax trees or other IRs. These single-pass compilers restrict the design of the language. You have no intermediate data structures to store global information about the program, and you don’t revisit any previously parsed part of the code. That means as soon as you see some expression, you need to know enough to correctly compile it.

一些簡單的編譯器將解析、分析和程式碼生成交織在一起，這樣它們就可以直接在解析器中生成輸出程式碼，而無需分配任何語法樹或其他IR。這些單遍編譯器限制了語言的設計。你沒有中間資料結構來儲存程式的全域性資訊，也不會重新訪問任何之前解析過的程式碼部分。 這意味著，一旦你看到某個表示式，就需要足夠的知識來正確地對其進行編譯⁹。

Pascal and C were designed around this limitation. At the time, memory was so precious that a compiler might not even be able to hold an entire source file in memory, much less the whole program. This is why Pascal’s grammar requires type declarations to appear first in a block. It’s why in C you can’t call a function above the code that defines it unless you have an explicit forward declaration that tells the compiler what it needs to know to generate code for a call to the later function.

Pascal和C語言就是圍繞這個限制而設計的。在當時，記憶體非常珍貴，一個編譯器可能連整個原始檔都無法存放在記憶體中，更不用說整個程式了。這也是為什麼Pascal的語法要求型別宣告要先出現在一個塊中。這也是為什麼在C語言中，你不能在定義函式的程式碼上面呼叫函式，除非你有一個明確的前向宣告，告訴編譯器它需要知道什麼，以便生成呼叫後面函式的程式碼。

2 . 2 . 2 Tree-walk interpreters

2.2.2 樹遍歷直譯器

Some programming languages begin executing code right after parsing it to an AST (with maybe a bit of static analysis applied). To run the program, the interpreter traverses the syntax tree one branch and leaf at a time, evaluating each node as it goes.

有些程式語言在將程式碼解析為AST後就開始執行程式碼（可能應用了一點靜態分析）。為了執行程式，直譯器每次都會遍歷語法樹的一個分支和葉子，並在執行過程中計算每個節點。

This implementation style is common for student projects and little languages, but is not widely used for general-purpose languages since it tends to be slow. Some people use “interpreter” to mean only these kinds of implementations, but others define that word more generally, so I’ll use the inarguably explicit “tree-walk interpreter” to refer to these. Our first interpreter rolls this way.

這種實現風格在學生專案和小型語言中很常見，但在通用語言中並不廣泛使用，因為它往往很慢。有些人使用“直譯器”僅指這類實現，但其他人對“直譯器”一詞的定義更寬泛，因此我將使用沒有歧義的“樹遍歷直譯器”來指代這些實現。我們的第一個直譯器就是這樣工作的¹⁰。

2 . 2 . 3 Transpilers

2.2.3 轉譯器

Writing a complete back end for a language can be a lot of work. If you have some existing generic IR to target, you could bolt your front end onto that. Otherwise, it seems like you’re stuck. But what if you treated some other source language as if it were an intermediate representation?

為一種語言編寫一個完整的後端可能需要大量的工作。 如果你有一些現有的通用IR作為目標，則可以將前端轉換到該IR上。 否則，你可能會陷入困境。 但是，如果你將某些其他源語言視為中間程式碼，該怎麼辦？

You write a front end for your language. Then, in the back end, instead of doing all the work to lower the semantics to some primitive target language, you produce a string of valid source code for some other language that’s about as high level as yours. Then, you use the existing compilation tools for that language as your escape route off the mountain and down to something you can execute.

你需要為你的語言編寫一個前端。然後，在後端，你可以生成一份與你的語言級別差不多的其他語言的有效原始碼字串，而不是將所有程式碼降低到某個原始目標語言的語義。然後，你可以使用該語言現有的編譯工具作為逃離大山的路徑，得到某些可執行的內容。

They used to call this a source-to-source compiler or a transcompiler. After the rise of languages that compile to JavaScript in order to run in the browser, they’ve affected the hipster sobriquet transpiler.

人們過去稱之為源到源編譯器或轉換編譯器¹¹。隨著那些為了在瀏覽器中執行而編譯成JavaScript的各類語言的興起，它們有了一個時髦的名字——轉譯器。

While the first transcompiler translated one assembly language to another, today, most transpilers work on higher-level languages. After the viral spread of UNIX to machines various and sundry, there began a long tradition of compilers that produced C as their output language. C compilers were available everywhere UNIX was and produced efficient code, so targeting C was a good way to get your language running on a lot of architectures.

雖然第一個編譯器是將一種組合語言翻譯成另一種組合語言，但現今，大多數編譯器都適用於高階語言。在UNIX廣泛執行在各種各樣的機器上之後，編譯器開始長期以C作為輸出語言。C編譯器在UNIX存在的地方都可以使用，並能生成有效的程式碼，因此，以C為目標是讓語言在許多體系結構上執行的好方法。

Web browsers are the “machines” of today, and their “machine code” is JavaScript, so these days it seems almost every language out there has a compiler that targets JS since that’s the main way to get your code running in a browser.

Web瀏覽器是今天的 "機器"，它們的 "機器程式碼 "是JavaScript，所以現在似乎幾乎所有的語言都有一個以JS為目標的編譯器，因為這是讓你的程式碼在瀏覽器中執行的主要方式¹²。

The front end—scanner and parser—of a transpiler looks like other compilers. Then, if the source language is only a simple syntactic skin over the target language, it may skip analysis entirely and go straight to outputting the analogous syntax in the destination language.

轉譯器的前端（掃描器和解析器）看起來跟其他編譯器相似。 然後，如果源語言只是在目標語言在語法方面的換皮版本，則它可能會完全跳過分析，並直接輸出目標語言中的類似語法。

If the two languages are more semantically different, then you’ll see more of the typical phases of a full compiler including analysis and possibly even optimization. Then, when it comes to code generation, instead of outputting some binary language like machine code, you produce a string of grammatically correct source (well, destination) code in the target language.

如果兩種語言的語義差異較大，那麼你就會看到完整編譯器的更多典型階段，包括分析甚至最佳化。然後，在程式碼生成階段，無需輸出一些像機器程式碼一樣的二進位制語言，而是生成一串語法正確的目標語言的原始碼（好吧，目的碼）。

Either way, you then run that resulting code through the output language’s existing compilation pipeline and you’re good to go.

不管是哪種方式，你再透過目標語言已有的編譯流水線執行生成的程式碼就可以了。

2 . 2 . 4 Just-in-time compilation

2.2.4 即時編譯

This last one is less of a shortcut and more a dangerous alpine scramble best reserved for experts. The fastest way to execute code is by compiling it to machine code, but you might not know what architecture your end user’s machine supports. What to do?

最後一個與其說是捷徑，不如說是危險的高山爭霸賽，最好留給專家。執行程式碼最快的方法是將程式碼編譯成機器程式碼，但你可能不知道你的終端使用者的機器支援什麼架構。該怎麼做呢？

You can do the same thing that the HotSpot JVM, Microsoft’s CLR and most JavaScript interpreters do. On the end user’s machine, when the program is loaded—either from source in the case of JS, or platform-independent bytecode for the JVM and CLR—you compile it to native for the architecture their computer supports. Naturally enough, this is called just-in-time compilation. Most hackers just say “JIT”, pronounced like it rhymes with “fit”.

你可以做和HotSpot JVM、Microsoft的CLR和大多數JavaScript直譯器相同的事情。 在終端使用者的機器上，當程式載入時（無論是JS原始碼還者是平臺無關的JVM和CLR位元組碼），都可以將其編譯為對應的原生代碼，以適應本機支援的體系結構。 自然地，這被稱為即時編譯。 大多數駭客只是說“ JIT”，其發音與“ fit”押韻。

The most sophisticated JITs insert profiling hooks into the generated code to see which regions are most performance critical and what kind of data is flowing through them. Then, over time, they will automatically recompile those hot spots with more advanced optimizations.

最複雜的JIT將效能分析鉤子插入到生成的程式碼中，以檢視哪些區域對效能最為關鍵，以及哪些型別的資料正在流經其中。 然後，隨著時間的推移，它們將透過更高階的最佳化功能自動重新編譯那些熱點部分¹³。

2 . 3 Compilers and Interpreters

2.3 編譯器和直譯器

Now that I’ve stuffed your head with a dictionary’s worth of programming language jargon, we can finally address a question that’s plagued coders since time immemorial: “What’s the difference between a compiler and an interpreter?”

現在我已經向你的腦袋裡塞滿了一大堆程式語言術語，我們終於可以解決一個自遠古以來一直困擾著程式設計師的問題:編譯器和直譯器之間有什麼區別?

It turns out this is like asking the difference between a fruit and a vegetable. That seems like a binary either-or choice, but actually “fruit” is a botanical term and “vegetable” is culinary. One does not strictly imply the negation of the other. There are fruits that aren’t vegetables (apples) and vegetables that are not fruits (carrots), but also edible plants that are both fruits and vegetables, like tomatoes.

事實證明，這就像問水果和蔬菜的區別一樣。這看上去似乎是一個非此即彼的選擇，但實際上 "水果 "是一個植物學術語，"蔬菜 "是烹飪學術語。嚴格來說，一個並不意味著對另一個的否定。有不是蔬菜的水果（蘋果），也有不是水果的蔬菜（胡蘿蔔），也有既是水果又是蔬菜的可食用植物，比如西紅柿¹⁴。

So, back to languages:

• Compiling is an implementation technique that involves translating a source language to some other—usually lower-level—form. When you generate bytecode or machine code, you are compiling. When you transpile to another high-level language you are compiling too.
• When we say a language implementation “is a compiler”, we mean it translates source code to some other form but doesn’t execute it. The user has to take the resulting output and run it themselves.
• Conversely, when we say an implementation “is an interpreter”, we mean it takes in source code and executes it immediately. It runs programs “from source”.

好，回到語言上：

• 編譯是一種實現技術，其中涉及到將源語言翻譯成其他語言——通常是較低階的形式。當你生成位元組碼或機器程式碼時，你就是在編譯。當你移植到另一種高階語言時，你也在編譯。
• 當我們說語言實現“是編譯器”時，是指它會將原始碼轉換為其他形式，但不會執行。 使用者必須獲取結果輸出並自己執行。
• 相反，當我們說一個實現“是一個直譯器”時，是指它接受原始碼並立即執行它。 它“從原始碼”執行程式。

Like apples and oranges, some implementations are clearly compilers and not interpreters. GCC and Clang take your C code and compile it to machine code. An end user runs that executable directly and may never even know which tool was used to compile it. So those are compilers for C.

像蘋果和橘子一樣，某些實現顯然是編譯器，而不是直譯器。 GCC和Clang接受你的C程式碼並將其編譯為機器程式碼。 終端使用者直接執行該可執行檔案，甚至可能永遠都不知道使用了哪個工具來編譯它。 所以這些是C的編譯器。

In older versions of Matz’ canonical implementation of Ruby, the user ran Ruby from source. The implementation parsed it and executed it directly by traversing the syntax tree. No other translation occurred, either internally or in any user-visible form. So this was definitely an interpreter for Ruby.

由 Matz 實現的老版本 Ruby 中，使用者從原始碼中執行Ruby。該實現透過遍歷語法樹對其進行解析並直接執行。期間都沒有發生其他的轉換，無論是在實現內部還是以任何使用者可見的形式。所以這絕對是一個Ruby的直譯器。

But what of CPython? When you run your Python program using it, the code is parsed and converted to an internal bytecode format, which is then executed inside the VM. From the user’s perspective, this is clearly an interpreter—they run their program from source. But if you look under CPython’s scaly skin, you’ll see that there is definitely some compiling going on.

但是 CPython 呢？當你使用它執行你的Python程式時，程式碼會被解析並轉換為內部位元組碼格式，然後在虛擬機器內部執行。從使用者的角度來看，這顯然是一個直譯器——他們是從原始碼開始執行自己的程式。但如果你看一下CPython的內部，你會發現肯定有一些編譯工作在進行。

The answer is that it is both. CPython is an interpreter, and it has a compiler. In practice, most scripting languages work this way, as you can see:

答案是兩者兼而有之。 CPython是一個直譯器，但他也有一個編譯器。 實際上，大多數指令碼語言都以這種方式工作¹⁵，如你所見：

That overlapping region in the center is where our second interpreter lives too, since it internally compiles to bytecode. So while this book is nominally about interpreters, we’ll cover some compilation too.

中間那個重疊的區域也是我們第二個直譯器所在的位置，因為它會在內部編譯成位元組碼。所以，雖然本書名義上是關於直譯器的，但我們也會涉及一些編譯的內容。

2 . 4 Our Journey

2.4 我們的旅程

That’s a lot to take in all at once. Don’t worry. This isn’t the chapter where you’re expected to understand all of these pieces and parts. I just want you to know that they are out there and roughly how they fit together.

一下子有太多東西要消化掉。別擔心。這一章並不是要求你理解所有這些零碎的內容。我只是想讓你們知道它們是存在的，以及大致瞭解它們是如何組合在一起的。

This map should serve you well as you explore the territory beyond the guided path we take in this book. I want to leave you yearning to strike out on your own and wander all over that mountain.

當你探索本書本書所指導的路徑之外的領域時，這張地圖應該對你很有用。我希望你自己出擊，在那座山裡到處遊走。

But, for now, it’s time for our own journey to begin. Tighten your bootlaces, cinch up your pack, and come along. From here on out, all you need to focus on is the path in front of you.

但是，現在，是我們自己的旅程開始的時候了。繫好你的鞋帶，背好你的包，走吧。從這裡開始，你需要關注的是你面前的路。

CHALLENGES

習題

1、Pick an open source implementation of a language you like. Download the source code and poke around in it. Try to find the code that implements the scanner and parser. Are they hand-written, or generated using tools like Lex and Yacc? (.l or .y files usually imply the latter.)

1、選擇一個你喜歡的語言的開源實現。下載原始碼，並在其中探索。試著找到實現掃描器和解析器的程式碼，它們是手寫的，還是用Lex和Yacc等工具生成的？（存在.l或.y檔案通常意味著後者）

2、Just-in-time compilation tends to be the fastest way to implement a dynamically-typed language, but not all of them use it. What reasons are there to not JIT?

2、實時編譯往往是實現動態型別語言最快的方法，但並不是所有的語言都使用它。有什麼理由不採用JIT呢？

3、Most Lisp implementations that compile to C also contain an interpreter that lets them execute Lisp code on the fly as well. Why?

3、大多數可編譯為C的Lisp實現也包含一個直譯器，該直譯器還使它們能夠即時執行Lisp程式碼。 為什麼？

1. 毫無疑問，CS論文也有死衚衕，被引為零的悲慘小眾論文以及如今被遺忘的最佳化方法，這些最佳化方法只有在以單個位元組為單位來衡量記憶體時才有意義。 ↩

2. 我們在本書中構建的語言是動態型別的，因此將在稍後的執行時中進行型別檢查。 ↩

3. 有幾種成熟的IR風格。點選你熟悉的搜尋引擎，搜尋 "控制流圖"、"靜態單賦值形式"、"延續傳遞形式 "和 "三位址碼"。 ↩

4. 如果你曾經好奇GCC如何支援這麼多瘋狂的語言和體系結構，例如Motorola 68k上的Modula-3，現在你就明白了。 語言前端針對的是少數IR，主要是GIMPLE和RTL。 目標後端如68k，會接受這些IR並生成本機程式碼。 ↩

5. 如果你無法抗拒要進入這個領域，可以從以下關鍵字開始，例如“常量摺疊”，“公共表示式消除”，“迴圈不變程式碼外提”，“全域性值編號”，“強度降低”，“ 聚合量標量替換”，“死碼刪除”和“迴圈展開”。 ↩

6. 例如，AAD（"ASCII Adjust AX Before Division",除法前ASCII調整AX）指令可以讓你執行除法，這聽起來很有用。除了該指令將兩個二進位制編碼的十進位制數字作為運算元打包到一個16位暫存器中。你最後一次在16位機器上使用BCD是什麼時候？ ↩

7. 這裡的基本原則是，你把特定於體系架構的工作推得越靠後，你就可以在不同架構之間共享更多的早期階段。不過，這裡存在一些矛盾。 許多最佳化（例如暫存器分配和指令選擇）在瞭解特定晶片的優勢和功能時才能發揮最佳效果。 弄清楚編譯器的哪些部分可以共享，哪些應該針對特定目標是一門藝術。 ↩

8. 術語“虛擬機器”也指另一種抽象。 “系統虛擬機器”在軟體中模擬整個硬體平臺和作業系統。 這就是你可以在Linux機器上玩Windows遊戲的原因，也是雲提供商為什麼可以給客戶提供控制自己的“伺服器”的使用者體驗，而無需為每個使用者實際分配單獨的計算機。在本書中，我們將要討論的虛擬機器型別是“語言虛擬機器”或“程序虛擬機器”（如果你需要明確的話）。 ↩

9. 語法導向翻譯是一種結構化的技術，用於構建這些一次性編譯器。你可以將一個操作與語法的每個片段(通常是生成輸出程式碼的語法片段)相關聯。然後，每當解析器匹配該語法塊時，它就執行操作，一次構建一個規則的目的碼。 ↩

10. 一個明顯的例外是早期版本的Ruby，它們是樹遍歷型直譯器。在1.9時，Ruby的規範實現從最初的MRI（"Matz' Ruby Interpreter"）切換到了Koichi Sasada的YARV（"Yet Another Ruby VM"）。YARV是一個位元組碼虛擬機器。 ↩

11. 第一個轉編譯器XLT86將8080程式集轉換為8086程式集。 這看似簡單，但請記住8080是8位晶片，而8086是16位晶片，可以將每個暫存器用作一對8位暫存器。 XLT86進行了資料流分析，以跟蹤源程式中的暫存器使用情況，然後將其有效地對映到8086的暫存器集。它是由悲慘的電腦科學英雄加里·基爾達爾（Gary Kildall）撰寫的。 他是最早認識到微型計算機前景的人之一，他建立了PL / M和CP / M，這是它們的第一種高階語言和作業系統。 ↩

12. JS曾經是在瀏覽器中執行程式碼的唯一方式。多虧了Web Assembly，編譯器現在有了第二種可以在Web上執行的低階語言。 ↩

13. 當然，這正是HotSpot JVM名稱的來源。 ↩

14. 花生（連真正的堅果都算不上）和小麥等穀類其實都是水果，但我把這個圖畫錯了。我能說什麼呢，我是個軟體工程師，不是植物學家。我也許應該抹掉這個花生小傢伙，但他太可愛了，我不忍心。 ↩

15. Go工具更是一個奇葩。如果你執行go build，它就會把你的go原始碼編譯成機器程式碼然後停止。如果你輸入go run，它也會這樣做，然後立即執行生成的可執行檔案。所以，可以說go是一個編譯器（你可以把它當做一個工具來編譯程式碼而不執行）；也可以說是一個直譯器（你可以呼叫它立即從原始碼中執行一個程式），並且有一個編譯器（當你把它當做直譯器使用時，它仍然在內部編譯）。 ↩

3.Lox語言 The Lox Language

What nicer thing can you do for somebody than make them breakfast?

​ ——Anthony Bourdain

還有什麼能比給別人做頓早餐，更能體現你對他的好呢？

We’ll spend the rest of this book illuminating every dark and sundry corner of the Lox language, but it seems cruel to have you immediately start grinding out code for the interpreter without at least a glimpse of what we’re going to end up with.

我們將用本書的其餘部分來照亮Lox語言的每一個黑暗和雜亂的角落，但如果讓你在對目標一無所知的情況下，就立即開始為直譯器編寫程式碼，這似乎很殘忍。

At the same time, I don’t want to drag you through reams of language lawyering and specification-ese before you get to touch your text editor. So this will be a gentle, friendly introduction to Lox. It will leave out a lot of details and edge cases. We’ve got plenty of time for those later.

與此同時，我也不想在您編碼之前，就把您拖入大量的語言和規範術語中。所以這是一個溫和、友好的Lox介紹，它會省去很多細節和邊緣情況¹。後面我們有足夠的時間來解決這些問題。

3 . 1 Hello, Lox

3 . 1 Hello, Lox

Here’s your very first taste of Lox:

下面是你對Lox的第一次體驗：

// Your first Lox program!
print "Hello, world!";

As that // line comment and the trailing semicolon imply, Lox’s syntax is a member of the C family. (There are no parentheses around the string because print is a built-in statement, and not a library function.)

正如那句//行註釋和後面的分號所暗示的那樣，Lox的語法是C語言家族的成員之一。（因為print是一個內建語句，而不是庫函式，所以字串周圍沒有括號。）

Now, I won’t claim that C has a great syntax. If we wanted something elegant, we’d probably mimic Pascal or Smalltalk. If we wanted to go full Scandinavian-furniture-minimalism, we’d do a Scheme. Those all have their virtues.

這裡，我並不是想說C語言具有出色的語法²。如果我們想要一些優雅的東西，我們可能會模仿Pascal或Smalltalk。如果我們想要完全體現斯堪的納維亞傢俱的極簡主義風格，我們會實現一個Scheme。這些都有其優點。

What C-like syntax has instead is something you’ll find is often more valuable in a language: familiarity. I know you are already comfortable with that style because the two languages we’ll be using to implement Lox—Java and C—also inherit it. Using a similar syntax for Lox gives you one less thing to learn.

但是，類C的語法所具有的反而是一些在語言中更有價值的東西：熟悉度。我知道你已經對這種風格很熟悉了，因為我們將用來實現Lox的兩種語言——Java和C——也繼承了這種風格。讓Lox使用類似的語法，你就少了一件需要學習的事情。

3 . 2 A High-Level Language

3.2 高階語言

While this book ended up bigger than I was hoping, it’s still not big enough to fit a huge language like Java in it. In order to fit two complete implementations of Lox in these pages, Lox itself has to be pretty compact.

雖然這本書最終比我所希望的要大，但它仍然不夠大，無法將Java這樣一門龐大的語言放進去。為了在有限的篇幅裡容納兩個完整的Lox實現，Lox本身必須相當緊湊。

When I think of languages that are small but useful, what comes to mind are high-level “scripting” languages like JavaScript, Scheme, and Lua. Of those three, Lox looks most like JavaScript, mainly because most C-syntax languages do. As we’ll learn later, Lox’s approach to scoping hews closely to Scheme. The C flavor of Lox we’ll build in Part III is heavily indebted to Lua’s clean, efficient implementation.

當我想到那些小而有用的語言時，我腦海中浮現的是像JavaScript³、Scheme和Lua這樣的高階 "指令碼 "語言。在這三種語言中，Lox看起來最像JavaScript，主要是因為大多數c語法語言都是這樣的。稍後我們將瞭解到，Lox的範圍界定方法與Scheme密切相關。 我們將在第三部分中構建的C風格的Lox很大程度上借鑑了Lua的乾淨、高效的實現。

Lox shares two other aspects with those three languages:

Lox與這三種語言有兩個共同之處：

3 . 2 . 1 Dynamic typing

3.2.1 動態型別

Lox is dynamically typed. Variables can store values of any type, and a single variable can even store values of different types at different times. If you try to perform an operation on values of the wrong type—say, dividing a number by a string—then the error is detected and reported at runtime.

Lox是動態型別的。變數可以儲存任何型別的值，單個變數甚至可以在不同時間儲存不同型別的值。如果嘗試對錯誤型別的值執行操作（例如，將數字除以字串），則會在執行時檢測到錯誤並報告。

There are plenty of reasons to like static types, but they don’t outweigh the pragmatic reasons to pick dynamic types for Lox. A static type system is a ton of work to learn and implement. Skipping it gives you a simpler language and a shorter book. We’ll get our interpreter up and executing bits of code sooner if we defer our type checking to runtime.

喜歡靜態型別的原因有很多，但它們都比不上為Lox選擇動態型別的實際原因⁴。靜態型別系統需要學習和實現大量的工作。跳過它會讓你的語言更簡單，也可以讓本書更短。如果我們將型別檢查推遲到執行時，我們將可以更快地啟動直譯器並執行程式碼。

3 . 2 . 2 Automatic memory management

3.2.2 自動記憶體管理

High-level languages exist to eliminate error-prone, low-level drudgery and what could be more tedious than manually managing the allocation and freeing of storage? No one rises and greets the morning sun with, “I can’t wait to figure out the correct place to call free() for every byte of memory I allocate today!”

高階語言的存在是為了消除容易出錯的低階工作，還有什麼比手動管理儲存的分配和釋放更繁瑣的呢?沒有人會抬起頭來迎接早晨的陽光，“我迫不及待想找到正確的位置去呼叫free()方法，來釋放掉今天我在記憶體中申請的每個位元組！”

There are two main techniques for managing memory: reference counting and tracing garbage collection (usually just called “garbage collection” or “GC”). Ref counters are much simpler to implement—I think that’s why Perl, PHP, and Python all started out using them. But, over time, the limitations of ref counting become too troublesome. All of those languages eventually ended up adding a full tracing GC or at least enough of one to clean up object cycles.

有兩種主要的記憶體管理技術：引用計數和跟蹤垃圾收集（通常僅稱為“垃圾收集”或“ GC”）⁵。 引用計數器的實現要簡單得多——我想這就是為什麼Perl、PHP和Python一開始都使用該方式的原因。但是，隨著時間的流逝，引用計數的限制變得太麻煩了。 所有這些語言最終都添加了完整的跟蹤GC或至少一種足以清除物件迴圈引用的管理方式。

Tracing garbage collection has a fearsome reputation. It is a little harrowing working at the level of raw memory. Debugging a GC can sometimes leave you seeing hex dumps in your dreams. But, remember, this book is about dispelling magic and slaying those monsters, so we are going to write our own garbage collector. I think you’ll find the algorithm is quite simple and a lot of fun to implement.

追蹤式垃圾收集是一個聽起來就很可怕的名稱。在原始記憶體的層面上工作是有點折磨人的。除錯GC的時候會讓你在夢中也能看到hex dumps。但是，請記住，這本書是關於驅散魔法和殺死那些怪物的，所以我們要寫出自己的垃圾收集器。我想你會發現這個演算法相當簡單，而且實現起來很有趣。

3 . 3 Data Types

3.3 資料型別

In Lox’s little universe, the atoms that make up all matter are the built-in data types. There are only a few:

在Lox的小宇宙中，構成所有物質的原子是內建的資料型別。只有幾個：

Booleans – You can’t code without logic and you can’t logic without Boolean values. “True” and “false”, the yin and yang of software. Unlike some ancient languages that repurpose an existing type to represent truth and falsehood, Lox has a dedicated Boolean type. We may be roughing it on this expedition, but we aren’t savages.

There are two Boolean values, obviously, and a literal for each one:

Booleans——沒有邏輯就不能編碼，沒有布林值也就沒有邏輯⁶。 “真”和“假”，就是軟體的陰與陽。 與某些古老的語言重新利用已有型別來表示真假不同，Lox具有專用的布林型別。在這次探險中，我們可能會有些粗暴，但我們不是野蠻人。

顯然，有兩個布林值，每個值都有一個字面量：

true;  // Not false.
false; // Not *not* false.

Numbers – Lox only has one kind of number: double-precision floating point. Since floating point numbers can also represent a wide range of integers, that covers a lot of territory, while keeping things simple.

Full-featured languages have lots of syntax for numbers—hexadecimal, scientific notation, octal, all sorts of fun stuff. We’ll settle for basic integer and decimal literals:

Numbers——Lox只有一種數字：雙精度浮點數。 由於浮點數還可以表示各種各樣的整數，因此可以覆蓋很多領域，同時保持簡單。

功能齊全的語言具有多種數字語法-十六進位制，科學計數法，八進位制和各種有趣的東西。 我們只使用基本的整數和十進位制文字：

1234;  // An integer.
12.34; // A decimal number.

Strings – We’ve already seen one string literal in the first example. Like most languages, they are enclosed in double quotes:

Strings——在第一個示例中，我們已經看到一個字串字面量。 與大多數語言一樣，它們用雙引號引起來：

"I am a string";
"";    // The empty string.
"123"; // This is a string, not a number.

As we’ll see when we get to implementing them, there is quite a lot of complexity hiding in that innocuous sequence of characters.

我們在實現它們時會看到，在這個看起來無害的字元序列⁷中隱藏了相當多的複雜性。

Nil – There’s one last built-in value who’s never invited to the party but always seems to show up. It represents “no value”. It’s called “null” in many other languages. In Lox we spell it nil. (When we get to implementing it, that will help distinguish when we’re talking about Lox’s nil versus Java or C’s null.)

There are good arguments for not having a null value in a language since null pointer errors are the scourge of our industry. If we were doing a statically-typed language, it would be worth trying to ban it. In a dynamically-typed one, though, eliminating it is often more annoying than having it.

Nil——還有最後一個內建資料，它從未被邀請參加聚會，但似乎總是會出現。 它代表“沒有價值”。 在許多其他語言中稱為“null”。 在Lox中，我們將其拼寫為nil。 （當我們實現它時，這將有助於區分Lox的nil與Java或C的null）

有一些很好的理由表明在語言中不使用空值是合理的，因為空指標錯誤是我們行業的禍害。如果我們使用的是靜態型別語言，那麼禁止它是值得的。然而，在動態型別中，消除它往往比保留它更加麻煩。

3 . 4 Expressions

3.4 表示式

If built-in data types and their literals are atoms, then expressions must be the molecules. Most of these will be familiar.

如果內建資料型別及其字面量是原子，那麼表示式一定是分子。其中大部分大家都很熟悉。

3 . 4 . 1 Arithmetic

3.4.1 算術運算

Lox features the basic arithmetic operators you know and love from C and other languages:

Lox具備了您從C和其他語言中瞭解到的基本算術運算子：

add + me;
subtract - me;
multiply * me;
divide / me;

The subexpressions on either side of the operator are operands. Because there are two of them, these are called binary operators. (It has nothing to do with the ones-and-zeroes use of “binary”.) Because the operator is fixed in the middle of the operands, these are also called infix operators as opposed to prefix operators where the operator comes before and postfix where it follows the operand.

運算子兩邊的子表示式都是運算元。因為有兩個運算元，它們被稱為二元運算子(這與二進位制的1和0二元沒有關聯)。由於運算子固定在運算元的中間，因此也稱為中綴運算子，相對的，還有字首運算子(運算子在運算元前面)和字尾運算子(運算子在運算元後面)⁸。

One arithmetic operator is actually both an infix and a prefix one. The - operator can also be used to negate a number:

有一個數學運算子既是中綴運算子也是字首運算子，-運算子可以對數字取負：

-negateMe;

All of these operators work on numbers, and it’s an error to pass any other types to them. The exception is the + operator—you can also pass it two strings to concatenate them.

所有這些運算子都是針對數字的，將任何其他型別運算元傳遞給它們都是錯誤的。唯一的例外是+運算子——你也可以傳給它兩個字串將它們串接起來。

3 . 4 . 2 Comparison and equality

3.4.2 比較與相等

Moving along, we have a few more operators that always return a Boolean result. We can compare numbers (and only numbers), using Ye Olde Comparison Operators:

接下來，我們有幾個返回布林值的運算子。我們可以使用舊的比較運算子來比較數字(並且只能比較數字)：

less < than;
lessThan <= orEqual;
greater > than;
greaterThan >= orEqual;

We can test two values of any kind for equality or inequality:

我們可以測試兩個任意型別的值是否相等：

1 == 2;         // false.
"cat" != "dog"; // true.

Even different types:

即使是不同型別也可以：

314 == "pi"; // false.

Values of different types are never equivalent:

不同型別的值永遠不會相等：

123 == "123"; // false.

I’m generally against implicit conversions.

我通常是反對隱式轉換的。

3 . 4 . 3 Logical operators

3.4.3 邏輯運算

The not operator, a prefix !, returns false if its operand is true, and vice versa:

取非運算子，是字首運算子!，如果運算元是true，則返回false，反之亦然：

!true;  // false.
!false; // true.

The other two logical operators really are control flow constructs in the guise of expressions. An and expression determines if two values are both true. It returns the left operand if it’s false, or the right operand otherwise:

其他兩個邏輯運算子實際上是表示式偽裝下的控制流結構。and表示式用於確認兩個運算元是否都是true。如果左側運算元是false，則返回左側運算元，否則返回右側運算元：

true and false; // false.
true and true;  // true.

And an or expression determines if either of two values (or both) are true. It returns the left operand if it is true and the right operand otherwise:

or表示式用於確認兩個運算元中任意一個（或者都是）為true。如果左側運算元為true，則返回左側運算元，否則返回右側運算元：

false or false; // false.
true or false;  // true.

The reason and and or are like control flow structures is because they short-circuit. Not only does and return the left operand if it is false, it doesn’t even evaluate the right one in that case. Conversely, (“contrapositively”?) if the left operand of an or is true, the right is skipped.

and和 or之所以像控制流結構，是因為它們會短路⁹。如果左運算元為假，and不僅會返回左運算元，在這種情況下，它甚至不會計算右運算元。反過來，("相對的"?)如果or的左運算元為真，右運算元就會被跳過。

3 . 4 . 4 Precedence and grouping

3.4.4 優先順序與分組

All of these operators have the same precedence and associativity that you’d expect coming from C. (When we get to parsing, we’ll get way more precise about that.) In cases where the precedence isn’t what you want, you can use () to group stuff:

所有這些運算子都具有與c語言相同的優先順序和結合性(當我們開始解析時，會進行更詳細的說明)。在優先順序不滿足要求的情況下，你可以使用()來分組：

var average = (min + max) / 2;

Since they aren’t very technically interesting, I’ve cut the remainder of the typical operator menagerie out of our little language. No bitwise, shift, modulo, or conditional operators. I’m not grading you, but you will get bonus points in my heart if you augment your own implementation of Lox with them.

我把其他典型的運算子從我們的小語言中去掉了，因為它們在技術上不是很有趣。沒有位運算、移位、取模或條件運算子。我不是在給你打分，但如果你透過自己的方式來完成支援這些運算的Lox實現，你會在我心中得到額外的加分。

Those are the expression forms (except for a couple related to specific features that we’ll get to later), so let’s move up a level.

這些都是表示式形式(除了一些與我們將在後面介紹的特定特性相關的)，所以讓我們繼續。

3 . 5 Statements

3.5 語句

Now we’re at statements. Where an expression’s main job is to produce a value, a statement’s job is to produce an effect. Since, by definition, statements don’t evaluate to a value, to be useful they have to otherwise change the world in some way—usually modifying some state, reading input, or producing output.

現在我們來看語句。表示式的主要作用是產生一個值，語句的主要作用是產生一個效果。由於根據定義，語句不求值，因此必須以某種方式改變世界（通常是修改某些狀態，讀取輸入或產生輸出）才能有用。

You’ve seen a couple of kinds of statements already. The first one was:

您已經看到了幾種語句。 第一個是：

print "Hello, world!";

A print statement evaluates a single expression and displays the result to the user. You’ve also seen some statements like:

print語句計算單個表示式並將結果顯示給使用者¹⁰。 您還看到了一些語句，例如：

"some expression";

An expression followed by a semicolon (;) promotes the expression to statement-hood. This is called (imaginatively enough), an expression statement.

表示式後跟分號（;）可以將表示式提升為語句狀態。這被稱為(很有想象力)表示式語句。

If you want to pack a series of statements where a single one is expected, you can wrap them up in a block:

如果您想將一系列語句打包成一個語句，那麼可以將它們打包在一個塊中：

{
  print "One statement.";
  print "Two statements.";
}

Blocks also affect scoping, which leads us to the next section…

塊還會影響作用域，我們將在下一節中進行說明。

3 . 6 Variables

3.6 變數

You declare variables using var statements. If you omit the initializer, the variable’s value defaults to nil:

你可以使用var語句宣告變數。如果你省略了初始化操作，變數的值預設為nil¹¹：

var imAVariable = "here is my value";
var iAmNil;

Once declared, you can, naturally, access and assign a variable using its name:

一旦宣告完成，你自然就可以透過變數名對其進行訪問和賦值：

var breakfast = "bagels";
print breakfast; // "bagels".
breakfast = "beignets";
print breakfast; // "beignets".

I won’t get into the rules for variable scope here, because we’re going to spend a surprising amount of time in later chapters mapping every square inch of the rules. In most cases, it works like you expect coming from C or Java.

我不會在這裡討論變數作用域的規則，因為我們在後面的章節中將會花費大量的時間來詳細討論這些規則。在大多數情況下，它的工作方式與您期望的C或Java一樣。

3 . 7 Control Flow

3.7 控制流

It’s hard to write useful programs if you can’t skip some code, or execute some more than once. That means control flow. In addition to the logical operators we already covered, Lox lifts three statements straight from C.

如果你不能跳過某些程式碼，或者不能多次執行某些程式碼，就很難寫出有用的程式¹²。這意味著控制流。除了我們已經介紹過的邏輯運算子之外，Lox直接從C中借鑑了三條語句。

An if statement executes one of two statements based on some condition:

if語句根據某些條件執行兩條語句中的一條：

if (condition) {
  print "yes";
} else {
  print "no";
}

A while loop executes the body repeatedly as long as the condition expression evaluates to true:

只要條件表示式的計算結果為true，while迴圈就會重複執行迴圈體¹³：

var a = 1;
while (a < 10) {
  print a;
  a = a + 1;
}

Finally, we have for loops:

最後，還有for迴圈：

for (var a = 1; a < 10; a = a + 1) {
  print a;
}

This loop does the same thing as the previous while loop. Most modern languages also have some sort of for-in or foreach loop for explicitly iterating over various sequence types. In a real language, that’s nicer than the crude C-style for loop we got here. Lox keeps it basic.

這個迴圈與之前的 while 迴圈做同樣的事情。大多數現代語言也有某種for-in或foreach迴圈，用於顯式迭代各種序列型別¹⁴。在真正的語言中，這比我們在這裡使用的粗糙的C-風格for迴圈要好。Lox只保持了它的基本功能。

3 . 8 Functions

3.8 函式

A function call expression looks the same as it does in C:

函式呼叫表示式與C語言中一樣：

makeBreakfast(bacon, eggs, toast);

You can also call a function without passing anything to it:

你也可以在不傳遞任何引數的情況下呼叫一個函式：

makeBreakfast();

Unlike, say, Ruby, the parentheses are mandatory in this case. If you leave them off, it doesn’t call the function, it just refers to it.

與Ruby不同的是，在本例中括號是強制性的。如果你把它們去掉，就不會呼叫函式，只是指向該函式。

A language isn’t very fun if you can’t define your own functions. In Lox, you do that with fun:

如果你不能定義自己的函式，一門語言就不能算有趣。在Lox裡，你可以透過fun完成：

fun printSum(a, b) {
  print a + b;
}

Now’s a good time to clarify some terminology. Some people throw around “parameter” and “argument” like they are interchangeable and, to many, they are. We’re going to spend a lot of time splitting the finest of downy hairs around semantics, so let’s sharpen our words. From here on out:

• An argument is an actual value you pass to a function when you call it. So a function call has an argument list. Sometimes you hear actual parameter used for these.
• A parameter is a variable that holds the value of the argument inside the body of the function. Thus, a function declaration has a parameter list. Others call these formal parameters or simply formals.

現在是澄清一些術語的好時機¹⁵。有些人把 "parameter "和 "argument "混為一談，好像它們可以互換，而對許多人來說，它們確實可以互換。我們要花很多時間圍繞語義學來對其進行分辨，所以讓我們在這裡把話說清楚：

• argument是你在呼叫函式時傳遞給它的實際值。所以一個函式呼叫有一個argument列表。有時你會聽到有人用實際引數指代這些引數。
• parameter是一個變數，用於在函式的主體裡面存放引數的值。因此，一個函式宣告有一個parameter列表。也有人把這些稱為形式引數或者乾脆稱為形參。

The body of a function is always a block. Inside it, you can return a value using a return statement:

函式體總是一個塊。在其中，您可以使用return語句返回一個值：

fun returnSum(a, b) {
  return a + b;
}

If execution reaches the end of the block without hitting a return, it implicitly returns nil.

如果執行到達程式碼塊的末尾而沒有return語句，則會隱式返回nil。

3 . 8 . 1 Closures

3.8.1 閉包

Functions are first class in Lox, which just means they are real values that you can get a reference to, store in variables, pass around, etc. This works:

在Lox中，函式是一等公民，這意味著它們都是真實的值，你可以對這些值進行引用、儲存在變數中、傳遞等等。下面的程式碼是有效的：

fun addPair(a, b) {
  return a + b;
}

fun identity(a) {
  return a;
}

print identity(addPair)(1, 2); // Prints "3".

Since function declarations are statements, you can declare local functions inside another function:

由於函式宣告是語句，所以可以在另一個函式中宣告區域性函式：

fun outerFunction() {
  fun localFunction() {
    print "I'm local!";
  }

  localFunction();
}

If you combine local functions, first-class functions, and block scope, you run into this interesting situation:

如果將區域性函式、頭等函式和塊作用域組合在一起，就會遇到這種有趣的情況：

fun returnFunction() {
  var outside = "outside";

  fun inner() {
    print outside;
  }

  return inner;
}

var fn = returnFunction();
fn();

Here, inner() accesses a local variable declared outside of its body in the surrounding function. Is this kosher? Now that lots of languages have borrowed this feature from Lisp, you probably know the answer is yes.

在這裡，inner()訪問了在其函式體外的外部函式中宣告的區域性變數。這樣可行嗎?現在很多語言都從Lisp借鑑了這個特性，你應該也知道答案是肯定的。

For that to work, inner() has to “hold on” to references to any surrounding variables that it uses so that they stay around even after the outer function has returned. We call functions that do this closures. These days, the term is often used for any first-class function, though it’s sort of a misnomer if the function doesn’t happen to close over any variables.

要做到這一點，inner()必須“保留”對它使用的任何周圍變數的引用，這樣即使在外層函式返回之後，這些變數仍然存在。我們把能做到這一點的函式稱為閉包¹⁶。現在，這個術語經常被用於任何頭類函式，但是如果函式沒有在任何變數上閉包，那就有點用詞不當了。

As you can imagine, implementing these adds some complexity because we can no longer assume variable scope works strictly like a stack where local variables evaporate the moment the function returns. We’re going to have a fun time learning how to make these work and do so efficiently.

可以想象，實現這些會增加一些複雜性，因為我們不能再假定變數作用域嚴格地像堆疊一樣工作，在函式返回時區域性變數就消失了。我們將度過一段有趣的時間來學習如何使這些工作，並有效地做到這一點。

3 . 9 Classes

3.9 類

Since Lox has dynamic typing, lexical (roughly, “block”) scope, and closures, it’s about halfway to being a functional language. But as you’ll see, it’s also about halfway to being an object-oriented language. Both paradigms have a lot going for them, so I thought it was worth covering some of each.

因為Lox具有動態型別、詞法(粗略地說，就是塊)作用域和閉包，所以它離函式式語言只有一半的距離。但正如您將看到的，它離成為一種面向物件的語言也有一半的距離。這兩種模式都有很多優點，所以我認為有必要分別介紹一下。

Since classes have come under fire for not living up to their hype, let me first explain why I put them into Lox and this book. There are really two questions:

類因為沒有達到其宣傳效果而受到抨擊，所以讓我先解釋一下為什麼我把它們放到Lox和這本書中。這裡實際上有兩個問題：

3 . 9 . 1 Why might any language want to be object oriented?

3.9.1 為什麼任何語言都想要面向物件？

Now that object-oriented languages like Java have sold out and only play arena shows, it’s not cool to like them anymore. Why would anyone make a new language with objects? Isn’t that like releasing music on 8-track?

現在像Java這樣的面向物件的語言已經銷聲匿跡了，只能在舞臺上表演，喜歡它們已經不酷了。為什麼有人要用物件來做一門新的語言呢？這不就像用磁帶¹⁷發行音樂一樣嗎？

It is true that the “all inheritance all the time” binge of the 90s produced some monstrous class hierarchies, but object-oriented programming is still pretty rad. Billions of lines of successful code have been written in OOP languages, shipping millions of apps to happy users. Likely a majority of working programmers today are using an object-oriented language. They can’t all be that wrong.

90年代的 "一直都是繼承 "的狂潮確實產生了一些畸形的類層次結構，但面向物件的程式設計還是很流行的。數十億行成功的程式碼都是用OOP語言編寫的，為使用者提供了數百萬個應用程式。很可能今天大多數在職程式設計師都在使用面嚮物件語言。他們不可能都錯得那麼離譜。

In particular, for a dynamically-typed language, objects are pretty handy. We need some way of defining compound data types to bundle blobs of stuff together.

特別是，對於動態型別語言來說，物件是非常方便的。我們需要某種方式來定義複合資料型別，用來將一堆資料組合在一起。

If we can also hang methods off of those, then we avoid the need to prefix all of our functions with the name of the data type they operate on to avoid colliding with similar functions for different types. In, say, Racket, you end up having to name your functions like hash-copy (to copy a hash table) and vector-copy (to copy a vector) so that they don’t step on each other. Methods are scoped to the object, so that problem goes away.

如果我們也能把方法掛在這些物件上，那麼我們就不需要把函式操作的資料型別的名字作為函式名稱的字首，以避免與不同型別的類似函式發生衝突。比如說，在Racket中，你最終不得不將你的函式命名為hash-copy(複製一個雜湊表)和vector-copy(複製一個向量)，這樣它們就不會互相覆蓋。方法的作用域是物件，所以這個問題就不存在了。

3 . 9 . 2 Why is Lox object oriented?

3.9.2 為什麼Lox是面向物件的？

I could claim objects are groovy but still out of scope for the book. Most programming language books, especially ones that try to implement a whole language, leave objects out. To me, that means the topic isn’t well covered. With such a widespread paradigm, that omission makes me sad.

我可以說物件確實很吸引人，但仍然超出了本書的範圍。大多數程式語言的書籍，特別是那些試圖實現一門完整語言的書籍，都忽略了物件。對我來說，這意味著這個主題沒有被很好地覆蓋。對於如此廣泛使用的正規化，這種遺漏讓我感到悲傷。

Given how many of us spend all day using OOP languages, it seems like the world could use a little documentation on how to make one. As you’ll see, it turns out to be pretty interesting. Not as hard as you might fear, but not as simple as you might presume, either.

鑑於我們很多人整天都在使用OOP語言，似乎這個世界應該有一些關於如何製作OOP語言的文件。正如你將看到的那樣，事實證明這很有趣。沒有你擔心的那麼難，但也沒有你想象的那麼簡單。

3 . 9 . 3 Classes or prototypes?

3.9.3 類還是原型？

When it comes to objects, there are actually two approaches to them, classes and prototypes. Classes came first, and are more common thanks to C++, Java, C#, and friends. Prototypes were a virtually forgotten offshoot until JavaScript accidentally took over the world.

當涉及物件時，實際上有兩種方法，類和原型。 類最先出現，由於C++、Java、C#和其它近似語言的出現，類更加普遍。直到JavaScript意外地佔領了世界之前，原型幾乎是一個被遺忘的分支。

In a class-based language, there are two core concepts: instances and classes. Instances store the state for each object and have a reference to the instance’s class. Classes contain the methods and inheritance chain. To call a method on an instance, there is always a level of indirection. You look up the instance’s class and then you find the method there:

在基於類的語言中，有兩個核心概念：例項和類。 例項儲存每個物件的狀態，並有一個對例項的類的引用。 類包含方法和繼承鏈。要在例項上呼叫方法，總是存在一箇中間層。您要先查詢例項的類，然後在其中找到方法：

Prototype-based languages merge these two concepts. There are only objects—no classes—and each individual object may contain state and methods. Objects can directly inherit from each other (or “delegate to” in prototypal lingo):

基於原型的語言融合了這兩個概念¹⁸。這裡只有物件——沒有類，而且每個物件都可以包含狀態和方法。物件之間可以直接繼承（或者用原型語言的術語說是 “委託”）：

This means prototypal languages are more fundamental in some way than classes. They are really neat to implement because they’re so simple. Also, they can express lots of unusual patterns that classes steer you away from.

這意味著原型語言在某些方面比類更基礎。 它們實現起來真的很整潔，因為它們很簡單。另外，它們還可以表達很多不尋常的模式，而這些模式是類所不具備的。

But I’ve looked at a lot of code written in prototypal languages—including some of my own devising. Do you know what people generally do with all of the power and flexibility of prototypes? …They use it to reinvent classes.

但是我看過很多用原型語言寫的程式碼——包括我自己設計的一些程式碼。你知道人們一般會怎麼使用原型的強大功能和靈活性嗎？...他們用它來重新發明類。

I don’t know why that is, but people naturally seem to prefer a class-based (“Classic”? “Classy”?) style. Prototypes are simpler in the language, but they seem to accomplish that only by pushing the complexity onto the user. So, for Lox, we’ll save our users the trouble and bake classes right in.

我不知道這是為什麼，但人們自然而然地似乎更喜歡基於類的（經典？優雅？）風格。原型在語言中更簡單，但它們似乎只是透過將複雜性推給使用者來實現的¹⁹。所以，對於Lox來說，我們將省去使用者的麻煩，直接把類包含進去。

3 . 9 . 4 Classes in Lox

3.9.4 Lox中的類

Enough rationale, let’s see what we actually have. Classes encompass a constellation of features in most languages. For Lox, I’ve selected what I think are the brightest stars. You declare a class and its methods like so:

理由已經說夠了，來看看我們實際上擁有什麼。在大多數語言中，類包含了一系列的特性。對於Lox，我選擇了我認為最閃亮的一點。您可以像這樣宣告一個類及其方法：

class Breakfast {
  cook() {
    print "Eggs a-fryin'!";
  }

  serve(who) {
    print "Enjoy your breakfast, " + who + ".";
  }
}

The body of a class contains its methods. They look like function declarations but without the fun keyword. When the class declaration is executed, Lox creates a class object and stores that in a variable named after the class. Just like functions, classes are first class in Lox:

類的主體包含其方法。 它們看起來像函式宣告，但沒有fun關鍵字。 當類宣告生效時，Lox將建立一個類物件，並將其儲存在以該類命名的變數中。就像函式一樣，類在Lox中也是一等公民：

// Store it in variables.
var someVariable = Breakfast;

// Pass it to functions.
someFunction(Breakfast);

Next, we need a way to create instances. We could add some sort of new keyword, but to keep things simple, in Lox the class itself is a factory function for instances. Call a class like a function and it produces a new instance of itself:

接下來，我們需要一種建立例項的方法。我們可以新增某種new關鍵字，但為了簡單起見，在Lox中，類本身是例項的工廠函式。像呼叫函式一樣呼叫一個類，它會生成一個自己的新例項：

var breakfast = Breakfast();
print breakfast; // "Breakfast instance".

3 . 9 . 5 Instantiation and initialization

3.9.5 例項化和初始化

Classes that only have behavior aren’t super useful. The idea behind object-oriented programming is encapsulating behavior and state together. To do that, you need fields. Lox, like other dynamically-typed languages, lets you freely add properties onto objects:

只有行為的類不是非常有用。面向物件程式設計背後的思想是將行為和狀態封裝在一起。為此，您需要有欄位。Lox和其他動態型別語言一樣，允許您自由地向物件新增屬性：

breakfast.meat = "sausage";
breakfast.bread = "sourdough";

Assigning to a field creates it if it doesn’t already exist.

如果一個欄位不存在，那麼對它進行賦值時就會先建立。

If you want to access a field or method on the current object from within a method, you use good old this:

如果您想從方法內部訪問當前物件上的欄位或方法，可以使用this：

class Breakfast {
  serve(who) {
    print "Enjoy your " + this.meat + " and " +
        this.bread + ", " + who + ".";
  }

  // ...
}

Part of encapsulating data within an object is ensuring the object is in a valid state when it’s created. To do that, you can define an initializer. If your class has a method named init(), it is called automatically when the object is constructed. Any parameters passed to the class are forwarded to its initializer:

在物件中封裝資料的目的之一是確保物件在建立時處於有效狀態。為此，你可以定義一個初始化器。如果您的類中包含一個名為init()的方法，則在構造物件時會自動呼叫該方法。傳遞給類的任何引數都會轉發給它的初始化器：

class Breakfast {
  init(meat, bread) {
    this.meat = meat;
    this.bread = bread;
  }

  // ...
}

var baconAndToast = Breakfast("bacon", "toast");
baconAndToast.serve("Dear Reader");
// "Enjoy your bacon and toast, Dear Reader."

3 . 9 . 6 Inheritance

3.9.6 繼承

Every object-oriented language lets you not only define methods, but reuse them across multiple classes or objects. For that, Lox supports single inheritance. When you declare a class, you can specify a class that it inherits from using a less-than (<) operator:

在每一種面向物件的語言中，你不僅可以定義方法，而且可以在多個類或物件中重用它們。為此，Lox支援單繼承。當你宣告一個類時，你可以使用小於(<)運算子指定它繼承的類²⁰：

class Brunch < Breakfast {
  drink() {
    print "How about a Bloody Mary?";
  }
}

Here, Brunch is the derived class or subclass, and Breakfast is the base class or superclass. Every method defined in the superclass is also available to its subclasses:

這裡，Brunch是派生類或子類，而Breakfast是基類或超類。父類中定義的每個方法對其子類也可用：

var benedict = Brunch("ham", "English muffin");
benedict.serve("Noble Reader");

Even the init() method gets inherited. In practice, the subclass usually wants to define its own init() method too. But the original one also needs to be called so that the superclass can maintain its state. We need some way to call a method on our own instance without hitting our own methods.

即使是init()方法也會被繼承。在實踐中，子類通常也想定義自己的init()方法。但還需要呼叫原始的初始化方法，以便超類能夠維護其狀態²¹。我們需要某種方式能夠呼叫自己例項上的方法，而無需觸發例項自身的方法。

As in Java, you use super for that:

與Java中一樣，您可以使用super：

class Brunch < Breakfast {
  init(meat, bread, drink) {
    super.init(meat, bread);
    this.drink = drink;
  }
}

That’s about it for object orientation. I tried to keep the feature set minimal. The structure of the book did force one compromise. Lox is not a pure object-oriented language. In a true OOP language every object is an instance of a class, even primitive values like numbers and Booleans.

這就是面向物件的內容。我儘量將功能設定保持在最低限度。本書的結構確實迫使我做了一個妥協。Lox不是一種純粹的面向物件的語言。在真正的OOP語言中，每個物件都是一個類的例項，即使是像數字和布林值這樣的基本型別。

Because we don’t implement classes until well after we start working with the built-in types, that would have been hard. So values of primitive types aren’t real objects in the sense of being instances of classes. They don’t have methods or properties. If I were trying to make Lox a real language for real users, I would fix that.

因為我們開始使用內建型別很久之後才會實現類，所以這一點很難實現。因此，從類例項的意義上說，基本型別的值並不是真正的物件。它們沒有方法或屬性。如果以後我想讓Lox成為真正的使用者使用的語言，我會解決這個問題。

3 . 10 The Standard Library

3.10 標準庫

We’re almost done. That’s the whole language, so all that’s left is the “core” or “standard” library—the set of functionality that is implemented directly in the interpreter and that all user-defined behavior is built on top of.

我們快結束了，這就是整個語言，所剩下的就是“核心”或“標準”庫——這是一組直接在直譯器中實現的功能集，所有使用者定義的行為都是建立在此之上。

This is the saddest part of Lox. Its standard library goes beyond minimalism and veers close to outright nihilism. For the sample code in the book, we only need to demonstrate that code is running and doing what it’s supposed to do. For that, we already have the built-in print statement.

這是Lox中最可悲的部分。它的標準庫已經超過了極簡主義，接近徹底的虛無主義。對於本書中的示例程式碼，我們只需要證明程式碼在執行，並且在做它應該做的事。為此，我們已經有了內建的print語句。

Later, when we start optimizing, we’ll write some benchmarks and see how long it takes to execute code. That means we need to track time, so we’ll define one built-in function clock() that returns the number of seconds since the program started.

稍後，當我們開始最佳化時，我們將編寫一些基準測試，看看執行程式碼需要多長時間。這意味著我們需要跟蹤時間，因此我們將定義一個內建函式clock()，該函式會返回程式啟動後的秒數。

And… that’s it. I know, right? It’s embarrassing.

嗯...就是這樣。 我知道，有點尷尬，對吧？

If you wanted to turn Lox into an actual useful language, the very first thing you should do is flesh this out. String manipulation, trigonometric functions, file I/O, networking, heck, even reading input from the user would help. But we don’t need any of that for this book, and adding it wouldn’t teach you anything interesting, so I left it out.

如果您想將Lox變成一門實際可用的語言，那麼您應該做的第一件事就是對其充實。 字串操作、三角函式、檔案I / O、網路、擴充套件，甚至讀取使用者的輸入都將有所幫助。但對於本書來說，我們不需要這些，而且加入這些也不會教給你任何有趣的東西，所以我把它省略了。

Don’t worry, we’ll have plenty of exciting stuff in the language itself to keep us busy.

別擔心，這門語言本身就有很多精彩的內容讓我們忙個不停。

CHALLENGES

習題

1、Write some sample Lox programs and run them (you can use the implementations of Lox in my repository). Try to come up with edge case behavior I didn’t specify here. Does it do what you expect? Why or why not?

1、編寫一些示例Lox程式並執行它們(您可以使用我的Lox實現)。試著想出我在這裡沒有詳細說明的邊界情況。它是否按照期望執行？為什麼？

2、This informal introduction leaves a lot unspecified. List several open questions you have about the language’s syntax and semantics. What do you think the answers should be?

2、這種非正式的介紹留下了很多未說明的東西。列出幾個關於語言語法和語義的開放問題。你認為答案應該是什麼？

3、Lox is a pretty tiny language. What features do you think it is missing that would make it annoying to use for real programs? (Aside from the standard library, of course.)

3、Lox是一種很小的語言。 您認為缺少哪些功能會使其不適用於實際程式？ （當然，除了標準庫。）

DESIGN NOTE: EXPRESSIONS AND STATEMENTS

設計筆記：表示式和語句

Lox has both expressions and statements. Some languages omit the latter. Instead, they treat declarations and control flow constructs as expressions too. These “everything is an expression” languages tend to have functional pedigrees and include most Lisps, SML, Haskell, Ruby, and CoffeeScript.

To do that, for each “statement-like” construct in the language, you need to decide what value it evaluates to. Some of those are easy:

• An if expression evaluates to the result of whichever branch is chosen. Likewise, a switch or other multi-way branch evaluates to whichever case is picked.
• A variable declaration evaluates to the value of the variable.
• A block evaluates to the result of the last expression in the sequence.

Some get a little stranger. What should a loop evaluate to? A while loop in CoffeeScript evaluates to an array containing each element that the body evaluated to. That can be handy, or a waste of memory if you don’t need the array.

You also have to decide how these statement-like expressions compose with other expressions—you have to fit them into the grammar’s precedence table. For example, Ruby allows:

puts 1 + if true then 2 else 3 end + 4

Is this what you’d expect? Is it what your users expect? How does this affect how you design the syntax for your “statements”? Note that Ruby has an explicit end to tell when the if expression is complete. Without it, the + 4 would likely be parsed as part of the else clause.

Turning every statement into an expression forces you to answer a few hairy questions like that. In return, you eliminate some redundancy. C has both blocks for sequencing statements, and the comma operator for sequencing expressions. It has both the if statement and the ?: conditional operator. If everything was an expression in C, you could unify each of those.

Languages that do away with statements usually also feature implicit returns—a function automatically returns whatever value its body evaluates to without need for some explicit return syntax. For small functions and methods, this is really handy. In fact, many languages that do have statements have added syntax like => to be able to define functions whose body is the result of evaluating a single expression.

But making all functions work that way can be a little strange. If you aren’t careful, your function will leak a return value even if you only intend it to produce a side effect. In practice, though, users of these languages don’t find it to be a problem.

For Lox, I gave it statements for prosaic reasons. I picked a C-like syntax for familiarity’s sake, and trying to take the existing C statement syntax and interpret it like expressions gets weird pretty fast.

Lox既有表示式也有語句。有些語言省略了後者。相對地，它們將宣告和控制流結構也視為表示式。這類 "一切都是表示式" 的語言往往具有函式式的血統，包括大多數Lisps、SML、Haskell、Ruby和CoffeeScript。

要做到這一點，對於語言中的每一個 "類似於語句" 的構造，你需要決定它所計算的值是什麼。其中有些很簡單：

• if表示式的計算結果是所選分支的結果。同樣，switch或其他多路分支的計算結果取決於所選擇的情況。
• 變數宣告的計算結果是變數的值。
• 塊的計算結果是序列中最後一個表示式的結果。

有一些是比較複雜的。迴圈應該計算什麼值？在CoffeeScript中，一個while迴圈計算結果為一個陣列，其中包含了迴圈體中計算到的每個元素。這可能很方便，但如果你不需要這個陣列，就會浪費記憶體。

您還必須決定這些類似語句的表示式如何與其他表示式組合，必須將它們放入語法的優先表中。例如，Ruby允許下面這種寫法：

puts 1 + if true then 2 else 3 end + 4

這是你所期望的嗎？這是你的使用者所期望的嗎？這對你如何設計 "語句 "的語法有什麼影響？請注意，Ruby有一個顯式的end關鍵字來表明if表示式結束。如果沒有它，+4很可能會被解析為 else子句的一部分。

把每個語句都轉換成表示式會迫使你回答一些類似這樣的複雜問題。作為回報，您消除了一些冗餘。C語言中既有用於排序語句的塊，以及用於排序表示式的逗號運算子。它既有if語句，也有?:條件運算子。如果在C語言中所有東西都是表示式，你就可以把它們統一起來。

取消了語句的語言通常還具有隱式返回的特點——函式自動返回其函式主體所計算得到的任何值，而不需要顯式的return語法。對於小型函式和方法來說，這真的很方便。事實上，許多有語句的語言都添加了類似於 => 的語法，以便能夠定義函式體是計算單一表達式結果的函式。

但是讓所有的函式以這種方式工作可能有點奇怪。即使你只是想讓函式產生副作用，如果不小心，函式也可能會洩露返回值。但實際上，這些語言的使用者並不覺得這是一個問題。

對於Lox，我在其中新增語句是出於樸素的原因。為了熟悉起見，我選擇了一種類似於C的語法，而試圖把現有的C語句語法像表示式一樣解釋，會很快變得奇怪。

1. 如果你不親自執行程式碼，那教程就毫無意義。唉，你還沒有Lox直譯器，因為你還沒有建立一個!不要害怕。你可以用我的。 ↩

2. 我肯定有偏見，但我認為Lox的語法很乾淨。 C語言最嚴重的語法問題就是關於型別的。丹尼斯·裡奇（Dennis Ritchie）有個想法叫“宣告反映使用”，其中變數宣告反映了為獲得基本型別的值而必須對變數執行的操作。這主意不錯，但是我認為實踐中效果不太好。Lox沒有靜態型別，所以我們避免了這一點。 ↩

3. 現在，JavaScript已席捲全球，並已用於構建大量應用程式，很難將其視為“小指令碼語言”。但是Brendan Eich曾在十天內將第一個JS直譯器嵌入了Netscape Navigator，以使網頁上的按鈕具有動畫效果。 從那時起，JavaScript逐漸發展起來，但是它曾經是一種可愛的小語言。因為Eich大概只用了一集MacGyver的時間把JS糅合在一起，所以它有一些奇怪的語義，會有明顯的拼湊痕跡。比如變數提升、動態繫結this、陣列中的漏洞和隱式轉換等。我有幸在Lox上多花了點時間，所以它應該更乾淨一些。 ↩

4. 畢竟，我們用於實現Lox的兩種語言都是靜態型別的。 ↩

5. 在實踐中，引用計數和追蹤更像是連續體的兩端，而不是對立的雙方。大多數引用計數系統最終會執行一些跟蹤來處理迴圈，如果你仔細觀察的話，分代收集器的寫屏障看起來有點像保留呼叫。有關這方面的更多資訊，請參閱垃圾收集統一理論(PDF)。 ↩

6. 布林變數是Lox中唯一以人名George Boole命名的資料型別，這也是為什麼 "Boolean "是大寫的原因。他死於1864年，比數字計算機把他的代數變成電子資訊的時間早了近一個世紀。我很好奇他看到自己的名字出現在數十億行Java程式碼中時會怎麼想。 ↩

7. 就連那個 "character "一詞也是個騙局。是ASCII碼？是Unicode？一個碼點，還是一個 "字詞群"？字元是如何編碼的？每個字元是固定的大小，還是可以變化的？ ↩

8. 有些運算子有兩個以上的運算元，並且運算子與運算元之間是交錯的。唯一廣泛使用的是C及其相近語言中的“條件”或“三元”運算子:condition ?thenArm: elseArm;，有些人稱這些為mixfix運算子。有一些語言允許您定義自己的運算子，並控制它們的定位方式——它們的 "固定性"。。 ↩

9. 我使用了and和or，而不是&&和||，因為Lox不使用&和|作為位元運算子。不存在單字元形式的情況下引入雙字元形式感覺很奇怪。我喜歡用單詞來表示運算，也是因為它們實際上是控制流結構，而不是簡單的運算子。 ↩

10. 將 print 融入到語言中，而不是僅僅將其作為一個核心庫函式，這是一種入侵。但對我們來說，這是一個很有用的“入侵”：這意味著在我們實現所有定義函式、按名稱查詢和呼叫函式所需的機制之前，我們的直譯器可以就開始產生輸出。 ↩

11. 這是一種情況，沒有nil並強制每個變數初始化為某個值，會比處理nil本身更麻煩。 ↩

12. 我們已經有and和or可以進行分支處理，我們可以用遞迴來重複程式碼，所以理論上這就足夠了。但是，在命令式語言中這樣程式設計會很尷尬。另一方面，Scheme沒有內建的迴圈結構。它確實依賴遞迴進行重複執行程式碼。Smalltalk沒有內建的分支結構，並且依賴動態分派來選擇性地執行程式碼。 ↩

13. 我沒有在Lox中使用do-while迴圈，因為它們並不常見，相比while迴圈也沒有多餘的內涵。如果你高興的話，就把它加入到你的實現中去吧。你自己做主。 ↩

14. 這是我做出的讓步，因為本書中的實現是按章節劃分的。for-in迴圈需要迭代器協議中的某種動態分派來處理不同型別的序列，但我們完成控制流之後才能實現這種分派。我們可以回過頭來，新增for-in迴圈，但我認為這樣做不會教給你什麼超級有趣的東西。 ↩

15. 說到術語，一些靜態型別的語言，比如C語言，會對函式的宣告和定義進行區分。宣告是將函式的型別和它的名字繫結在一起，所以呼叫時可以進行型別檢查，但不提供函式體。定義也會填入函式的主體，這樣就可以進行編譯。由於Lox是動態型別的，所以這種區分沒有意義。一個函式宣告完全指定了函式，包括它的主體。 ↩

16. Peter J. Landin創造了這個詞。沒錯，幾乎一半的程式語言術語都是他創造的。它們中的大部分都出自一篇不可思議的論文 "The Next 700 Programming Languages"。為了實現這類函式，您需要建立一個資料結構，將函式程式碼和它所需要的周圍變數繫結在一起。他稱它為“閉包”，是因為函式“閉合”並保留了它需要的變數。 ↩

17. 這裡的8軌音樂指的是磁帶。在中國大陸，通常“磁帶”或者“錄音帶”一詞都指緊湊音訊盒帶，因為它的應用非常廣泛。在中國臺灣，reel-to-reel tape被稱為盤式錄音帶、緊湊音訊盒帶（Compact audio cassette）被稱為卡式錄音帶、8軌軟片（8-track cartridges)）被稱為匣式錄音帶。 ↩

18. 實際上，基於類的語言和基於原型的語言之間的界限變得模糊了。JavaScript的“建構函式”概念使您很難定義類物件。 同時，基於類的Ruby非常樂意讓您將方法附加到單個例項中。 ↩

19. Perl的發明家/先知Larry Wall將其稱為“水床理論”。 某些複雜性是必不可少的，無法消除。 如果在某個位置將其向下推，則在另一個位置會出現膨脹。原型語言並沒有消除類的複雜性，因為它們確實讓使用者透過構建近似類的超程式設計庫來承擔這種複雜性。 ↩

20. 為什麼用<運算子？我不喜歡引入一個新的關鍵字，比如extends。Lox不使用:來做其他事情，所以我也不想保留它。相反，我借鑑了Ruby的做法，使用了<。如果你瞭解任何型別理論，你會發現這並不是一個完全任意的選擇。一個子類的每一個例項也是它的超類的一個例項，但可能有超類的例項不是子類的例項。這意味著，在物件的宇宙中，子類物件的集合比超類的集合要小，儘管型別迷們通常用<:來表示這種關係。 ↩

21. Lox不同於不繼承建構函式的c++、Java和c#，而是類似於Smalltalk和Ruby，它們繼承了建構函式。 ↩

II. A TREE-WALK INTERPRETER

With this part, we begin jlox, the first of our two interpreters. Programming languages are a huge topic with piles of concepts and terminology to cram into your brain all at once. Programming language theory requires a level of mental rigor that you probably haven’t had to summon since your last calculus final. (Fortunately there isn’t too much theory in this book.)

在這部分中，我們開始學習jlox，這是我們兩個解釋器中的第一個。編程語言是一個巨大的話題，其中有大量的概念和術語需要一下子塞進你的大腦。編程語言理論需要一定程度的腦力投入，你可能自上次微積分期末考試後就沒這麼投入過了。(幸運的是，這本書沒有太多的理論。)

Implementing an interpreter uses a few architectural tricks and design patterns uncommon in other kinds of applications, so we’ll be getting used to the engineering side of things too. Given all of that, we’ll keep the code we have to write as simple and plain as possible.

實現一個解釋器需要一些架構技巧和設計模式，這在其他類型的應用程序中是不常見的，所以我們也要習慣於工程方面的東西。考慮到這些，我們會盡可能地讓代碼簡單明瞭。

In less than two thousand lines of clean Java code, we’ll build a complete interpreter for Lox that implements every single feature of the language, exactly as we’ve specified. The first few chapters work front-to-back through the phases of the interpreter—scanning, parsing, and evaluating code. After that, we add language features one at a time, growing a simple calculator into a full-fledged scripting language.

在不到2000行簡潔的Java代碼中，我們將為Lox構建一個完整的解釋器，完全按照我們指定的方式實現該語言的每一個功能。前幾章從頭到尾介紹解釋器的各個階段——掃描、解析和計算代碼。之後，我們逐步添加語言特性，將一個簡單的計算器發展成一種成熟的腳本語言。

4.掃描 Scanning

Take big bites. Anything worth doing is worth overdoing.

​ —— Robert A. Heinlein, Time Enough for Love

大幹特工。每件值得做的事都要盡力做好。

The first step in any compiler or interpreter is scanning. The scanner takes in raw source code as a series of characters and groups it into a series of chunks we call tokens. These are the meaningful “words” and “punctuation” that make up the language’s grammar.

任何編譯器或直譯器的第一步都是掃描¹。掃描器以一系列字元的形式接收原始原始碼，並將其分組成一系列的塊，我們稱之為標識（詞法單元）。這些是有意義的 "單詞 "和 "標點"，它們構成了語言的語法。

Scanning is a good starting point for us too because the code isn’t very hard—pretty much a switch statement with delusions of grandeur. It will help us warm up before we tackle some of the more interesting material later. By the end of this chapter, we’ll have a full-featured, fast scanner that can take any string of Lox source code and produce the tokens that we’ll feed into the parser in the next chapter.

對於我們來說，掃描也是一個很好的起點，因為程式碼不是很難——相當於有很多分支的switch語句。這可以幫助我們在學習更後面有趣的部分之前進行熱身。在本章結束時，我們將擁有一個功能齊全、速度快的掃描器，它可以接收任何一串Lox原始碼，併產生標記，我們將在下一章把這些標記輸入到解析器中。

4 . 1 The Interpreter Framework

4.1 直譯器框架

Since this is our first real chapter, before we get to actually scanning some code we need to sketch out the basic shape of our interpreter, jlox. Everything starts with a class in Java.

由於這是我們的第一個真正的章節，在我們開始實際掃描程式碼之前，我們需要先勾勒出我們的直譯器jlox的基本形態。在Java中，一切都是從一個類開始的。

【譯者注：原作者在程式碼的側邊欄標註了程式碼名及對應的操作（建立檔案、追加程式碼、刪除程式碼等），由於翻譯版的格式受限，將這部分資訊遷移到程式碼塊之前，以帶下劃線的斜體突出，後同】

lox/Lox.java，建立新檔案²

package com.craftinginterpreters.lox;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.nio.charset.Charset;
import java.nio.file.Files;
import java.nio.file.Paths;
import java.util.List;

public class Lox {
  public static void main(String[] args) throws IOException {
    if (args.length > 1) {
      System.out.println("Usage: jlox [script]");
      System.exit(64); 
    } else if (args.length == 1) {
      runFile(args[0]);
    } else {
      runPrompt();
    }
  }
}

Stick that in a text file, and go get your IDE or Makefile or whatever set up. I’ll be right here when you’re ready. Good? OK!

把它貼在一個文字檔案裡，然後去把你的IDE或者Makefile或者其他工具設定好。我就在這裡等你準備好。好了嗎？好的！

Lox is a scripting language, which means it executes directly from source. Our interpreter supports two ways of running code. If you start jlox from the command line and give it a path to a file, it reads the file and executes it.

Lox是一種指令碼語言，這意味著它直接從原始碼執行。我們的直譯器支援兩種執行程式碼的方式。如果從命令列啟動jlox併為其提供檔案路徑，它將讀取該檔案並執行。

lox/Lox.java，新增到main()方法之後

private static void runFile(String path) throws IOException {
  byte[] bytes = Files.readAllBytes(Paths.get(path));
  run(new String(bytes, Charset.defaultCharset()));
}

If you want a more intimate conversation with your interpreter, you can also run it interactively. Fire up jlox without any arguments, and it drops you into a prompt where you can enter and execute code one line at a time.

如果你想與你的直譯器對話, 可以互動式的啟動它。 啟動的時候不加任何引數就可以了，它會有一個提示符，你可以在提示符處一次輸入並執行一行程式碼。

lox/Lox.java，新增到runFile()方法之後³

private static void runPrompt() throws IOException {
  InputStreamReader input = new InputStreamReader(System.in);
  BufferedReader reader = new BufferedReader(input);

  for (;;) { 
    System.out.print("> ");
    String line = reader.readLine();
    if (line == null) break;
    run(line);
  }
}

The readLine() function, as the name so helpfully implies, reads a line of input from the user on the command line and returns the result. To kill an interactive command-line app, you usually type Control-D. Doing so signals an “end-of-file” condition to the program. When that happens readLine() returns null, so we check for that to exit the loop.

readLine()函式，顧名思義，讀取使用者在命令列上的一行輸入，並返回結果。要終止互動式命令列應用程式，通常需要輸入Control-D。這樣做會向程式發出 "檔案結束" 的訊號。當這種情況發生時，readLine()就會返回null，所以我們檢查一下是否存在null以退出迴圈。

Both the prompt and the file runner are thin wrappers around this core function:

互動式提示符和檔案執行工具都是對這個核心函式的簡單包裝：

lox/Lox.java，新增到runPrompt()之後

  private static void run(String source) {
    Scanner scanner = new Scanner(source);
    List<Token> tokens = scanner.scanTokens();

    // For now, just print the tokens.
    for (Token token : tokens) {
      System.out.println(token);
    }
  }

It’s not super useful yet since we haven’t written the interpreter, but baby steps, you know? Right now, it prints out the tokens our forthcoming scanner will emit so that we can see if we’re making progress.

因為我們還沒有寫出直譯器，所以這些程式碼還不是很有用，但這只是小步驟，你要明白？現在，它可以打印出我們即將完成的掃描器所返回的標記，這樣我們就可以看到我們的解析是否生效。

4 . 1 . 1 Error handling

4.1.1 錯誤處理

While we’re setting things up, another key piece of infrastructure is error handling. Textbooks sometimes gloss over this because it’s more a practical matter than a formal computer science-y problem. But if you care about making a language that’s actually usable, then handling errors gracefully is vital.

當我們設定東西的時候，另一個關鍵的基礎設施是錯誤處理。教科書有時會掩蓋這一點，因為這更多的是一個實際問題，而不是一個正式的電腦科學問題。但是，如果你關心的是如何製作一個真正可用的語言，那麼優雅地處理錯誤是至關重要的。

The tools our language provides for dealing with errors make up a large portion of its user interface. When the user’s code is working, they aren’t thinking about our language at all—their headspace is all about their program. It’s usually only when things go wrong that they notice our implementation.

我們的語言提供的處理錯誤的工具構成了其使用者介面的很大一部分。當使用者的程式碼在工作時，他們根本不會考慮我們的語言——他們的腦子裡都是他們的程式。通常只有當程式出現問題時，他們才會注意到我們的實現。

When that happens, it’s up to us to give the user all the information they need to understand what went wrong and guide them gently back to where they are trying to go. Doing that well means thinking about error handling all through the implementation of our interpreter, starting now.

當這種情況發生時，我們就需要向用戶提供他們所需要的所有資訊，讓他們瞭解哪裡出了問題，並引導他們慢慢達到他們想要去的地方。要做好這一點，意味著從現在開始，在直譯器的整個實現過程中都要考慮錯誤處理⁴。

lox/Lox.java，新增到run()方法之後

static void error(int line, String message) {
    report(line, "", message);
  }

  private static void report(int line, String where,
                             String message) {
    System.err.println(
        "[line " + line + "] Error" + where + ": " + message);
    hadError = true;
  }

This error() function and its report() helper tells the user some syntax error occurred on a given line. That is really the bare minimum to be able to claim you even have error reporting. Imagine if you accidentally left a dangling comma in some function call and the interpreter printed out:

這個error()函式和其工具方法report()會告訴使用者在某一行上發生了一些語法錯誤。這其實是最起碼的，可以說你有錯誤報告功能。想象一下，如果你在某個函式呼叫中不小心留下了一個懸空的逗號，直譯器就會打印出來：

Error: Unexpected "," somewhere in your code. Good luck finding it!

That’s not very helpful. We need to at least point them to the right line. Even better would be the beginning and end column so they know where in the line. Even better than that is to show the user the offending line, like:

這種資訊沒有多大幫助。我們至少要給他們指出正確的方向。好一些的做法是指出開頭和結尾一欄，這樣他們就知道這一行的位置了。更好的做法是向用戶顯示違規的行，比如：

Error: Unexpected "," in argument list.

    15 | function(first, second,);
                               ^-- Here.

I’d love to implement something like that in this book but the honest truth is that it’s a lot of grungy string manipulation code. Very useful for users, but not super fun to read in a book and not very technically interesting. So we’ll stick with just a line number. In your own interpreters, please do as I say and not as I do.

我很想在這本書裡實現這樣的東西，但老實說，這會引入很多繁瑣的字串操作程式碼。這些程式碼對使用者來說非常有用，但在書中讀起來並不友好，而且技術上也不是很有趣。所以我們還是隻用一個行號。在你們自己的直譯器中，請按我說的做，而不是按我做的做。

The primary reason we’re sticking this error reporting function in the main Lox class is because of that hadError field. It’s defined here:

我們在Lox主類中堅持使用這個錯誤報告功能的主要原因就是因為那個hadError欄位。它的定義在這裡：

lox/Lox.java 在Lox類中新增：

public class Lox {
  static boolean hadError = false;

We’ll use this to ensure we don’t try to execute code that has a known error. Also, it lets us exit with a non-zero exit code like a good command line citizen should.

我們將以此來確保我們不會嘗試執行有已知錯誤的程式碼。此外，它還能讓我們像一個好的命令列工具那樣，用一個非零的結束程式碼退出。

lox/Lox.java，在runFile()中新增：

    run(new String(bytes, Charset.defaultCharset()));
    
    // Indicate an error in the exit code.
    if (hadError) System.exit(65);
  }

We need to reset this flag in the interactive loop. If the user makes a mistake, it shouldn’t kill their entire session.

我們需要在互動式迴圈中重置此標誌。 如果使用者輸入有誤，也不應終止整個會話。

lox/Lox.java，在runPrompt()中新增：

      run(line);
      hadError = false;
    }

The other reason I pulled the error reporting out here instead of stuffing it into the scanner and other phases where the error might occur is to remind you that it’s good engineering practice to separate the code that generates the errors from the code that reports them.

我把錯誤報告拉出來，而不是把它塞進掃描器和其他可能發生錯誤的階段，還有另一個原因，是為了提醒您，把產生錯誤的程式碼和報告錯誤的程式碼分開是一個很好的工程實踐。

Various phases of the front end will detect errors, but it’s not really their job to know how to present that to a user. In a full-featured language implementation, you will likely have multiple ways errors get displayed: on stderr, in an IDE’s error window, logged to a file, etc. You don’t want that code smeared all over your scanner and parser.

前端的各個階段都會檢測到錯誤，但是它們不需要知道如何向用戶展示錯誤。在一個功能齊全的語言實現中，可能有多種方式展示錯誤資訊：在stderr，在IDE的錯誤視窗中，記錄到檔案，等等。您肯定不希望掃描器和直譯器中到處充斥著這類程式碼。

Ideally, we would have an actual abstraction, some kind of “ErrorReporter” interface that gets passed to the scanner and parser so that we can swap out different reporting strategies. For our simple interpreter here, I didn’t do that, but I did at least move the code for error reporting into a different class.

理想情況下，我們應該有一個實際的抽象，即傳遞給掃描程式和解析器的某種ErrorReporter介面⁵，這樣我們就可以交換不同的報告策略。對於我們這裡的簡單直譯器，我沒有那樣做，但我至少將錯誤報告程式碼移到了一個不同的類中。

With some rudimentary error handling in place, our application shell is ready. Once we have a Scanner class with a scanTokens() method, we can start running it. Before we get to that, let’s get more precise about what tokens are.

有了一些基本的錯誤處理，我們的應用程式外殼已經準備好了。一旦我們有了一個帶有 scanTokens() 方法的 Scanner 類，我們就可以開始執行它了。在我們開始之前，讓我們更精確地瞭解什麼是標記（tokens）。

4 . 2 Lexemes and Tokens

4.2 詞素和標記（詞法單元）

下面是一行lox程式碼：

var language = "lox";

Here, var is the keyword for declaring a variable. That three-character sequence “v-a-r” means something. But if we yank three letters out of the middle of language, like “g-u-a”, those don’t mean anything on their own.

在這裡，var是宣告變數的關鍵字。“v-a-r”這三個字元的序列是有意義的。但如果我們從language中間抽出三個字母，比如“g-u-a”，它們本身並沒有任何意義。

That’s what lexical analysis is about. Our job is to scan through the list of characters and group them together into the smallest sequences that still represent something. Each of these blobs of characters is called a lexeme. In that example line of code, the lexemes are:

這就是詞法分析的意義所在。我們的工作是掃描字元列表，並將它們歸納為具有某些含義的最小序列。每一組字元都被稱為詞素。在示例程式碼行中，詞素是：

The lexemes are only the raw substrings of the source code. However, in the process of grouping character sequences into lexemes, we also stumble upon some other useful information. When we take the lexeme and bundle it together with that other data, the result is a token. It includes useful stuff like:

詞素只是原始碼的原始子字串。 但是，在將字元序列分組為詞素的過程中，我們也會發現了一些其他有用的資訊。 當我們獲取詞素並將其與其他資料捆綁在一起時，結果是一個標記（token，詞法單元）。它包含一些有用的內容，比如：

4 . 2 . 1 Token type

4.2.1 標記型別

Keywords are part of the shape of the language’s grammar, so the parser often has code like, “If the next token is while then do . . . ” That means the parser wants to know not just that it has a lexeme for some identifier, but that it has a reserved word, and which keyword it is.

關鍵詞是語言語法的一部分，所以解析器經常會有這樣的程式碼："如果下一個標記是while，那麼就……" 。這意味著解析器想知道的不僅僅是它有某個識別符號的詞素，而是它得到一個保留詞，以及它是哪個關鍵詞。

The parser could categorize tokens from the raw lexeme by comparing the strings, but that’s slow and kind of ugly. Instead, at the point that we recognize a lexeme, we also remember which kind of lexeme it represents. We have a different type for each keyword, operator, bit of punctuation, and literal type.

解析器可以透過比較字串對原始詞素中的標記進行分類，但這樣做很慢，而且有點難看⁶。相反，在我們識別一個詞素的時候，我們還要記住它代表的是哪種詞素。我們為每個關鍵字、運算子、標點位和字面量都有不同的型別。

lox/TokenType.java 建立新檔案

package com.craftinginterpreters.lox;

enum TokenType {
  // Single-character tokens.
  LEFT_PAREN, RIGHT_PAREN, LEFT_BRACE, RIGHT_BRACE,
  COMMA, DOT, MINUS, PLUS, SEMICOLON, SLASH, STAR,

  // One or two character tokens.
  BANG, BANG_EQUAL,
  EQUAL, EQUAL_EQUAL,
  GREATER, GREATER_EQUAL,
  LESS, LESS_EQUAL,

  // Literals.
  IDENTIFIER, STRING, NUMBER,

  // Keywords.
  AND, CLASS, ELSE, FALSE, FUN, FOR, IF, NIL, OR,
  PRINT, RETURN, SUPER, THIS, TRUE, VAR, WHILE,

  EOF
}

4 . 2 . 2 Literal value

4.2.2 字面量

There are lexemes for literal values—numbers and strings and the like. Since the scanner has to walk each character in the literal to correctly identify it, it can also convert that textual representation of a value to the living runtime object that will be used by the interpreter later.

字面量有對應詞素——數字和字串等。由於掃描器必須遍歷文字中的每個字元才能正確識別，所以它還可以將值的文字表示轉換為執行時物件，直譯器後續將使用該物件。

4 . 2 . 3 Location information

4.2.3 位置資訊

Back when I was preaching the gospel about error handling, we saw that we need to tell users where errors occurred. Tracking that starts here. In our simple interpreter, we note only which line the token appears on, but more sophisticated implementations include the column and length too.

早在我宣講錯誤處理的福音時，我們就看到，我們需要告訴使用者錯誤發生在哪裡。（使用者）從這裡開始定位問題。在我們的簡易直譯器中，我們只說明瞭標記出現在哪一行上，但更復雜的實現中還應該包括列位置和長度⁷。

We take all of this data and wrap it in a class.

我們將所有這些資料打包到一個類中。

lox/Token.java，建立新檔案

package com.craftinginterpreters.lox;

class Token {
  final TokenType type;
  final String lexeme;
  final Object literal;
  final int line; 

  Token(TokenType type, String lexeme, Object literal, int line) {
    this.type = type;
    this.lexeme = lexeme;
    this.literal = literal;
    this.line = line;
  }

  public String toString() {
    return type + " " + lexeme + " " + literal;
  }
}

Now we have an object with enough structure to be useful for all of the later phases of the interpreter.

現在我們有了一個資訊充分的物件，足以支撐直譯器的所有後期階段。

4 . 3 Regular Languages and Expressions

4.3 正則語言和表示式

Now that we know what we’re trying to produce, let’s, well, produce it. The core of the scanner is a loop. Starting at the first character of the source code, it figures out what lexeme it belongs to, and consumes it and any following characters that are part of that lexeme. When it reaches the end of that lexeme, it emits a token.

既然我們已知道我們要輸出什麼，那麼，我們就開始吧。掃描器的核心是一個迴圈。從原始碼的第一個字元開始，掃描器計算出該字元屬於哪個詞素，並消費它和屬於該詞素的任何後續字元。當到達該詞素的末尾時，掃描器會輸出一個標記（詞法單元 token）。

Then it loops back and does it again, starting from the very next character in the source code. It keeps doing that, eating characters and occasionally, uh, excreting tokens, until it reaches the end of the input.

然後再迴圈一次，它又迴圈回來，從原始碼中的下一個字元開始再做一次。它一直這樣做，吃掉字元，偶爾，呃，排出標記，直到它到達輸入的終點。

The part of the loop where we look at a handful of characters to figure out which kind of lexeme it “matches” may sound familiar. If you know regular expressions, you might consider defining a regex for each kind of lexeme and using those to match characters. For example, Lox has the same rules as C for identifiers (variable names and the like). This regex matches one:

在迴圈中，我們會檢視一些字元，以確定它 "匹配 "的是哪種詞素，這部分內容可能聽起來很熟悉，但如果你知道正規表示式，你可以考慮為每一種詞素定義一個regex，並使用這些regex來匹配字元。例如，Lox對識別符號（變數名等）的規則與C語言相同。下面的regex可以匹配一個識別符號：

[a-zA-Z_][a-zA-Z_0-9]*

If you did think of regular expressions, your intuition is a deep one. The rules that determine how a particular language groups characters into lexemes are called its lexical grammar. In Lox, as in most programming languages, the rules of that grammar are simple enough for the language to be classified a regular language. That’s the same “regular” as in regular expressions.

如果你確實想到了正規表示式，那麼你的直覺還是很深刻的。決定一門語言如何將字元分組為詞素的規則被稱為它的詞法語法⁸。在Lox中，和大多數程式語言一樣，該語法的規則非常簡單，可以將其歸為 正則語言。這裡的正則和正規表示式中的 "正則 "是一樣的含義。

You very precisely can recognize all of the different lexemes for Lox using regexes if you want to, and there’s a pile of interesting theory underlying why that is and what it means. Tools like Lex or Flex are designed expressly to let you do this—throw a handful of regexes at them, and they give you a complete scanner back.

如果你願意，你可以非常精確地使用正規表示式來識別Lox的所有不同片語，而且還有一堆有趣的理論來支撐著為什麼會這樣以及它的意義。像Lex⁹或Flex這樣的工具就是專門為實現這一功能而設計的——向其中傳入一些正規表示式，它可以為您提供完整的掃描器。

Since our goal is to understand how a scanner does what it does, we won’t be delegating that task. We’re about handcrafted goods.

由於我們的目標是瞭解掃描器是如何工作的，所以我們不會把這個任務交給正規表示式。我們要親自動手實現。

4 . 4 The Scanner Class

4.4 Scanner類

事不宜遲，我們先來建一個掃描器吧。

lox/Scanner.java，建立新檔案¹⁰

package com.craftinginterpreters.lox;

import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

import static com.craftinginterpreters.lox.TokenType.*; 

class Scanner {
  private final String source;
  private final List<Token> tokens = new ArrayList<>();

  Scanner(String source) {
    this.source = source;
  }
}

We store the raw source code as a simple string, and we have a list ready to fill with tokens we’re going to generate. The aforementioned loop that does that looks like this:

我們將原始的原始碼儲存為一個簡單的字串，並且我們已經準備了一個列表來儲存掃描時產生的標記。前面提到的迴圈看起來類似於：

lox/Scanner.java，方法Scanner()後新增：

  List<Token> scanTokens() {
    while (!isAtEnd()) {
      // We are at the beginning of the next lexeme.
      start = current;
      scanToken();
    }

    tokens.add(new Token(EOF, "", null, line));
    return tokens;
  }

The scanner works its way through the source code, adding tokens until it runs out of characters. Then it appends one final “end of file” token. That isn’t strictly needed, but it makes our parser a little cleaner.

掃描器透過自己的方式遍歷原始碼，新增標記，直到遍歷完所有字元。然後，它在最後附加一個的 "end of file "標記。嚴格意義上來說，這並不是必須的，但它可以使我們的解析器更加乾淨。

This loop depends on a couple of fields to keep track of where the scanner is in the source code.

這個迴圈依賴於幾個欄位來跟蹤掃描器在原始碼中的位置。

lox/Scanner.java，在Scanner類中新增：

  private final List<Token> tokens = new ArrayList<>();
// 新增下面三行程式碼
  private int start = 0;
  private int current = 0;
  private int line = 1;

  Scanner(String source) {

The start and current fields are offsets that index into the string. The start field points to the first character in the lexeme being scanned, and current points at the character currently being considered. The line field tracks what source line current is on so we can produce tokens that know their location.

start和current欄位是指向字串的偏移量。start欄位指向被掃描的詞素中的第一個字元，current欄位指向當前正在處理的字元。line欄位跟蹤的是current所在的原始檔行數，這樣我們產生的標記就可以知道其位置。

Then we have one little helper function that tells us if we’ve consumed all the characters.

然後，我們還有一個輔助函式，用來告訴我們是否已消費完所有字元。

lox/Scanner.java在scanTokens()方法之後新增：

  private boolean isAtEnd() {
    return current >= source.length();
  }

4 . 5 Recognizing Lexemes

4 . 5 識別詞素

In each turn of the loop, we scan a single token. This is the real heart of the scanner. We’ll start simple. Imagine if every lexeme were only a single character long. All you would need to do is consume the next character and pick a token type for it. Several lexemes are only a single character in Lox, so let’s start with those.

在每一次迴圈中，我們可以掃描出一個 token。這是掃描器真正的核心。讓我們先從簡單情況開始。想象一下，如果每個詞素只有一個字元長。您所需要做的就是消費下一個字元併為其選擇一個 token 型別。在Lox中有一些詞素只包含一個字元，所以我們從這些詞素開始¹¹。

lox/Scanner.java新增到scanTokens()方法之後

private void scanToken() {
    char c = advance();
    switch (c) {
      case '(': addToken(LEFT_PAREN); break;
      case ')': addToken(RIGHT_PAREN); break;
      case '{': addToken(LEFT_BRACE); break;
      case '}': addToken(RIGHT_BRACE); break;
      case ',': addToken(COMMA); break;
      case '.': addToken(DOT); break;
      case '-': addToken(MINUS); break;
      case '+': addToken(PLUS); break;
      case ';': addToken(SEMICOLON); break;
      case '*': addToken(STAR); break; 
    }
  }

Again, we need a couple of helper methods.

同樣，我們也需要一些輔助方法。

lox/Scanner.java，新增到 isAtEnd()方法後

  private char advance() {
    current++;
    return source.charAt(current - 1);
  }

  private void addToken(TokenType type) {
    addToken(type, null);
  }

  private void addToken(TokenType type, Object literal) {
    String text = source.substring(start, current);
    tokens.add(new Token(type, text, literal, line));
  }

The advance() method consumes the next character in the source file and returns it. Where advance() is for input, addToken() is for output. It grabs the text of the current lexeme and creates a new token for it. We’ll use the other overload to handle tokens with literal values soon.

advance()方法獲取原始檔中的下一個字元並返回它。advance()用於處理輸入，addToken()則用於輸出。該方法獲取當前詞素的文字併為其建立一個新 token。我們馬上會使用另一個過載方法來處理帶有字面值的 token。

4 . 5 . 1 Lexical errors

4.5.1 詞法錯誤

Before we get too far in, let’s take a moment to think about errors at the lexical level. What happens if a user throws a source file containing some characters Lox doesn’t use, like @#^, at our interpreter? Right now, those characters get silently discarded. They aren’t used by the Lox language, but that doesn’t mean the interpreter can pretend they aren’t there. Instead, we report an error.

在我們深入探討之前，我們先花一點時間考慮一下詞法層面的錯誤。如果使用者拋入直譯器的原始檔中包含一些Lox中不使用的字元——如@#^，會發生什麼？現在，這些字元被默默拋棄了。它們沒有被Lox語言使用，但是不意味著直譯器可以假裝它們不存在。相反，我們應該報告一個錯誤：

lox/Scanner.java 在 scanToken()方法中新增：

      case '*': addToken(STAR); break; 

      default:
        Lox.error(line, "Unexpected character.");
        break;
    }

Note that the erroneous character is still consumed by the earlier call to advance(). That’s important so that we don’t get stuck in an infinite loop.

注意，錯誤的字元仍然會被前面呼叫的advance()方法消費。這一點很重要，這樣我們就不會陷入無限迴圈了。

Note also that we keep scanning. There may be other errors later in the program. It gives our users a better experience if we detect as many of those as possible in one go. Otherwise, they see one tiny error and fix it, only to have the next error appear, and so on. Syntax error Whac-A-Mole is no fun.

另請注意，我們一直在掃描。 程式稍後可能還會出現其他錯誤。 如果我們能夠一次檢測出儘可能多的錯誤，將為我們的使用者帶來更好的體驗。 否則，他們會看到一個小錯誤並修復它，但是卻出現下一個錯誤，不斷重複這個過程。語法錯誤“打地鼠”一點也不好玩。

(Don’t worry. Since hadError gets set, we’ll never try to execute any of the code, even though we keep going and scan the rest of it.)

(別擔心。因為hadError進行了賦值，我們永遠不會嘗試執行任何程式碼，即使程式在繼續執行並掃描程式碼檔案的其餘部分。)

4 . 5 . 2 Operators

4.5.2 運算子

We have single-character lexemes working, but that doesn’t cover all of Lox’s operators. What about !? It’s a single character, right? Sometimes, yes, but if the very next character is an equals sign, then we should instead create a != lexeme. Note that the ! and = are not two independent operators. You can’t write ! = in Lox and have it behave like an inequality operator. That’s why we need to scan != as a single lexeme. Likewise, <, >, and = can all be followed by = to create the other equality and comparison operators.

我們的單字元詞素已經生效了，但是這不能涵蓋Lox中的所有運算子。比如!，這是單字元，對吧？有時候是的，但是如果下一個字元是等號，那麼我們應該改用!= 詞素。注意，這裡的!和=不是兩個獨立的運算子。在Lox中，你不能寫! =來表示不等運算子。這就是為什麼我們需要將!=作為單個詞素進行掃描。同樣地，<、>和=都可以與後面跟隨的=來組合成其他相等和比較運算子。

For all of these, we need to look at the second character.

對於所有這些情況，我們都需要檢視第二個字元。

lox/Scanner.java，在 scanToken()方法中新增

      case '*': addToken(STAR); break; 
      case '!':
        addToken(match('=') ? BANG_EQUAL : BANG);
        break;
      case '=':
        addToken(match('=') ? EQUAL_EQUAL : EQUAL);
        break;
      case '<':
        addToken(match('=') ? LESS_EQUAL : LESS);
        break;
      case '>':
        addToken(match('=') ? GREATER_EQUAL : GREATER);
        break;
      default:

Those cases use this new method:

這些分支中使用了下面的新方法：

lox/Scanner.java 新增到 scanToken()方法後

  private boolean match(char expected) {
    if (isAtEnd()) return false;
    if (source.charAt(current) != expected) return false;

    current++;
    return true;
  }

It’s like a conditional advance(). We only consume the current character if it’s what we’re looking for.

這就像一個有條件的advance()。只有當前字元是我們正在尋找的字元時，我們才會消費。

Using match(), we recognize these lexemes in two stages. When we reach, for example, !, we jump to its switch case. That means we know the lexeme starts with !. Then we look at the next character to determine if we’re on a != or merely a !.

使用match()，我們分兩個階段識別這些詞素。例如，當我們得到!時，我們會跳轉到它的case分支。這意味著我們知道這個詞素是以 !開始的。然後，我們檢視下一個字元，以確認詞素是一個 != 還是僅僅是一個 !。

4 . 6 Longer Lexemes

4.6 更長的詞素

We’re still missing one operator: / for division. That character needs a little special handling because comments begin with a slash too.

我們還缺少一個運算子：表示除法的/。這個字元需要一些特殊處理，因為註釋也是以斜線開頭的。

lox/Scanner.java，在scanToken()方法中新增：

      break;
      case '/':
        if (match('/')) {
          // A comment goes until the end of the line.
          while (peek() != '\n' && !isAtEnd()) advance();
        } else {
          addToken(SLASH);
        }
        break;
      default:

This is similar to the other two-character operators, except that when we find a second /, we don’t end the token yet. Instead, we keep consuming characters until we reach the end of the line.

這與其它的雙字元運算子是類似的，區別在於我們找到第二個/時，還沒有結束本次標記。相反，我們會繼續消費字元直至行尾。

This is our general strategy for handling longer lexemes. After we detect the beginning of one, we shunt over to some lexeme-specific code that keeps eating characters until it sees the end.

這是我們處理較長詞素的一般策略。當我們檢測到一個詞素的開頭後，我們會分流到一些特定於該詞素的程式碼，這些程式碼會不斷地消費字元，直到結尾。

We’ve got another helper:

我們又有了一個輔助函式：

lox/Scanner.java，在match()方法後新增：

  private char peek() {
    if (isAtEnd()) return '\0';
    return source.charAt(current);
  }

It’s sort of like advance(), but doesn’t consume the character. This is called lookahead. Since it only looks at the current unconsumed character, we have one character of lookahead. The smaller this number is, generally, the faster the scanner runs. The rules of the lexical grammar dictate how much lookahead we need. Fortunately, most languages in wide use peek only one or two characters ahead.

這有點像advance()方法，只是不會消費字元。這就是所謂的lookahead(前瞻)¹²。因為它只關注當前未消費的字元，所以我們有一個前瞻字元。一般來說，前瞻的字元越少，掃描器執行速度就越快。詞法語法的規則決定了我們需要前瞻多少字元。幸運的是，大多數廣泛使用的語言只需要提前一到兩個字元。

Comments are lexemes, but they aren’t meaningful, and the parser doesn’t want to deal with them. So when we reach the end of the comment, we don’t call addToken(). When we loop back around to start the next lexeme, start gets reset and the comment’s lexeme disappears in a puff of smoke.

註釋是詞素，但是它們沒有含義，而且解析器也不想要處理它們。所以，我們達到註釋末尾後，不會呼叫addToken()方法。當我們迴圈處理下一個詞素時，start已經被重置了，註釋的詞素就消失在一陣煙霧中了。

While we’re at it, now’s a good time to skip over those other meaningless characters: newlines and whitespace.

既然如此，現在正好可以跳過其它那些無意義的字元了：換行和空格。

lox/Scanner.java，在scanToken()方法中新增：

      	break;
      case ' ':
      case '\r':
      case '\t':
        // Ignore whitespace.
        break;

      case '\n':
        line++;
        break;
      default:
        Lox.error(line, "Unexpected character.");

When encountering whitespace, we simply go back to the beginning of the scan loop. That starts a new lexeme after the whitespace character. For newlines, we do the same thing, but we also increment the line counter. (This is why we used peek() to find the newline ending a comment instead of match(). We want that newline to get us here so we can update line.)

當遇到空白字元時，我們只需回到掃描迴圈的開頭。這樣就會在空白字元之後開始一個新的詞素。對於換行符，我們做同樣的事情，但我們也會遞增行計數器。(這就是為什麼我們使用peek() 而不是match()來查詢註釋結尾的換行符。我們到這裡希望能讀取到換行符，這樣我們就可以更新行數了)

Our scanner is getting smarter. It can handle fairly free-form code like:

我們的掃描器越來越聰明瞭。它可以處理相當自由形式的程式碼，如：

// this is a comment
(( )){} // grouping stuff
!*+-/=<> <= == // operators

4 . 6 . 1 String literals

4.6.1 字串字面量

Now that we’re comfortable with longer lexemes, we’re ready to tackle literals. We’ll do strings first, since they always begin with a specific character, ".

現在我們對長詞素已經很熟悉了，我們可以開始處理字面量了。我們先處理字串，因為字串總是以一個特定的字元"開頭。

lox/Scanner.java，在 scanToken()方法中新增：

      	break;
      case '"': string(); break;
      default:

That calls:

這裡會呼叫：

lox/Scanner.java，在 scanToken()方法之後新增：

  private void string() {
    while (peek() != '"' && !isAtEnd()) {
      if (peek() == '\n') line++;
      advance();
    }

    if (isAtEnd()) {
      Lox.error(line, "Unterminated string.");
      return;
    }

    // The closing ".
    advance();

    // Trim the surrounding quotes.
    String value = source.substring(start + 1, current - 1);
    addToken(STRING, value);
  }

Like with comments, we consume characters until we hit the " that ends the string. We also gracefully handle running out of input before the string is closed and report an error for that.

與註釋類似，我們會一直消費字元，直到"結束該字串。如果輸入內容耗盡，我們也會進行優雅的處理，並報告一個對應的錯誤。

For no particular reason, Lox supports multi-line strings. There are pros and cons to that, but prohibiting them was a little more complex than allowing them, so I left them in. That does mean we also need to update line when we hit a newline inside a string.

沒有特別的原因，Lox支援多行字串。這有利有弊，但禁止換行比允許換行更復雜一些，所以我把它們保留了下來。這意味著當我們在字串內遇到新行時，我們也需要更新line值。

Finally, the last interesting bit is that when we create the token, we also produce the actual string value that will be used later by the interpreter. Here, that conversion only requires a substring() to strip off the surrounding quotes. If Lox supported escape sequences like \n, we’d unescape those here.

最後，還有一個有趣的地方就是當我們建立標記時，我們也會產生實際的字串值，該值稍後將被直譯器使用。這裡，值的轉換隻需要呼叫substring()剝離前後的引號。如果Lox支援轉義序列，比如\n，我們會在這裡取消轉義。

4 . 6 . 2 Number literals

4.6.2 數字字面量

All numbers in Lox are floating point at runtime, but both integer and decimal literals are supported. A number literal is a series of digits optionally followed by a . and one or more trailing digits.

在Lox中，所有的數字在執行時都是浮點數，但是同時支援整數和小數字面量。一個數字字面量就是一系列數位，後面可以跟一個.和一或多個尾數¹³。

1234
12.34

我們不允許小數點處於最開始或最末尾，所以下面的格式是不正確的：

.1234
1234.

We could easily support the former, but I left it out to keep things simple. The latter gets weird if we ever want to allow methods on numbers like 123.sqrt().

我們可以很容易地支援前者，但為了保持簡單，我把它刪掉了。如果我們要允許對數字進行方法呼叫，比如123.sqrt()，後者會變得很奇怪。

To recognize the beginning of a number lexeme, we look for any digit. It’s kind of tedious to add cases for every decimal digit, so we’ll stuff it in the default case instead.

為了識別數字詞素的開頭，我們會尋找任何一位數字。 為每個十進位制數字新增case分支有點乏味，所以我們直接在預設分支中進行處理。

lox/Scanner.java，在 scanToken()方法中替換一行：

      default:
      	// 替換部分開始
      	if (isDigit(c)) {
          number();
        } else {
          Lox.error(line, "Unexpected character.");
        }
        // 替換部分結束
        break;

This relies on this little utility:

這裡依賴下面的小工具函式¹⁴：

lox/Scanner.java，在 peek()方法之後新增：

  private boolean isDigit(char c) {
    return c >= '0' && c <= '9';
  } 

Once we know we are in a number, we branch to a separate method to consume the rest of the literal, like we do with strings.

一旦我們知道當前在處理數字，我們就分支進入一個單獨的方法消費剩餘的字面量，跟字串的處理類似。

lox/Scanner.java，在 scanToken()方法後新增：

  private void number() {
    while (isDigit(peek())) advance();

    // Look for a fractional part.
    if (peek() == '.' && isDigit(peekNext())) {
      // Consume the "."
      advance();

      while (isDigit(peek())) advance();
    }

    addToken(NUMBER,
        Double.parseDouble(source.substring(start, current)));
  }

We consume as many digits as we find for the integer part of the literal. Then we look for a fractional part, which is a decimal point (.) followed by at least one digit. If we do have a fractional part, again, we consume as many digits as we can find.

我們在字面量的整數部分中儘可能多地獲取數字。然後我們尋找小數部分，也就是一個小數點(.)後面至少跟一個數字。如果確實有小數部分，同樣地，我們也儘可能多地獲取數字。

Looking past the decimal point requires a second character of lookahead since we don’t want to consume the . until we’re sure there is a digit after it. So we add:

在定位到小數點之後需要繼續前瞻第二個字元，因為我們只有確認其後有數字才會消費.。所以我們添加了¹⁵：

lox/Scanner.java，在 peek()方法後新增

  private char peekNext() {
    if (current + 1 >= source.length()) return '\0';
    return source.charAt(current + 1);
  }

Finally, we convert the lexeme to its numeric value. Our interpreter uses Java’s Double type to represent numbers, so we produce a value of that type. We’re using Java’s own parsing method to convert the lexeme to a real Java double. We could implement that ourselves, but, honestly, unless you’re trying to cram for an upcoming programming interview, it’s not worth your time.

最後，我們將詞素轉換為其對應的數值。我們的直譯器使用Java的Double型別來表示數字，所以我們建立一個該型別的值。我們使用Java自帶的解析方法將詞素轉換為真正的Java double。我們可以自己實現，但是，說實話，除非你想為即將到來的程式設計面試做準備，否則不值得你花時間。

The remaining literals are Booleans and nil, but we handle those as keywords, which gets us to . . .

剩下的詞素是Boolean和nil，但我們把它們作為關鍵字來處理，這樣我們就來到了......

4 . 7 Reserved Words and Identifiers

4.7 保留字和識別符號

Our scanner is almost done. The only remaining pieces of the lexical grammar to implement are identifiers and their close cousins, the reserved words. You might think we could match keywords like or in the same way we handle multiple-character operators like <=.

我們的掃描器基本完成了，詞法語法中還需要實現的部分僅剩識別符號及其近親——保留字。你也許會想，我們可以採用與處理<=等多字元運算子時相同的方法來匹配關鍵字，如or。

case 'o':
  if (peek() == 'r') {
    addToken(OR);
  }
  break;

Consider what would happen if a user named a variable orchid. The scanner would see the first two letters, or, and immediately emit an or keyword token. This gets us to an important principle called maximal munch. When two lexical grammar rules can both match a chunk of code that the scanner is looking at, whichever one matches the most characters wins.

考慮一下，如果使用者將變數命名為orchid會發生什麼？掃描器會先看到前面的兩個字元，然後立刻生成一個or標記。這就涉及到了一個重要原則，叫作maximal munch(最長匹配)¹⁶。當兩個語法規則都能匹配掃描器正在處理的一大塊程式碼時，哪個規則相匹配的字元最多，就使用哪個規則。

That rule states that if we can match orchid as an identifier and or as a keyword, then the former wins. This is also why we tacitly assumed, previously, that <= should be scanned as a single <= token and not < followed by =.

該規則規定，如果我們可以將orchid匹配為一個識別符號，也可以將or匹配為一個關鍵字，那就採用第一種結果。這也就是為什麼我們在前面會預設為，<=應該識別為單一的<=標記，而不是<後面跟了一個=。

Maximal munch means we can’t easily detect a reserved word until we’ve reached the end of what might instead be an identifier. After all, a reserved word is an identifier, it’s just one that has been claimed by the language for its own use. That’s where the term reserved word comes from.

最大匹配原則意味著，我們只有掃描完一個可能是識別符號的片段，才能確認是否一個保留字。畢竟，保留字也是一個識別符號，只是一個已經被語言要求為自己所用的識別符號。這也是保留字一詞的由來。

So we begin by assuming any lexeme starting with a letter or underscore is an identifier.

所以我們首先假設任何以字母或下劃線開頭的詞素都是一個識別符號。

lox/Scanner.java，在 scanToken()中新增程式碼

        default:
        if (isDigit(c)) {
          number();
          // 新增部分開始
        } else if (isAlpha(c)) {
          identifier();
        // 新增部分結束
        } else {
          Lox.error(line, "Unexpected character.");
        }

The rest of the code lives over here:

其它程式碼如下：

lox/Scanner.java，在 scanToken()方法之後新增：

  private void identifier() {
    while (isAlphaNumeric(peek())) advance();

    addToken(IDENTIFIER);
  }

We define that in terms of these helpers:

透過以下輔助函式來定義：

lox/Scanner.java，在 peekNext()方法之後新增：

  private boolean isAlpha(char c) {
    return (c >= 'a' && c <= 'z') ||
           (c >= 'A' && c <= 'Z') ||
            c == '_';
  }

  private boolean isAlphaNumeric(char c) {
    return isAlpha(c) || isDigit(c);
  }

That gets identifiers working. To handle keywords, we see if the identifier’s lexeme is one of the reserved words. If so, we use a token type specific to that keyword. We define the set of reserved words in a map.

這樣識別符號就開始工作了。為了處理關鍵字，我們要檢視識別符號的詞素是否是保留字之一。如果是，我們就使用該關鍵字特有的標記型別。我們在map中定義保留字的集合。

lox/Scanner.java，在 Scanner類中新增：

  private static final Map<String, TokenType> keywords;

  static {
    keywords = new HashMap<>();
    keywords.put("and",    AND);
    keywords.put("class",  CLASS);
    keywords.put("else",   ELSE);
    keywords.put("false",  FALSE);
    keywords.put("for",    FOR);
    keywords.put("fun",    FUN);
    keywords.put("if",     IF);
    keywords.put("nil",    NIL);
    keywords.put("or",     OR);
    keywords.put("print",  PRINT);
    keywords.put("return", RETURN);
    keywords.put("super",  SUPER);
    keywords.put("this",   THIS);
    keywords.put("true",   TRUE);
    keywords.put("var",    VAR);
    keywords.put("while",  WHILE);
  }

Then, after we scan an identifier, we check to see if it matches anything in the map.

接下來，在我們掃描到識別符號之後，要檢查是否與map中的某些項匹配。

lox/Scanner.java，在 identifier()方法中替換一行：

    while (isAlphaNumeric(peek())) advance();

    // 替換部分開始
    String text = source.substring(start, current);
    TokenType type = keywords.get(text);
    if (type == null) type = IDENTIFIER;
    addToken(type);
    // 替換部分結束
  }

If so, we use that keyword’s token type. Otherwise, it’s a regular user-defined identifier.

如果匹配的話，就使用關鍵字的標記型別。否則，就是一個普通的使用者定義的識別符號。

And with that, we now have a complete scanner for the entire Lox lexical grammar. Fire up the REPL and type in some valid and invalid code. Does it produce the tokens you expect? Try to come up with some interesting edge cases and see if it handles them as it should.

至此，我們就有了一個完整的掃描器，可以掃描整個Lox詞法語法。啟動REPL，輸入一些有效和無效的程式碼。它是否產生了你所期望的詞法單元？試著想出一些有趣的邊界情況，看看它是否能正確地處理它們。

CHALLENGES

習題

1、The lexical grammars of Python and Haskell are not regular. What does that mean, and why aren’t they?

1、Python和Haskell的語法不是常規的。 這是什麼意思，為什麼不是呢？

• Python和Haskell都採用了對縮排敏感的語法，所以它們必須將縮排級別的變動識別為詞法標記。這樣做需要比較連續行的開頭空格數量，這是使用常規語法無法做到的。

2、Aside from separating tokens—distinguishing print foo from printfoo—spaces aren’t used for much in most languages. However, in a couple of dark corners, a space does affect how code is parsed in CoffeeScript, Ruby, and the C preprocessor. Where and what effect does it have in each of those languages?

2、除了分隔標記——區分print foo和printfoo——空格在大多數語言中並沒有什麼用處。在CoffeeScript、Ruby和C前處理器中的一些隱秘的地方，空格確實會影響程式碼解析方式。在這些語言中，空格在什麼地方，會有什麼影響？

3、Our scanner here, like most, discards comments and whitespace since those aren’t needed by the parser. Why might you want to write a scanner that does not discard those? What would it be useful for?

3、我們這裡的掃描器和大多數掃描器一樣，會丟棄註釋和空格，因為解析器不需要這些。什麼情況下你會寫一個不丟棄這些的掃描器？它有什麼用呢？

4、Add support to Lox’s scanner for C-style /* ... */ block comments. Make sure to handle newlines in them. Consider allowing them to nest. Is adding support for nesting more work than you expected? Why?

4、為Lox掃描器增加對C樣式/ * ... * /遮蔽註釋的支援。確保要處理其中的換行符。 考慮允許它們巢狀， 增加對巢狀的支援是否比你預期的工作更多？ 為什麼？

DESIGN NOTE: IMPLICIT SEMICOLONS

設計筆記：隱藏的分號

Programmers today are spoiled for choice in languages and have gotten picky about syntax. They want their language to look clean and modern. One bit of syntactic lichen that almost every new language scrapes off (and some ancient ones like BASIC never had) is ; as an explicit statement terminator.

Instead, they treat a newline as a statement terminator where it makes sense to do so. The “where it makes sense” part is the challenging bit. While most statements are on their own line, sometimes you need to spread a single statement across a couple of lines. Those intermingled newlines should not be treated as terminators.

Most of the obvious cases where the newline should be ignored are easy to detect, but there are a handful of nasty ones:

• A return value on the next line:

  if (condition) return
  "value"
  

  Is “value” the value being returned, or do we have a return statement with no value followed by an expression statement containing a string literal?

• A parenthesized expression on the next line:

  func
  (parenthesized)
  

  Is this a call to func(parenthesized), or two expression statements, one for func and one for a parenthesized expression?

• A - on the next line:

  first
  -second
  

  Is this first - second—an infix subtraction—or two expression statements, one for first and one to negate second?

In all of these, either treating the newline as a separator or not would both produce valid code, but possibly not the code the user wants. Across languages, there is an unsettling variety of rules used to decide which newlines are separators. Here are a couple:

• Lua completely ignores newlines, but carefully controls its grammar such that no separator between statements is needed at all in most cases. This is perfectly legit:

  a = 1 b = 2
  

  Lua avoids the return problem by requiring a return statement to be the very last statement in a block. If there is a value after return before the keyword end, it must be for the return. For the other two cases, they allow an explicit ; and expect users to use that. In practice, that almost never happens because there’s no point in a parenthesized or unary negation expression statement.

• Go handles newlines in the scanner. If a newline appears following one of a handful of token types that are known to potentially end a statement, the newline is treated like a semicolon, otherwise it is ignored. The Go team provides a canonical code formatter, gofmt, and the ecosystem is fervent about its use, which ensures that idiomatic styled code works well with this simple rule.

• Python treats all newlines as significant unless an explicit backslash is used at the end of a line to continue it to the next line. However, newlines anywhere inside a pair of brackets ((), [], or {}) are ignored. Idiomatic style strongly prefers the latter.

  This rule works well for Python because it is a highly statement-oriented language. In particular, Python’s grammar ensures a statement never appears inside an expression. C does the same, but many other languages which have a “lambda” or function literal syntax do not.

  An example in JavaScript:

  console.log(function() {
    statement();
  });
  

  Here, the console.log() expression contains a function literal which in turn contains the statement statement();.

  Python would need a different set of rules for implicitly joining lines if you could get back into a statement where newlines should become meaningful while still nested inside brackets.

• JavaScript’s “automatic semicolon insertion” rule is the real odd one. Where other languages assume most newlines are meaningful and only a few should be ignored in multi-line statements, JS assumes the opposite. It treats all of your newlines as meaningless whitespace unless it encounters a parse error. If it does, it goes back and tries turning the previous newline into a semicolon to get something grammatically valid.

  This design note would turn into a design diatribe if I went into complete detail about how that even works, much less all the various ways that JavaScript’s “solution” is a bad idea. It’s a mess. JavaScript is the only language I know where many style guides demand explicit semicolons after every statement even though the language theoretically lets you elide them.

If you’re designing a new language, you almost surely should avoid an explicit statement terminator. Programmers are creatures of fashion like other humans, and semicolons are as passé as ALL CAPS KEYWORDS. Just make sure you pick a set of rules that make sense for your language’s particular grammar and idioms. And don’t do what JavaScript did.

現在的程式設計師已經被越來越多的語言選擇寵壞了，對語法也越來越挑剔。他們希望自己的程式碼看起來乾淨、現代化。幾乎每一種新語言都會放棄一個小的語法點（一些古老的語言，比如BASIC從來沒有過），那就是將;作為顯式的語句結束符。

相對地，它們將“有意義的”換行符看作是語句結束符。這裡所說的“有意義的”是有挑戰性的部分。儘管大多數的語句都是在同一行，但有時你需要將一個語句擴充套件到多行。這些混雜的換行符不應該被視作結束符。

大多數明顯的應該忽略換行的情況都很容易發現，但也有少數討厭的情況：

• 返回值在下一行：

  if (condition) return
  "value"
  

  “value”是要返回的值嗎？還是說我們有一個空的return語句，後面跟著包含一個字串字面量的表示式語句。

• 下一行中有帶圓括號的表示式：

  func
  (parenthesized)
  

  這是一個對func(parenthesized)的呼叫，還是兩個表示式語句，一個用於func，一個用於圓括號表示式？

• “-”號在下一行：

  first
  -second
  

  這是一箇中綴表示式——first - second，還是兩個表示式語句，一個是first，另一個是對second取負？

在所有這些情況下，無論是否將換行符作為分隔符，都會產生有效的程式碼，但可能不是使用者想要的程式碼。在不同的語言中，有各種不同的規則來決定哪些換行符是分隔符。下面是幾個例子：

• Lua完全忽略了換行符，但是仔細地控制了它的語法，因此在大多數情況下，語句之間根本不需要分隔符。這段程式碼是完全合法的：

  a = 1 b = 2
  

  Lua要求 return 語句是一個塊中的最後一條語句，從而避免 return 問題。如果在關鍵字end之前、return之後有一個值，這個值必須是用於return。對於其他兩種情況來說，Lua允許顯式的;並且期望使用者使用它。在實踐中，這種情況基本不會發生，因為在小括號或一元否定表示式語句中沒有任何意義。

• Go會處理掃描器中的換行。如果在詞法單元之後出現換行，並且該詞法標記是已知可能結束語句的少數標記型別之一，則將換行視為分號，否則就忽略它。Go團隊提供了一個規範的程式碼格式化程式gofmt，整個軟體生態系統非常熱衷於使用它，這確保了常用樣式的程式碼能夠很好地遵循這個簡單的規則。

• Python將所有換行符都視為有效，除非在行末使用明確的反斜槓將其延續到下一行。但是，括號(()、[]或{})內的任何換行都將被忽略。慣用的程式碼風格更傾向於後者。

  這條規則對 Python 很有效，因為它是一種高度面向語句的語言。特別是，Python 的語法確保了語句永遠不會出現在表示式內。C語言也是如此，但許多其他有 "lambda "或函式字面語法的語言則不然。

  舉一個JavaScript中的例子：

  console.log(function() {
    statement();
  });
  

  這裡，console.log() 表示式包含一個函式字面量，而這個函式字面量又包含 statement();語句。

  如果要求進入一個巢狀在括號內的語句中，並且要求其中的換行是有意義的，那麼Python將需要一套不同的隱式連線行的規則¹⁷。

• JavaScript的“自動分號插入”規則才是真正的奇葩。其他語言認為大多數換行符都是有意義的，只有少數換行符在多行語句中應該被忽略，而JS的假設恰恰相反。它將所有的換行符都視為無意義的空白，除非遇到解析錯誤。如果遇到了，它就會回過頭來，嘗試把之前的換行變成分號，以期得到正確的語法。

  如果我完全詳細地介紹它是如何工作的，那麼這個設計說明就會變成一篇設計檄文，更不用說JavaScript的“解決方案”從各種角度看都是個壞主意。真是一團糟。JavaScript是我所知道的唯一（風格指南和語言本身背離）的語言，它的許多風格指南要求在每條語句後都顯式地使用分號，但該語言卻理論上允許您省略分號。

如果您要設計一種新的語言，則幾乎可以肯定應該避免使用顯式的語句終止符。 程式設計師和其他人類一樣是時尚的動物，分號和ALL CAPS KEYWORDS(全大寫關鍵字)一樣已經過時了。只是要確保您選擇了一套適用於您語言的特定語法和習語的規則即可。不要重蹈JavaScript的覆轍。

1. 一直以來，這項工作被稱為 "掃描(scanning) "和 "詞法分析(lexing)"（ "詞法分析(lexical analysis)"的簡稱）。早在計算機還像Winnebagos一樣大，但記憶體比你的手錶還小的時候，有些人就用 "掃描 "來指代從磁碟上讀取原始原始碼字元並在記憶體中緩衝的那段程式碼。然後，"lexing "是後續階段，對字元做有用的操作。現在，將原始檔讀入記憶體是很平常的事情，因此在編譯器中很少出現不同的階段。 因此，這兩個術語基本上可以互換。 ↩

2. System.exit(64)，對於退出程式碼，我使用UNIX sysexts .h標頭檔案中定義的約定。這是我能找到的最接近標準的東西。 ↩

3. 互動式提示符也被稱為REPL(發音像rebel，但替換為p)。它的名稱來自於Lisp，實現Lisp非常簡單，只需圍繞幾個內建函式進行迴圈:(print (eval (read)))從巢狀最內的呼叫向外執行，讀取一行輸入，求值，列印結果，然後迴圈並再次執行。 ↩

4. 說了這麼多，對於這個直譯器，我們要構建的只是基本框架。我很想談談互動式偵錯程式、靜態分析器和其它有趣的東西，但是篇幅實在有限。 ↩

5. 我第一次實現jlox的時候正是如此。最後我把它拆出去了，因為對於本書的最小直譯器來說，這有點過度設計了。 ↩

6. 畢竟，字串比較最終也會比對單個字元，這不正是掃描器的工作嗎？ ↩

7. 一些標記實現將位置儲存為兩個數字：從原始檔開始到詞素開始的偏移量，以及詞素的長度。掃描器無論如何都會知道這些數字，因此計算這些數字沒有任何開銷。透過回頭檢視原始檔並計算前面的換行數，可以將偏移量轉換為行和列位置。這聽起來很慢，確實如此。然而，只有當你需要向用戶實際顯示行和列的時候，你才需要這樣做。大多數標記從來不會出現在錯誤資訊中。對於這些標記，你花在提前計算位置資訊上的時間越少越好。 ↩

8. 我很痛心要對理論做這麼多掩飾，尤其是當它像喬姆斯基譜系和有限狀態機那樣有趣的時候。但說實話，其他的書比我寫得好。Compilers: Principles, Techniques, and Tools(常被稱為“龍書”)是最經典的參考書。 ↩

9. Lex是由Mike Lesk和Eric Schmidt建立的。是的，就是那個曾任谷歌執行董事長的Eric Schmidt。我並不是說程式語言是通往財富和名聲的必經之路，但我們中至少已經有一位超級億萬富翁。 ↩

10. 我知道很多人認為靜態匯入是一種不好的程式碼風格，但這樣我就不必在掃描器和解析器中到處寫TokenType了。恕我直言，在一本書中，每個字元都很重要 ↩

11. 想知道這裡為什麼沒有/嗎？別擔心，我們會解決的。 ↩

12. 技術上來說，match()方法也是在做前瞻。advance()和peek()是基本運算子，match()將它們結合起來。 ↩

13. 因為我們只會根據數字來判斷數字字面量，這就意味著-123不是一個數字字面量。相反，-123是一個表示式，將-應用到數字字面量123。在實踐中，結果是一樣的，儘管它有一個有趣的邊緣情況。試想一下，如果我們要在數字上新增方法呼叫：print -123.abs();，這裡會輸出-123，因為負號的優先順序低於方法呼叫。我們可以透過將-作為數字字面值的一部分來解決這個問題。但接著考慮：var n = 123; print -n.abs();，結果仍然是-123，所以現在語言似乎不一致。無論你怎麼做，有些情況最後都會變得很奇怪。 ↩

14. Java標準庫中提供了Character.isDigit()，這似乎是個不錯的選擇。唉，該方法中還允許梵文數字、全寬數字和其他我們不想要的有趣的東西。 ↩

15. 我本可以讓peek()方法接受一個引數來表示要前瞻的字元數，而不需要定義兩個函式。但這樣做就會允許前瞻任意長度的字元。提供兩個函式可以讓讀者更清楚地知道，我們的掃描器最多隻能向前看兩個字元。 ↩

16. 看一下這段討厭的C程式碼：---a;，它有效嗎？這取決於掃描器如何分割詞素。如果掃描器看到的是- --a;，那它就可以被解析。但是這需要掃描器知道程式碼前後的語法結構，這比我們需要的更復雜。相反，最大匹配原則表明，掃描結果總是：-- -a;，它就會這樣掃描，儘管這樣做會在解析器中導致後面的語法錯誤。 ↩

17. 現在你明白為什麼Python中的lambda只允許單行的表示式體了吧。 ↩

5.Representing Code 表示程式碼

To dwellers in a wood, almost every species of tree has its voice as well as its feature.

​ —— Thomas Hardy, Under the Greenwood Tree

對於森林中的居民來說，幾乎每一種樹都有它的聲音和特點。

In the last chapter, we took the raw source code as a string and transformed it into a slightly higher-level representation: a series of tokens. The parser we’ll write in the next chapter takes those tokens and transforms them yet again, into an even richer, more complex representation.

在上一章中，我們以字串形式接收原始原始碼，並將其轉換為一個稍高階別的表示：一系列詞法標記。我們在下一章中要編寫的解析器，會將這些詞法標記再次轉換為更豐富、更復雜的表示形式。

Before we can produce that representation, we need to define it. That’s the subject of this chapter. Along the way, we’ll cover some theory around formal grammars, feel the difference between functional and object-oriented programming, go over a couple of design patterns, and do some metaprogramming.

在我們能夠輸出這種表示形式之前，我們需要先對其進行定義。這就是本章的主題¹。在這一過程中，我們將圍繞形式化語法進行一些理論講解，感受函數語言程式設計和麵向物件程式設計的區別，會介紹幾種設計模式，並進行一些超程式設計。

Before we do all that, let’s focus on the main goal—a representation for code. It should be simple for the parser to produce and easy for the interpreter to consume. If you haven’t written a parser or interpreter yet, those requirements aren’t exactly illuminating. Maybe your intuition can help. What is your brain doing when you play the part of a human interpreter? How do you mentally evaluate an arithmetic expression like this:

在做這些事情之前，我們先關注一下主要目標——程式碼的表示形式。它應該易於解析器生成，也易於直譯器使用。如果您還沒有編寫過解析器或直譯器，那麼這樣的需求描述並不能很好地說明問題。也許你的直覺可以幫助你。當你扮演一個人類直譯器的角色時，你的大腦在做什麼？你如何在心裡計算這樣的算術表示式：

1 + 2 * 3 - 4

Because you understand the order of operations—the old “Please Excuse My Dear Aunt Sally” stuff—you know that the multiplication is evaluated before the addition or subtraction. One way to visualize that precedence is using a tree. Leaf nodes are numbers, and interior nodes are operators with branches for each of their operands.

因為你已經理解了操作的順序——以前的“Please Excuse My Dear Aunt Sally”之類²，你知道乘法在加減操作之前執行。有一種方法可以將這種優先順序進行視覺化，那就是使用樹³。葉子節點是數字，內部節點是運算子，它們的每個運算元都對應一個分支。

In order to evaluate an arithmetic node, you need to know the numeric values of its subtrees, so you have to evaluate those first. That means working your way from the leaves up to the root—a post-order traversal:

要想計算一個算術節點，你需要知道它的子樹的數值，所以你必須先計運算元樹的結果。這意味著要從葉節點一直計算到根節點——後序遍歷：

• A.從完整的樹開始，先計算最下面的操作2*3；
• B.現在計算+；
• C.接下來，計算-；
• D.最終得到答案。

If I gave you an arithmetic expression, you could draw one of these trees pretty easily. Given a tree, you can evaluate it without breaking a sweat. So it intuitively seems like a workable representation of our code is a tree that matches the grammatical structure—the operator nesting—of the language.

如果我給你一個算術表示式，你可以很容易地畫出這樣的樹；給你一棵樹，你也可以毫不費力地進行計算。因此，從直觀上看，我們的程式碼的一種可行的表示形式是一棵與語言的語法結構（運算子巢狀）相匹配的樹。

We need to get more precise about what that grammar is then. Like lexical grammars in the last chapter, there is a long ton of theory around syntactic grammars. We’re going into that theory a little more than we did when scanning because it turns out to be a useful tool throughout much of the interpreter. We start by moving one level up the Chomsky hierarchy . . .

那麼我們需要更精確地瞭解這個語法是什麼。就像上一章的詞彙語法一樣，圍繞句法語法也有一大堆理論。我們要比之前處理掃描時投入更多精力去研究這個理論，因為它在整個直譯器的很多地方都是一個有用的工具。我們先從喬姆斯基譜系中往上升一級……

5 . 1 Context-Free Grammars

5.1 上下文無關語法

In the last chapter, the formalism we used for defining the lexical grammar—the rules for how characters get grouped into tokens—was called a regular language. That was fine for our scanner, which emits a flat sequence of tokens. But regular languages aren’t powerful enough to handle expressions which can nest arbitrarily deeply.

在上一章中，我們用來定義詞法語法（字元如何被分組為詞法標記的規則）的形式體系，被稱為正則語言。這對於我們的掃描器來說沒什麼問題，因為它輸出的是一個扁平的詞法標記序列。但正則語言還不夠強大，無法處理可以任意深度巢狀的表示式。

We need a bigger hammer, and that hammer is a context-free grammar (CFG). It’s the next heaviest tool in the toolbox of formal grammars. A formal grammar takes a set of atomic pieces it calls its “alphabet”. Then it defines a (usually infinite) set of “strings” that are “in” the grammar. Each string is a sequence of “letters” in the alphabet.

我們還需要一個更強大的工具，就是上下文無關語法(context-free grammar，CFG)。它是形式化語法的工具箱中下一個最重的工具。一個形式化語法需要一組原子片段，它稱之為 "alphabet（字母表）"。然後它定義了一組（通常是無限的）"strings（字串）"，這些字串 "包含"在語法中。每個字串都是字母表中 "letters（字元）"的序列。

I’m using all those quotes because the terms get a little confusing as you move from lexical to syntactic grammars. In our scanner’s grammar, the alphabet consists of individual characters and the strings are the valid lexemes—roughly “words”. In the syntactic grammar we’re talking about now, we’re at a different level of granularity. Now each “letter” in the alphabet is an entire token and a “string” is a sequence of tokens—an entire expression.

我這裡使用引號是因為當你從詞法轉到文法語法時，這些術語會讓你有點困惑。在我們的掃描器詞法中，alphabet（字母表）由單個字元組成，strings（字串）是有效的詞素（粗略的說，就是“單詞”）。在現在討論的句法語法中，我們處於一個不同的粒度水平。現在，字母表中的一個“letters（字元）”是一個完整的詞法標記，而“strings（字串）”是一個詞法標記系列——一個完整的表示式。

Oof. Maybe a table will help:

嗯，使用表格可能更有助於理解：

A formal grammar’s job is to specify which strings are valid and which aren’t. If we were defining a grammar for English sentences, “eggs are tasty for breakfast” would be in the grammar, but “tasty breakfast for are eggs” would probably not.

形式化語法的工作是指定哪些字串有效，哪些無效。如果我們要為英語句子定義一個語法，"eggs are tasty for breakfast "會包含在語法中，但 "tasty breakfast for are eggs "可能不會。

5 . 1 . 1 Rules for grammars

5.1.1 語法規則

How do we write down a grammar that contains an infinite number of valid strings? We obviously can’t list them all out. Instead, we create a finite set of rules. You can think of them as a game that you can “play” in one of two directions.

我們如何寫下一個包含無限多有效字串的語法?我們顯然無法一一列舉出來。相反，我們建立了一組有限的規則。你可以把它們想象成一場你可以朝兩個方向“玩”的遊戲。

If you start with the rules, you can use them to generate strings that are in the grammar. Strings created this way are called derivations because each is derived from the rules of the grammar. In each step of the game, you pick a rule and follow what it tells you to do. Most of the lingo around formal grammars comes from playing them in this direction. Rules are called productions because they produce strings in the grammar.

如果你從規則入手，你可以用它們生成語法中的字串。以這種方式建立的字串被稱為推導式（派生式），因為每個字串都是從語法規則中推導出來的。在遊戲的每一步中，你都要選擇一條規則，然後按照它告訴你的去做。圍繞形式化語法的大部分語言都傾向這種方式。規則被稱為生成式，因為它們生成了語法中的字串。

Each production in a context-free grammar has a head—its name—and a body, which describes what it generates. In its pure form, the body is simply a list of symbols. Symbols come in two delectable flavors:

上下文無關語法中的每個生成式都有一個頭部（其名稱）和描述其生成內容的主體⁴。在純粹的形式上看，主體只是一系列符號。符號有兩種：

• A terminal is a letter from the grammar’s alphabet. You can think of it like a literal value. In the syntactic grammar we’re defining, the terminals are individual lexemes—tokens coming from the scanner like if or 1234.

  These are called “terminals”, in the sense of an “end point” because they don’t lead to any further “moves” in the game. You simply produce that one symbol.

• A nonterminal is a named reference to another rule in the grammar. It means “play that rule and insert whatever it produces here”. In this way, the grammar composes.

• 終止符是語法字母表中的一個字母。你可以把它想象成一個字面值。在我們定義的語法中，終止符是獨立的詞素——來自掃描器的詞法標記，比如 if 或 1234。

  這些詞素被稱為“終止符”，表示“終點”，因為它們不會導致遊戲中任何進一步的 "動作"。你只是簡單地產生了那一個符號。

• 非終止符是對語法中另一條規則的命名引用。它的意思是 "執行那條規則，然後將它產生的任何內容插入這裡"。這樣，語法就構成了。

There is one last refinement: you may have multiple rules with the same name. When you reach a nonterminal with that name, you are allowed to pick any of the rules for it, whichever floats your boat.

還有最後一個細節：你可以有多個同名的規則。當你遇到一個該名字的非終止符時，你可以為它選擇任何一條規則，隨您喜歡。

To make this concrete, we need a way to write down these production rules. People have been trying to crystallize grammar all the way back to Pāṇini’s Ashtadhyayi, which codified Sanskrit grammar a mere couple thousand years ago. Not much progress happened until John Backus and company needed a notation for specifying ALGOL 58 and came up with Backus-Naur form (BNF). Since then, nearly everyone uses some flavor of BNF, tweaked to their own tastes.

為了讓這個規則具體化，我們需要一種方式來寫下這些生成規則。人們一直試圖將語法具體化，可以追溯到Pāṇini的Ashtadhyayi，他在幾千年前編纂了梵文語法。直到約翰-巴庫斯（John Backus）和公司需要一個宣告ALGOL 58的符號，並提出了巴科斯正規化（BNF），才有了很大的進展。從那時起，幾乎每個人都在使用BNF的某種變形，並根據自己的需要進行了調整⁵。

I tried to come up with something clean. Each rule is a name, followed by an arrow (→), followed by a sequence of symbols, and finally ending with a semicolon (;). Terminals are quoted strings, and nonterminals are lowercase words.

我試圖提出一個簡單的形式。 每個規則都是一個名稱，後跟一個箭頭（→），後跟一系列符號，最後以分號（;）結尾。 終止符是帶引號的字串，非終止符是小寫的單詞。

Using that, here’s a grammar for breakfast menus:

以此為基礎，下面是一個早餐選單語法：

breakfast  → protein "with" breakfast "on the side" ;
breakfast  → protein ;
breakfast  → bread ;

protein    → crispiness "crispy" "bacon" ;
protein    → "sausage" ;
protein    → cooked "eggs" ;

crispiness → "really" ;
crispiness → "really" crispiness ;

cooked     → "scrambled" ;
cooked     → "poached" ;
cooked     → "fried" ;

bread      → "toast" ;
bread      → "biscuits" ;
bread      → "English muffin" ;

We can use this grammar to generate random breakfasts. Let’s play a round and see how it works. By age-old convention, the game starts with the first rule in the grammar, here breakfast. There are three productions for that, and we randomly pick the first one. Our resulting string looks like:

我們可以使用這個語法來隨機生成早餐。我們來玩一輪，看看它是如何工作的。按照老規矩，遊戲從語法中的第一個規則開始，這裡是breakfast。它有三個生成式，我們隨機選擇第一個。我們得到的字串是這樣的：

protein "with" breakfast "on the side"

We need to expand that first nonterminal, protein, so we pick a production for that. Let’s pick:

我們需要展開第一個非終止符，protein，所有我們要選擇它對應的一個生成式。我們選：

protein → cooked "eggs" ;

Next, we need a production for cooked, and so we pick "poached". That’s a terminal, so we add that. Now our string looks like:

接下來，我們需要 cooked的生成式，我們選擇 "poached"。這是一個終止符，我們加上它。現在我們的字串是這樣的：

"poached" "eggs" "with" breakfast "on the side"

The next non-terminal is breakfast again. The first breakfast production we chose recursively refers back to the breakfast rule. Recursion in the grammar is a good sign that the language being defined is context-free instead of regular. In particular, recursion where the recursive nonterminal has productions on both sides implies that the language is not regular.

下一個非終止符還是breakfast ，我們開始選擇的breakfast 生成式遞迴地指向了breakfast 規則⁶。語法中的遞迴是一個很好的標誌，表明所定義的語言是上下文無關的，而不是正則的。特別是，遞迴非終止符兩邊都有生成式的遞迴，意味著語言不是正則的。

We could keep picking the first production for breakfast over and over again yielding all manner of breakfasts like “bacon with sausage with scrambled eggs with bacon . . . ” We won’t though. This time we’ll pick bread. There are three rules for that, each of which contains only a terminal. We’ll pick “English muffin”.

我們可以不斷選擇breakfast 的第一個生成式，以做出各種各樣的早餐：“bacon with sausage with scrambled eggs with bacon . . . ”，【存疑，按照規則設定，這裡應該不會出現以bacon開頭的字串，原文可能有誤】但我們不會這樣做。這一次我們選擇bread。有三個對應的規則，每個規則只包含一個終止符。我們選 "English muffin"。

With that, every nonterminal in the string has been expanded until it finally contains only terminals and we’re left with:

這樣一來，字串中的每一個非終止符都被展開了，直到最後只包含終止符，我們就剩下：

Throw in some ham and Hollandaise, and you’ve got eggs Benedict.

再加上一些火腿和荷蘭醬，你就得到了鬆餅蛋。

Any time we hit a rule that had multiple productions, we just picked one arbitrarily. It is this flexibility that allows a short number of grammar rules to encode a combinatorially larger set of strings. The fact that a rule can refer to itself—directly or indirectly—kicks it up even more, letting us pack an infinite number of strings into a finite grammar.

每當我們遇到具有多個結果的規則時，我們都只是隨意選擇了一個。 正是這種靈活性允許用少量的語法規則來編碼出組合性更強的字串集。一個規則可以直接或間接地引用它自己，這就更提高了它的靈活性，讓我們可以將無限多的字串打包到一個有限的語法中。

5 . 1 . 2 Enhancing our notation

5.1.2 增強符號

Stuffing an infinite set of strings in a handful of rules is pretty fantastic, but let’s take it further. Our notation works, but it’s a little tedious. So, like any good language designer, we’ll sprinkle some syntactic sugar on top. In addition to terminals and nonterminals, we’ll allow a few other kinds of expressions in the body of a rule:

在少量的規則中可以填充無限多的字串是相當奇妙的，但是我們可以更進一步。我們的符號是可行的，但有點乏味。所以，就像所有優秀的語言設計者一樣，我們會在上面撒一些語法糖。除了終止符和非終止符之外，我們還允許在規則的主體中使用一些其他型別的表示式：

• Instead of repeating the rule name each time we want to add another production for it, we’ll allow a series of productions separated by a pipe (|).

  我們將允許一系列由管道符(|)分隔的生成式，避免在每次在新增另一個生成式時重複規則名稱。

  bread → "toast" | "biscuits" | "English muffin" ;
  

• Further, we’ll allow parentheses for grouping and then allow | within that to select one from a series of options within the middle of a production.

  此外，我們允許用括號進行分組，然後在分組中可以用|表示從一系列生成式中選擇一個。

  protein → ( "scrambled" | "poached" | "fried" ) "eggs" ;
  

• Using recursion to support repeated sequences of symbols has a certain appealing purity, but it’s kind of a chore to make a separate named sub-rule each time we want to loop. So, we also use a postfix * to allow the previous symbol or group to be repeated zero or more times.

  使用遞迴來支援符號的重複序列有一定的吸引力，但每次我們要迴圈的時候，都要建立一個單獨的命名子規則，有點繁瑣⁷。所以，我們也使用字尾*來允許前一個符號或組重複零次或多次。

  crispiness → "really" "really"* ;
  

• A postfix + is similar, but requires the preceding production to appear at least once.

  字尾+與此類似，但要求前面的生成式至少出現一次。

  crispiness → "really"+ ;
  

• A postfix ? is for an optional production. The thing before it can appear zero or one time, but not more.

  字尾？表示可選生成式，它之前的生成式可以出現零次或一次，但不能出現多次。

  breakfast → protein ( "with" breakfast "on the side" )? ;
  

With all of those syntactic niceties, our breakfast grammar condenses down to:

有了所有這些語法上的技巧，我們的早餐語法濃縮為：

breakfast → protein ( "with" breakfast "on the side" )?
          | bread ;

protein   → "really"+ "crispy" "bacon"
          | "sausage"
          | ( "scrambled" | "poached" | "fried" ) "eggs" ;

bread     → "toast" | "biscuits" | "English muffin" ;

Not too bad, I hope. If you’re used to grep or using regular expressions in your text editor, most of the punctuation should be familiar. The main difference is that symbols here represent entire tokens, not single characters.

我希望還不算太壞。如果你習慣使用grep或在你的文字編輯器中使用正規表示式，大多數的標點符號應該是熟悉的。主要區別在於，這裡的符號代表整個標記，而不是單個字元。

We’ll use this notation throughout the rest of the book to precisely describe Lox’s grammar. As you work on programming languages, you’ll find that context-free grammars (using this or EBNF or some other notation) help you crystallize your informal syntax design ideas. They are also a handy medium for communicating with other language hackers about syntax.

在本書的其餘部分中，我們將使用這種表示法來精確地描述Lox的語法。當您使用程式語言時，您會發現上下文無關的語法(使用此語法或EBNF或其他一些符號)可以幫助您將非正式的語法設計思想具體化。它們也是與其他語言駭客交流語法的方便媒介。

The rules and productions we define for Lox are also our guide to the tree data structure we’re going to implement to represent code in memory. Before we can do that, we need an actual grammar for Lox, or at least enough of one for us to get started.

我們為Lox定義的規則和生成式也是我們將要實現的樹資料結構（用於表示記憶體中的程式碼）的指南。 在此之前，我們需要為Lox編寫一個實際的語法，或者至少要有一個足夠上手的語法。

5 . 1 . 3 A Grammar for Lox expressions

5.1.3 Lox表示式語法

In the previous chapter, we did Lox’s entire lexical grammar in one fell swoop. Every keyword and bit of punctuation is there. The syntactic grammar is larger, and it would be a real bore to grind through the entire thing before we actually get our interpreter up and running.

在上一章中，我們一氣呵成地完成了Lox的全部詞彙語法，包括每一個關鍵詞和標點符號。但句法語法的規模更大，如果在我們真正啟動並執行直譯器之前，就要把整個語法啃完，那就太無聊了。

Instead, we’ll crank through a subset of the language in the next couple of chapters. Once we have that mini-language represented, parsed, and interpreted, then later chapters will progressively add new features to it, including the new syntax. For now, we are going to worry about only a handful of expressions:

相反，我們將在接下來的幾章中摸索該語言的一個子集。一旦我們可以對這個迷你語言進行表示、解析和解釋，那麼在之後的章節中將逐步為它新增新的特性，包括新的語法。現在，我們只關心幾個表示式：

• Literals. Numbers, strings, Booleans, and nil.

  字面量。數字、字串、布林值以及nil。

• Unary expressions. A prefix ! to perform a logical not, and - to negate a number.

  一元表示式。字首!執行邏輯非運算，-對數字求反。

• Binary expressions. The infix arithmetic (+, -, *, /) and logic operators (==, !=, <, <=, >, >=) we know and love.

  二元表示式。我們已經知道的中綴算術符（+，-，*，/）和邏輯運算子（==，！=，<，<=，>，> =）。

• Parentheses. A pair of ( and ) wrapped around an expression.

  括號。表示式前後的一對（和）。

That gives us enough syntax for expressions like:

這已經為表示式提供了足夠的語法，例如：

1 - (2 * 3) < 4 == false

Using our handy dandy new notation, here’s a grammar for those:

使用我們的新符號，下面是語法的表示：

expression     → literal
               | unary
               | binary
               | grouping ;

literal        → NUMBER | STRING | "true" | "false" | "nil" ;
grouping       → "(" expression ")" ;
unary          → ( "-" | "!" ) expression ;
binary         → expression operator expression ;
operator       → "==" | "!=" | "<" | "<=" | ">" | ">="
               | "+"  | "-"  | "*" | "/" ;

There’s one bit of extra metasyntax here. In addition to quoted strings for terminals that match exact lexemes, we CAPITALIZE terminals that are a single lexeme whose text representation may vary. NUMBER is any number literal, and STRING is any string literal. Later, we’ll do the same for IDENTIFIER.

這裡有一點額外的元語法。除了與精確詞素相匹配的終止符會加引號外，我們還對錶示單一詞素的終止符進行大寫化，這些詞素的文字表示方式可能會有所不同。NUMBER是任何數字字面量，STRING是任何字串字面量。稍後，我們將對IDENTIFIER進行同樣的處理⁸。

This grammar is actually ambiguous, which we’ll see when we get to parsing it. But it’s good enough for now.

這個語法實際上是有歧義的，我們在解析它時就會看到這一點。但現在這已經足夠了。

5 . 2 Implementing Syntax Trees

5.2 實現語法樹

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的——我們的資料結構將形成一棵樹。因為這個結構代表了我們語言的語法，所以叫做語法樹⁹。

Our scanner used a single Token class to represent all kinds of lexemes. To distinguish the different kinds—think the number 123 versus the string "123"—we included a simple TokenType enum. Syntax trees are not so homogeneous. Unary expressions have a single operand, binary expressions have two, and literals have none.

我們的掃描器使用一個單一的 Token 類來表示所有型別的詞素。為了區分不同的種類——想想數字 123 和字串 "123"——我們建立了一個簡單的 TokenType 列舉。語法樹並不是那麼同質的¹⁰。一元表示式只有一個運算元，二元表示式有兩個運算元，而字面量則沒有。

We could mush that all together into a single Expression class with an arbitrary list of children. Some compilers do. But I like getting the most out of Java’s type system. So we’ll define a base class for expressions. Then, for each kind of expression—each production under expression—we create a subclass that has fields for the nonterminals specific to that rule. This way, we get a compile error if we, say, try to access the second operand of a unary expression.

我們可以將所有這些內容整合到一個包含任意子類列表的 Expression 類中。有些編譯器會這麼做。但我希望充分利用Java的型別系統。所以我們將為表示式定義一個基類。然後，對於每一種表示式——expression下的每一個生成式——我們建立一個子類，這個子類有該規則所特有的非終止符欄位。這樣，如果試圖訪問一元表示式的第二個運算元，就會得到一個編譯錯誤。

Something like this:

類似這樣¹¹：

package com.craftinginterpreters.lox;

abstract class Expr { 
  static class Binary extends Expr {
    Binary(Expr left, Token operator, Expr right) {
      this.left = left;
      this.operator = operator;
      this.right = right;
    }

    final Expr left;
    final Token operator;
    final Expr right;
  }

  // Other expressions...
}

Expr is the base class that all expression classes inherit from. As you can see from Binary, the subclasses are nested inside of it. There’s no technical need for this, but it lets us cram all of the classes into a single Java file.

Expr是所有表示式類繼承的基類。從Binary中可以看到，子類都巢狀在它的內部。這在技術上沒有必要，但它允許我們將所有類都塞進一個Java檔案中。

5 . 2 . 1 Disoriented objects

5.2.1 非面向物件

You’ll note that, much like the Token class, there aren’t any methods here. It’s a dumb structure. Nicely typed, but merely a bag of data. This feels strange in an object-oriented language like Java. Shouldn’t the class do stuff?

你會注意到，（表示式類）像Token類一樣，其中沒有任何方法。這是一個很愚蠢的結構，巧妙的型別封裝，但僅僅是一包資料。這在Java這樣的面嚮物件語言中會有些奇怪，難道類不是應該做一些事情嗎？

The problem is that these tree classes aren’t owned by any single domain. Should they have methods for parsing since that’s where the trees are created? Or interpreting since that’s where they are consumed? Trees span the border between those territories, which means they are really owned by neither.

問題在於這些樹類不屬於任何單個的領域。樹是在解析的時候建立的，難道類中應該有解析對應的方法？或者因為樹結構在解釋的時候被消費，其中是不是要提供解釋相關的方法？樹跨越了這些領域之間的邊界，這意味著它們實際上不屬於任何一方。

In fact, these types exist to enable the parser and interpreter to communicate. That lends itself to types that are simply data with no associated behavior. This style is very natural in functional languages like Lisp and ML where all data is separate from behavior, but it feels odd in Java.

事實上，這些型別的存在是為了讓解析器和直譯器能夠進行交流。這就適合於那些只是簡單的資料而沒有相關行為的型別。這種風格在Lisp和ML這樣的函式式語言中是非常自然的，因為在這些語言中，所有的資料和行為都是分開的，但是在Java中感覺很奇怪。

Functional programming aficionados right now are jumping up to exclaim “See! Object-oriented languages are a bad fit for an interpreter!” I won’t go that far. You’ll recall that the scanner itself was admirably suited to object-orientation. It had all of the mutable state to keep track of where it was in the source code, a well-defined set of public methods, and a handful of private helpers.

函數語言程式設計的愛好者們現在都跳起來驚呼：“看吧！面向物件的語言不適合作為直譯器！”我不會那麼過分的。您可能還記得，掃描器本身非常適合面向物件。它包含所有的可變狀態來跟蹤其在原始碼中的位置、一組定義良好的公共方法和少量的私有輔助方法。

My feeling is that each phase or part of the interpreter works fine in an object-oriented style. It is the data structures that flow between them that are stripped of behavior.

我的感覺是，在面向物件的風格下，直譯器的每個階段或部分都能正常工作。只不過在它們之間流動的資料結構剝離了行為。

5 . 2 . 2 Metaprogramming the trees

5.2.2 節點樹超程式設計

Java can express behavior-less classes, but I wouldn’t say that it’s particularly great at it. Eleven lines of code to stuff three fields in an object is pretty tedious, and when we’re all done, we’re going to have 21 of these classes.

Java可以表達無行為的類，但很難說它特別擅長。用11行程式碼在一個物件中填充3個欄位是相當乏味的，當我們全部完成後，我們將有21個這樣的類。

I don’t want to waste your time or my ink writing all that down. Really, what is the essence of each subclass? A name, and a list of typed fields. That’s it. We’re smart language hackers, right? Let’s automate.

我不想浪費你的時間或我的墨水把這些都寫下來。真的，每個子類的本質是什麼?一個名稱和一個欄位列表而已。我們是聰明的語言駭客，對吧?我們把它自動化¹²。

Instead of tediously handwriting each class definition, field declaration, constructor, and initializer, we’ll hack together a script that does it for us. It has a description of each tree type—its name and fields—and it prints out the Java code needed to define a class with that name and state.

與其繁瑣地手寫每個類的定義、欄位宣告、建構函式和初始化器，我們一起編寫一個指令碼來完成任務。 它具有每種樹型別（名稱和欄位）的描述，並打印出定義具有該名稱和狀態的類所需的Java程式碼。

This script is a tiny Java command-line app that generates a file named “Expr.java”:

該指令碼是一個微型Java命令列應用程式，它生成一個名為“ Expr.java”的檔案：

tool/GenerateAst.java，建立新檔案

package com.craftinginterpreters.tool;

import java.io.IOException;
import java.io.PrintWriter;
import java.util.Arrays;
import java.util.List;

public class GenerateAst {
  public static void main(String[] args) throws IOException {
    if (args.length != 1) {
      System.err.println("Usage: generate_ast <output directory>");
      System.exit(64);
    }
    String outputDir = args[0];
  }
}

Note that this file is in a different package, .tool instead of .lox. This script isn’t part of the interpreter itself. It’s a tool we, the people hacking on the interpreter, run ourselves to generate the syntax tree classes. When it’s done, we treat “Expr.java” like any other file in the implementation. We are merely automating how that file gets authored.

注意，這個檔案在另一個包中，是.tool而不是.lox。這個指令碼並不是直譯器本身的一部分，它是一個工具，我們這種編寫直譯器的人，透過執行該指令碼來生成語法樹類。完成後，我們把“Expr.java”與實現中的其它檔案進行相同的處理。我們只是自動化了檔案的生成方式。

To generate the classes, it needs to have some description of each type and its fields.

為了生成類，還需要對每種型別及其欄位進行一些描述。

tool/GenerateAst.java，在 main()方法中新增

    String outputDir = args[0];
    // 新增部分開始
    defineAst(outputDir, "Expr", Arrays.asList(
      "Binary   : Expr left, Token operator, Expr right",
      "Grouping : Expr expression",
      "Literal  : Object value",
      "Unary    : Token operator, Expr right"
    ));
    // 新增部分結束
  }

For brevity’s sake, I jammed the descriptions of the expression types into strings. Each is the name of the class followed by : and the list of fields, separated by commas. Each field has a type and a name.

為簡便起見，我將表示式型別的描述放入了字串中。 每一項都包括類的名稱，後跟：和以逗號分隔的欄位列表。 每個欄位都有一個型別和一個名稱。

The first thing defineAst() needs to do is output the base Expr class.

defineAst()需要做的第一件事是輸出基類Expr。

tool/GenerateAst.java，在 main()方法後新增：

  private static void defineAst(
      String outputDir, String baseName, List<String> types)
      throws IOException {
    String path = outputDir + "/" + baseName + ".java";
    PrintWriter writer = new PrintWriter(path, "UTF-8");

    writer.println("package com.craftinginterpreters.lox;");
    writer.println();
    writer.println("import java.util.List;");
    writer.println();
    writer.println("abstract class " + baseName + " {");

    writer.println("}");
    writer.close();
  }

When we call this, baseName is “Expr”, which is both the name of the class and the name of the file it outputs. We pass this as an argument instead of hardcoding the name because we’ll add a separate family of classes later for statements.

我們呼叫這個函式時，baseName是“Expr”，它既是類的名稱，也是它輸出的檔案的名稱。我們將它作為引數傳遞，而不是對名稱進行硬編碼，因為稍後我們將為語句新增一個單獨的類族。

Inside the base class, we define each subclass.

在基類內部，我們定義每個子類。

tool/GenerateAst.java，在 defineAst()類中新增¹³：

    writer.println("abstract class " + baseName + " {");
    // 新增部分開始
    // The AST classes.
    for (String type : types) {
      String className = type.split(":")[0].trim();
      String fields = type.split(":")[1].trim(); 
      defineType(writer, baseName, className, fields);
    }
    // 新增部分結束
    writer.println("}");

That code, in turn, calls:

這段程式碼依次呼叫：

tool/GenerateAst.java，在 defineAst()後面新增：

  private static void defineType(
      PrintWriter writer, String baseName,
      String className, String fieldList) {
    writer.println("  static class " + className + " extends " +
        baseName + " {");

    // Constructor.
    writer.println("    " + className + "(" + fieldList + ") {");

    // Store parameters in fields.
    String[] fields = fieldList.split(", ");
    for (String field : fields) {
      String name = field.split(" ")[1];
      writer.println("      this." + name + " = " + name + ";");
    }

    writer.println("    }");

    // Fields.
    writer.println();
    for (String field : fields) {
      writer.println("    final " + field + ";");
    }

    writer.println("  }");
  }

There we go. All of that glorious Java boilerplate is done. It declares each field in the class body. It defines a constructor for the class with parameters for each field and initializes them in the body.

好了。所有的Java模板都完成了。它在類體中宣告瞭每個欄位。它為類定義了一個建構函式，為每個欄位提供引數，並在類體中對其初始化。

Compile and run this Java program now and it blasts out a new “.java” file containing a few dozen lines of code. That file’s about to get even longer.

現在編譯並執行這個Java程式，它會生成一個新的“. Java”檔案，其中包含幾十行程式碼。那份檔案還會變得更長¹⁴。

5 . 3 Working with Trees

5.3 處理樹結構

Put on your imagination hat for a moment. Even though we aren’t there yet, consider what the interpreter will do with the syntax trees. Each kind of expression in Lox behaves differently at runtime. That means the interpreter needs to select a different chunk of code to handle each expression type. With tokens, we can simply switch on the TokenType. But we don’t have a “type” enum for the syntax trees, just a separate Java class for each one.

先想象一下吧。儘管我們還沒有到那一步，但請考慮一下直譯器將如何處理語法樹。Lox中的每種表示式在執行時的行為都不一樣。這意味著直譯器需要選擇不同的程式碼塊來處理每種表示式型別。對於詞法標記，我們可以簡單地根據TokenType進行轉換。但是我們並沒有為語法樹設定一個 "type "列舉，只是為每個語法樹單獨設定一個Java類。

We could write a long chain of type tests:

我們可以編寫一長串型別測試：

if (expr instanceof Expr.Binary) {
  // ...
} else if (expr instanceof Expr.Grouping) {
  // ...
} else // ...

But all of those sequential type tests are slow. Expression types whose names are alphabetically later would take longer to execute because they’d fall through more if cases before finding the right type. That’s not my idea of an elegant solution.

但所有這些順序型別測試都很慢。型別名稱按字母順序排列在後面的表示式，執行起來會花費更多的時間，因為在找到正確的型別之前，它們會遇到更多的if情況。這不是我認為的優雅解決方案。

We have a family of classes and we need to associate a chunk of behavior with each one. The natural solution in an object-oriented language like Java is to put those behaviors into methods on the classes themselves. We could add an abstract interpret() method on Expr which each subclass would then implement to interpret itself.

我們有一個類族，我們需要將一組行為與每個類關聯起來。在Java這樣的面嚮物件語言中，最自然的解決方案是將這些行為放入類本身的方法中。我們可以在Expr上新增一個抽象的interpret()方法，然後每個子類都要實現這個方法來解釋自己¹⁵。

This works alright for tiny projects, but it scales poorly. Like I noted before, these tree classes span a few domains. At the very least, both the parser and interpreter will mess with them. As you’ll see later, we need to do name resolution on them. If our language was statically typed, we’d have a type checking pass.

這對於小型專案來說還行，但它的擴充套件性很差。就像我之前提到的，這些樹類跨越了幾個領域。至少，解析器和直譯器都會對它們進行幹擾。稍後您將看到，我們需要對它們進行名稱解析。如果我們的語言是靜態型別的，我們還需要做型別檢查。

If we added instance methods to the expression classes for every one of those operations, that would smush a bunch of different domains together. That violates separation of concerns and leads to hard-to-maintain code.

如果我們為每一個操作的表示式類中新增例項方法，就會將一堆不同的領域混在一起。這違反了關注點分離原則，並會產生難以維護的程式碼。

5 . 3 . 1 The expression problem

5.3.1 表示式問題

This problem is more fundamental than it may seem at first. We have a handful of types, and a handful of high-level operations like “interpret”. For each pair of type and operation, we need a specific implementation. Picture a table:

這個問題比起初看起來更基礎。我們有一些型別，和一些高階操作，比如“解釋”。對於每一對型別和操作，我們都需要一個特定的實現。畫一個表:

Rows are types, and columns are operations. Each cell represents the unique piece of code to implement that operation on that type.

行是型別，列是操作。每個單元格表示在該型別上實現該操作的唯一程式碼段。

An object-oriented language like Java assumes that all of the code in one row naturally hangs together. It figures all the things you do with a type are likely related to each other, and the language makes it easy to define them together as methods inside the same class.

像Java這樣的面向物件的語言，假定一行中的所有程式碼都自然地掛在一起。它認為你對一個型別所做的所有事情都可能是相互關聯的，而使用這類語言可以很容易將它們一起定義為同一個類裡面的方法。

This makes it easy to extend the table by adding new rows. Simply define a new class. No existing code has to be touched. But imagine if you want to add a new operation—a new column. In Java, that means cracking open each of those existing classes and adding a method to it.

這種情況下，向表中加入新行來擴充套件列表是很容易的，簡單地定義一個新類即可，不需要修改現有的程式碼。但是，想象一下，如果你要新增一個新操作（新的一列）。在Java中，這意味著要拆開已有的那些類並向其中新增方法。

Functional paradigm languages in the ML family flip that around. There, you don’t have classes with methods. Types and functions are totally distinct. To implement an operation for a number of different types, you define a single function. In the body of that function, you use pattern matching—sort of a type-based switch on steroids—to implement the operation for each type all in one place.

ML家族中的函式式範型反過來了¹⁶。在這些語言中，沒有帶方法的類，型別和函式是完全獨立的。要為許多不同型別實現一個操作，只需定義一個函式。在該函式體中，您可以使用模式匹配（某種基於型別的switch操作）在同一個函式中實現每個型別對應的操作。

This makes it trivial to add new operations—simply define another function that pattern matches on all of the types.

這使得新增新操作非常簡單——只需定義另一個與所有型別模式匹配的的函式即可。

But, conversely, adding a new type is hard. You have to go back and add a new case to all of the pattern matches in all of the existing functions.

但是，反過來說，新增新型別是困難的。您必須回頭向已有函式中的所有模式匹配新增一個新的case。

Each style has a certain “grain” to it. That’s what the paradigm name literally says—an object-oriented language wants you to orient your code along the rows of types. A functional language instead encourages you to lump each column’s worth of code together into a function.

每種風格都有一定的 "紋路"。這就是正規化名稱的字面意思——面向物件的語言希望你按照型別的行來組織你的程式碼。而函式式語言則鼓勵你把每一列的程式碼都歸納為一個函式。

A bunch of smart language nerds noticed that neither style made it easy to add both rows and columns to the table. They called this difficulty the “expression problem” because—like we are now—they first ran into it when they were trying to figure out the best way to model expression syntax tree nodes in a compiler.

一群聰明的語言迷注意到，這兩種風格都不容易向表格中新增行和列。他們稱這個困難為“表示式問題”¹⁷。就像我們現在一樣，他們是在試圖找出在編譯器中建模表達式語法樹節點的最佳方法時，第一次遇到了該問題。

People have thrown all sorts of language features, design patterns, and programming tricks to try to knock that problem down but no perfect language has finished it off yet. In the meantime, the best we can do is try to pick a language whose orientation matches the natural architectural seams in the program we’re writing.

人們已經拋出了各種各樣的語言特性、設計模式和程式設計技巧，試圖解決這個問題，但還沒有一種完美的語言能夠解決它。與此同時，我們所能做的就是儘量選擇一種與我們正在編寫的程式的自然架構相匹配的語言。

Object-orientation works fine for many parts of our interpreter, but these tree classes rub against the grain of Java. Fortunately, there’s a design pattern we can bring to bear on it.

面向物件在我們的直譯器的許多部分都可以正常工作，但是這些樹類與Java的本質背道而馳。 幸運的是，我們可以採用一種設計模式來解決這個問題。

5 . 3 . 2 The Visitor pattern

5.3.2 訪問者模式

The Visitor pattern is the most widely misunderstood pattern in all of Design Patterns, which is really saying something when you look at the software architecture excesses of the past couple of decades.

訪問者模式是所有設計模式中最容易被誤解的模式，當您回顧過去幾十年的軟體架構氾濫狀況時，會發現確實如此。

The trouble starts with terminology. The pattern isn’t about “visiting”, and the “accept” method in it doesn’t conjure up any helpful imagery either. Many think the pattern has to do with traversing trees, which isn’t the case at all. We are going to use it on a set of classes that are tree-like, but that’s a coincidence. As you’ll see, the pattern works as well on a single object.

問題出在術語上。這個模式不是關於“visiting（訪問）”，它的 “accept”方法也沒有讓人產生任何有用的想象。許多人認為這種模式與遍歷樹有關，但事實並非如此。我們確實要在一組樹結構的類上使用它，但這只是一個巧合。如您所見，該模式在單個物件上也可以正常使用。

The Visitor pattern is really about approximating the functional style within an OOP language. It lets us add new columns to that table easily. We can define all of the behavior for a new operation on a set of types in one place, without having to touch the types themselves. It does this the same way we solve almost every problem in computer science: by adding a layer of indirection.

訪問者模式實際上近似於OOP語言中的函式式。它讓我們可以很容易地向表中新增新的列。我們可以在一個地方定義針對一組型別的新操作的所有行為，而不必觸及型別本身。這與我們解決電腦科學中幾乎所有問題的方式相同：新增中間層。

Before we apply it to our auto-generated Expr classes, let’s walk through a simpler example. Say we have two kinds of pastries: beignets and crullers.

在將其應用到自動生成的Expr類之前，讓我們先看一個更簡單的例子。比方說我們有兩種點心:Beignet(捲餅)和Cruller(油酥卷)。

 abstract class Pastry {
  }

  class Beignet extends Pastry {
  }

  class Cruller extends Pastry {
  }

We want to be able to define new pastry operations—cooking them, eating them, decorating them, etc.—without having to add a new method to each class every time. Here’s how we do it. First, we define a separate interface.

我們希望能夠定義新的糕點操作（烹飪，食用，裝飾等），而不必每次都向每個類新增新方法。我們是這樣做的。首先，我們定義一個單獨的介面¹⁸。

  interface PastryVisitor {
    void visitBeignet(Beignet beignet); 
    void visitCruller(Cruller cruller);
  }

Each operation that can be performed on pastries is a new class that implements that interface. It has a concrete method for each type of pastry. That keeps the code for the operation on both types all nestled snugly together in one class.

可以對糕點執行的每個操作都是實現該介面的新類。 它對每種型別的糕點都有具體的方法。 這樣一來，針對兩種型別的操作程式碼都緊密地巢狀在一個類中。

Given some pastry, how do we route it to the correct method on the visitor based on its type? Polymorphism to the rescue! We add this method to Pastry:

給定一個糕點，我們如何根據其型別將其路由到訪問者的正確方法？多型性拯救了我們！我們在Pastry中新增這個方法：

  abstract class Pastry {
    abstract void accept(PastryVisitor visitor);
  }

Each subclass implements it.

每個子類都需要實現該方法：

  class Beignet extends Pastry {
    @Override
    void accept(PastryVisitor visitor) {
      visitor.visitBeignet(this);
    }
  }

And:

以及：

  class Cruller extends Pastry {
    @Override
    void accept(PastryVisitor visitor) {
      visitor.visitCruller(this);
    }
  }

To perform an operation on a pastry, we call its accept() method and pass in the visitor for the operation we want to execute. The pastry—the specific subclass’s overriding implementation of accept()—turns around and calls the appropriate visit method on the visitor and passes itself to it.

要對糕點執行一個操作，我們就呼叫它的accept()方法，並將我們要執行的操作vistor作為引數傳入該方法。pastry類——特定子類對accept()的重寫實現——會反過來，在visitor上呼叫合適的visit方法，並將自身作為引數傳入。

That’s the heart of the trick right there. It lets us use polymorphic dispatch on the pastry classes to select the appropriate method on the visitor class. In the table, each pastry class is a row, but if you look at all of the methods for a single visitor, they form a column.

這就是這個技巧的核心所在。它讓我們可以在pastry類上使用多型派遣，在visitor類上選擇合適的方法。對應在表格中，每個pastry類都是一行，但如果你看一個visitor的所有方法，它們就會形成一列。

We added one accept() method to each class, and we can use it for as many visitors as we want without ever having to touch the pastry classes again. It’s a clever pattern.

我們為每個類添加了一個accept（）方法，我們可以根據需要將其用於任意數量的訪問者，而無需再次修改pastry類。 這是一個聰明的模式。

5 . 3 . 3 Visitors for expressions

5.3.3 表示式訪問者

OK, let’s weave it into our expression classes. We’ll also refine the pattern a little. In the pastry example, the visit and accept() methods don’t return anything. In practice, visitors often want to define operations that produce values. But what return type should accept() have? We can’t assume every visitor class wants to produce the same type, so we’ll use generics to let each implementation fill in a return type.

好的，讓我們將它編入表示式類中。我們還要對這個模式進行一下完善。在糕點的例子中，visit和accept()方法沒有返回任何東西。在實踐中，訪問者通常希望定義能夠產生值的操作。但accept()應該具有什麼返回型別呢？我們不能假設每個訪問者類都想產生相同的型別，所以我們將使用泛型來讓每個實現類自行填充一個返回型別。

First, we define the visitor interface. Again, we nest it inside the base class so that we can keep everything in one file.

首先，我們定義訪問者介面。同樣，我們把它巢狀在基類中，以便將所有的內容都放在一個檔案中。

tool/GenerateAst.java，在 defineAst()方法中新增：

    writer.println("abstract class " + baseName + " {");
    // 新增部分開始
    defineVisitor(writer, baseName, types);
    // 新增部分結束
    // The AST classes.

That function generates the visitor interface.

這個函式會生成visitor介面。

tool/GenerateAst.java，在 defineAst()方法後新增：

  private static void defineVisitor(
      PrintWriter writer, String baseName, List<String> types) {
    writer.println("  interface Visitor<R> {");

    for (String type : types) {
      String typeName = type.split(":")[0].trim();
      writer.println("    R visit" + typeName + baseName + "(" +
          typeName + " " + baseName.toLowerCase() + ");");
    }

    writer.println("  }");
  }

Here, we iterate through all of the subclasses and declare a visit method for each one. When we define new expression types later, this will automatically include them.

在這裡，我們遍歷所有的子類，併為每個子類宣告一個visit方法。當我們以後定義新的表示式型別時，會自動包含這些內容。

Inside the base class, we define the abstract accept() method.

在基類中，定義抽象 accept() 方法。

tool/GenerateAst.java，在 defineAst()方法中新增：

    	defineType(writer, baseName, className, fields);
    }
    // 新增部分開始
    // The base accept() method.
    writer.println();
    writer.println("  abstract <R> R accept(Visitor<R> visitor);");
    // 新增部分結束
    writer.println("}");

Finally, each subclass implements that and calls the right visit method for its own type.

最後，每個子類都實現該方法，並呼叫其型別對應的visit方法。

tool/GenerateAst.java，在 defineType()方法中新增：

    writer.println("    }");
    // 新增部分開始
    // Visitor pattern.
    writer.println();
    writer.println("    @Override");
    writer.println("    <R> R accept(Visitor<R> visitor) {");
    writer.println("      return visitor.visit" +
        className + baseName + "(this);");
    writer.println("    }");
    // 新增部分結束
    // Fields.

There we go. Now we can define operations on expressions without having to muck with the classes or our generator script. Compile and run this generator script to output an updated “Expr.java” file. It contains a generated Visitor interface and a set of expression node classes that support the Visitor pattern using it.

這下好了。現在我們可以在表示式上定義操作，而且無需對類或生成器指令碼進行修改。編譯並執行這個生成器指令碼，輸出一個更新後的 "Expr.java "檔案。該檔案中包含一個生成的Visitor介面和一組使用該介面支援Visitor模式的表示式節點類。

Before we end this rambling chapter, let’s implement that Visitor interface and see the pattern in action.

在結束這雜亂的一章之前，我們先實現一下這個Visitor介面，看看這個模式的執行情況。

5 . 4 A (Not Very) Pretty Printer

5.4 一個（不是很）漂亮的列印器

When we debug our parser and interpreter, it’s often useful to look at a parsed syntax tree and make sure it has the structure we expect. We could inspect it in the debugger, but that can be a chore.

當我們除錯解析器和直譯器時，檢視解析後的語法樹並確保其與期望的結構一致通常是很有用的。我們可以在偵錯程式中進行檢查，但那可能有點難。

Instead, we’d like some code that, given a syntax tree, produces an unambiguous string representation of it. Converting a tree to a string is sort of the opposite of a parser, and is often called “pretty printing” when the goal is to produce a string of text that is valid syntax in the source language.

相反，我們需要一些程式碼，在給定語法樹的情況下，生成一個明確的字串表示。將語法樹轉換為字串是解析器的逆向操作，當我們的目標是產生一個在源語言中語法有效的文字字串時，通常被稱為 "漂亮列印"。

That’s not our goal here. We want the string to very explicitly show the nesting structure of the tree. A printer that returned 1 + 2 * 3 isn’t super helpful if what we’re trying to debug is whether operator precedence is handled correctly. We want to know if the + or * is at the top of the tree.

這不是我們的目標。我們希望字串非常明確地顯示樹的巢狀結構。如果我們要除錯的是運算子的優先順序是否處理正確，那麼返回1 + 2 * 3的列印器並沒有什麼用，我們想知道+或*是否在語法樹的頂部。

To that end, the string representation we produce isn’t going to be Lox syntax. Instead, it will look a lot like, well, Lisp. Each expression is explicitly parenthesized, and all of its subexpressions and tokens are contained in that.

因此，我們生成的字串表示形式不是Lox語法。相反，它看起來很像Lisp。每個表示式都被顯式地括起來，並且它的所有子表示式和詞法標記都包含在其中。

Given a syntax tree like:

給定一個語法樹，如：

It produces:

輸出結果為：

(* (- 123) (group 45.67))

Not exactly “pretty”, but it does show the nesting and grouping explicitly. To implement this, we define a new class.

不是很“漂亮”，但是它確實明確地展示了巢狀和分組。為了實現這一點，我們定義了一個新類。

lox/AstPrinter.java，建立新檔案：

package com.craftinginterpreters.lox;

class AstPrinter implements Expr.Visitor<String> {
  String print(Expr expr) {
    return expr.accept(this);
  }
}

As you can see, it implements the visitor interface. That means we need visit methods for each of the expression types we have so far.

如你所見，它實現了visitor介面。這意味著我們需要為我們目前擁有的每一種表示式型別提供visit方法。

lox/AstPrinter.java，在 print()方法後新增：

  return expr.accept(this);
  }
  // 新增部分開始
  @Override
  public String visitBinaryExpr(Expr.Binary expr) {
    return parenthesize(expr.operator.lexeme,
                        expr.left, expr.right);
  }

  @Override
  public String visitGroupingExpr(Expr.Grouping expr) {
    return parenthesize("group", expr.expression);
  }

  @Override
  public String visitLiteralExpr(Expr.Literal expr) {
    if (expr.value == null) return "nil";
    return expr.value.toString();
  }

  @Override
  public String visitUnaryExpr(Expr.Unary expr) {
    return parenthesize(expr.operator.lexeme, expr.right);
  }
	// 新增部分結束
}

Literal expressions are easy—they convert the value to a string with a little check to handle Java’s null standing in for Lox’s nil. The other expressions have subexpressions, so they use this parenthesize() helper method:

字面量表達式很簡單——它們將值轉換為一個字串，並透過一個小檢查用Java中的null代替Lox中的nil。其他表示式有子表示式，所以它們要使用parenthesize()這個輔助方法：

lox/AstPrinter.java，在 visitUnaryExpr()方法後新增：

  private String parenthesize(String name, Expr... exprs) {
    StringBuilder builder = new StringBuilder();

    builder.append("(").append(name);
    for (Expr expr : exprs) {
      builder.append(" ");
      builder.append(expr.accept(this));
    }
    builder.append(")");

    return builder.toString();
  }

It takes a name and a list of subexpressions and wraps them all up in parentheses, yielding a string like:

它接收一個名稱和一組子表示式作為引數，將它們全部包裝在圓括號中，並生成一個如下的字串：

(+ 1 2)

Note that it calls accept() on each subexpression and passes in itself. This is the recursive step that lets us print an entire tree.

請注意，它在每個子表示式上呼叫accept()並將自身傳遞進去。 這是遞迴步驟，可讓我們列印整棵樹。

We don’t have a parser yet, so it’s hard to see this in action. For now, we’ll hack together a little main() method that manually instantiates a tree and prints it.

我們還沒有解析器，所以很難看到它的實際應用。現在，我們先使用一個main()方法來手動例項化一個樹並列印它。

lox/AstPrinter.java，在 parenthesize()方法後新增：

  public static void main(String[] args) {
    Expr expression = new Expr.Binary(
        new Expr.Unary(
            new Token(TokenType.MINUS, "-", null, 1),
            new Expr.Literal(123)),
        new Token(TokenType.STAR, "*", null, 1),
        new Expr.Grouping(
            new Expr.Literal(45.67)));

    System.out.println(new AstPrinter().print(expression));
  }

If we did everything right, it prints:

如果我們都做對了，它就會列印：

(* (- 123) (group 45.67))

You can go ahead and delete this method. We won’t need it. Also, as we add new syntax tree types, I won’t bother showing the necessary visit methods for them in AstPrinter. If you want to (and you want the Java compiler to not yell at you), go ahead and add them yourself. It will come in handy in the next chapter when we start parsing Lox code into syntax trees. Or, if you don’t care to maintain AstPrinter, feel free to delete it. We won’t need it again.

您可以繼續刪除這個方法，我們後面不再需要它了。另外，當我們新增新的語法樹型別時，我不會在AstPrinter中展示它們對應的visit方法。如果你想這樣做(並且希望Java編譯器不會報錯)，那麼你可以自行新增這些方法。在下一章，當我們開始將Lox程式碼解析為語法樹時，它將會派上用場。或者，如果你不想維護AstPrinter，可以隨意刪除它。我們不再需要它了。

CHALLENGES

習題

1、Earlier, I said that the |, *, and + forms we added to our grammar metasyntax were just syntactic sugar. Take this grammar:

expr → expr ( "(" ( expr ( "," expr )* )? ")" | "." IDENTIFIER )+
     | IDENTIFIER
     | NUMBER

Produce a grammar that matches the same language but does not use any of that notational sugar.

Bonus: What kind of expression does this bit of grammar encode?

1、之前我說過，我們在語法元語法中新增的|、*、+等形式只是語法糖。以這個語法為例:

expr → expr ( "(" ( expr ( "," expr )* )? ")" | "." IDENTIFIER )+
     | IDENTIFIER
     | NUMBER

生成一個與同一語言相匹配的語法，但不要使用任何語法糖。

附加題：這一點語法表示了什麼樣的表示式？

2、The Visitor pattern lets you emulate the functional style in an object-oriented language. Devise a complementary pattern for a functional language. It should let you bundle all of the operations on one type together and let you define new types easily.

(SML or Haskell would be ideal for this exercise, but Scheme or another Lisp works as well.)

2、Visitor 模式讓你可以在面向物件的語言中模仿函式式。為函式式語言設計一個互補的模式，該模式讓你可以將一個型別上的所有操作捆綁在一起，並輕鬆擴充套件新的型別。

(SML或Haskell是這個練習的理想選擇，但Scheme或其它Lisp方言也可以。)

3、In Reverse Polish Notation (RPN), the operands to an arithmetic operator are both placed before the operator, so 1 + 2 becomes 1 2 +. Evaluation proceeds from left to right. Numbers are pushed onto an implicit stack. An arithmetic operator pops the top two numbers, performs the operation, and pushes the result. Thus, this:

(1 + 2) * (4 - 3)

in RPN becomes:

1 2 + 4 3 - *

Define a visitor class for our syntax tree classes that takes an expression, converts it to RPN, and returns the resulting string.

3、在逆波蘭表示式(RPN)中，算術運算子的運算元都放在運算子之前，所以1 + 2變成了1 2 +。計算時從左到右進行，運算元被壓入隱式棧。算術運算子彈出前兩個數字，執行運算，並將結果推入棧中。因此,

(1 + 2) * (4 - 3)

在RPN中變為了

1 2 + 4 3 - *

為我們的語法樹類定義一個Vistor類，該類接受一個表示式，將其轉換為RPN，並返回結果字串。

1. 我非常擔心這一章會成為這本書中最無聊的章節之一，所以我儘可能多地往裡面塞入了很多有趣的想法。 ↩

2. 在美國，運算子優先順序常縮寫為PEMDAS，分別表示Parentheses(括號), Exponents(指數), Multiplication/Division(乘除), Addition/Subtraction(加減)。為了便於記憶，將縮寫詞擴充為“Please Excuse My Dear Aunt Sally”。 ↩

3. 這並不是說樹是我們程式碼的唯一可能的表示方式。在第三部分，我們將生成位元組碼，這是另一種對人類不友好但更接近機器的表示方式。 ↩

4. 將頭部限制為單個符號是上下文無關語法的定義特性。更強大的形式，如無限制文法，允許在頭部和主體中都包含一系列的符號。 ↩

5. 是的，我們需要為定義語法的規則定義一個語法。我們也應該指定這個元語法嗎?我們用什麼符號來表示它?從上到下都是語言 ↩

6. 想象一下，我們在這裡遞迴擴充套件幾次breakfast規則，比如 "bacon with bacon with bacon with . . ." ，為了正確地完成這個字串，我們需要在結尾處新增同等數量的 "on the side "片語。跟蹤所需尾部的數量超出了正則語法的能力範圍。正則語法可以表達重複，但它們無法統計有多少重複，但是這（種跟蹤）對於確保字串的with和on the side部分的數量相同是必要的。 ↩

7. Scheme程式語言就是這樣工作的。它根本沒有內建的迴圈功能。相反，所有重複都用遞迴來表示。 ↩

8. 如果你願意，可以嘗試使用這個語法生成一些表示式，就像我們之前用早餐語法做的那樣。生成的表示式你覺得對嗎？你能讓它生成任何錯誤的東西，比如1+/3嗎？ ↩

9. 特別是，我們要定義一個抽象語法樹（AST）。在解析樹中，每一個語法生成式都成為樹中的一個節點。AST省略了後面階段不需要的生成式。 ↩

10. 詞法單元也不是完全同質的。字面值的標記儲存值，但其他型別的詞素不需要該狀態。我曾經見過一些掃描器使用不同的類來處理字面量和其他型別的詞素，但我認為我應該把事情簡單化。 ↩

11. 我儘量避免在程式碼中使用縮寫，因為這會讓不知道其含義的讀者犯錯誤。但是在我所研究過的編譯器中，“Expr”和“Stmt”是如此普遍，我最好現在就開始讓您習慣它們。 ↩

12. 我從Jython和IronPython的建立者Jim Hugunin那裡得到了編寫語法樹類指令碼的想法。真正的指令碼語言比Java更適合這種情況，但我儘量不向您提供太多的語言。 ↩

13. 這不是世界上最優雅的字串操作程式碼，但也很好。它只在我們給它的類定義集上執行。穩健性不是優先考慮的問題。 ↩

14. 附錄II包含了在我們完成jlox的實現並定義了它的所有語法樹節點之後，這個指令碼生成的程式碼。 ↩

15. 這就是Erich Gamma等人在《設計模式:可重用的面向物件軟體的元素》一書中所謂的直譯器模式。 ↩

16. ML，是元語言(metalanguage)的簡稱，它是由Robin Milner和他的朋友們建立的，是偉大的程式語言家族的主要分支之一。它的子程式包括SML、Caml、OCaml、Haskell和F#。甚至Scala、Rust和Swift都有很強的相似性。就像Lisp一樣，它也是那種充滿了好點子的語言之一，即使在40多年後的今天，語言設計者仍然在重新發現它們。 ↩

17. 諸如Common Lisp的CLOS，Dylan和Julia這樣的支援多方法(多分派)的語言都能輕鬆新增新型別和操作。它們通常犧牲的是靜態型別檢查或單獨編譯。 ↩

18. 在設計模式中，這兩種方法的名字都叫visit()，很容易混淆，需要依賴過載來區分不同方法。這也導致一些讀者認為正確的visit方法是在執行時根據其引數型別選擇的。事實並非如此。與重寫不同，過載是在編譯時靜態分派的。為每個方法使用不同的名稱使分派更加明顯，同時還向您展示瞭如何在不支援過載的語言中應用此模式。 ↩

6.Parsing Expressions 解析表示式

Grammar, which knows how to control even kings.

​ ——Molière

語法，它甚至知道如何控制國王。（莫里哀）

This chapter marks the first major milestone of the book. Many of us have cobbled together a mishmash of regular expressions and substring operations to extract some sense out of a pile of text. The code was probably riddled with bugs and a beast to maintain. Writing a real parser—one with decent error handling, a coherent internal structure, and the ability to robustly chew through a sophisticated syntax—is considered a rare, impressive skill. In this chapter, you will attain it.

本章是本書的第一個重要里程碑。我們中的許多人都曾將正規表示式和字串操作糅合在一起，以便從一堆文字中提取一些資訊。這些程式碼可能充滿了錯誤，而且很難維護。編寫一個真正的解析器¹——具有良好的錯誤處理、一致的內部結構和能夠健壯地分析複雜語法的能力——被認為是一種罕見的、令人印象深刻的技能。在這一章中，你將獲得這種技能。

It’s easier than you think, partially because we front-loaded a lot of the hard work in the last chapter. You already know your way around a formal grammar. You’re familiar with syntax trees, and we have some Java classes to represent them. The only remaining piece is parsing—transmogrifying a sequence of tokens into one of those syntax trees.

這比想象中要簡單，部分是因為我們在上一章中提前完成了很多困難的工作。你已經對形式化語法瞭如指掌，也熟悉了語法樹，而且我們有一些Java類來表示它們。唯一剩下的部分是解析——將一個標記序列轉換成這些語法樹中的一個。

Some CS textbooks make a big deal out of parsers. In the ’60s, computer scientists—understandably tired of programming in assembly language—started designing more sophisticated, human-friendly languages like Fortran and ALGOL. Alas, they weren’t very machine-friendly for the primitive computers of the time.

一些CS教科書在解析器上大做文章。在60年代，電腦科學家——他們理所當然地厭倦了用匯編語言程式設計——開始設計更復雜的、對人類友好的語言，比如Fortran和ALGOL²。唉，對於當時原始的計算機來說，這些語言對機器並不友好。

These pioneers designed languages that they honestly weren’t even sure how to write compilers for, and then did groundbreaking work inventing parsing and compiling techniques that could handle these new, big languages on those old, tiny machines.

這些先驅們設計了一些語言，說實話，他們甚至不知道如何編寫編譯器。然後他們做了開創性的工作，發明瞭解析和編譯技術，可以在那些老舊、小型的機器上處理這些新的、大型的語言。

Classic compiler books read like fawning hagiographies of these heroes and their tools. The cover of Compilers: Principles, Techniques, and Tools literally has a dragon labeled “complexity of compiler design” being slain by a knight bearing a sword and shield branded “LALR parser generator” and “syntax directed translation”. They laid it on thick.

經典的編譯書讀起來就像是對這些英雄和他們的工具的吹捧傳記。《編譯器:原理、技術和工具》（Compilers: Principles, Techniques, and Tools）的封面上有一條標記著“編譯器設計複雜性”的龍，被一個手持劍和盾的騎士殺死，劍和盾上標記著“LALR解析器生成器”和“語法制導翻譯”。他們在過分吹捧。

A little self-congratulation is well-deserved, but the truth is you don’t need to know most of that stuff to bang out a high quality parser for a modern machine. As always, I encourage you to broaden your education and take it in later, but this book omits the trophy case.

稍微的自我祝賀是當之無愧的，但事實是，你不需要知道其中的大部分知識，就可以為現代機器製作出高質量的解析器。一如既往，我鼓勵你先擴大學習範圍，以後再慢慢接受它，但這本書省略了獎盃箱。

6 . 1 Ambiguity and the Parsing Game

6.1 歧義與解析遊戲

In the last chapter, I said you can “play” a context-free grammar like a game in order to generate strings. Parsers play that game in reverse. Given a string—a series of tokens—we map those tokens to terminals in the grammar to figure out which rules could have generated that string.

在上一章中，我說過你可以像“玩”遊戲一樣使用上下文無關的語法來生成字串。解析器則以相反的方式玩遊戲。給定一個字串(一系列語法標記)，我們將這些標記對映到語法中的終止符，以確定哪些規則可能生成該字串。

The “could have” part is interesting. It’s entirely possible to create a grammar that is ambiguous, where different choices of productions can lead to the same string. When you’re using the grammar to generate strings, that doesn’t matter much. Once you have the string, who cares how you got to it?

"可能產生 "這部分很有意思。我們完全有可能建立一個模稜兩可的語法，在這個語法中，不同的生成式可能會得到同一個字串。當你使用該語法來生成字串時，這一點不太重要。一旦你有了字串，誰還會在乎你是怎麼得到它的呢？

When parsing, ambiguity means the parser may misunderstand the user’s code. As we parse, we aren’t just determining if the string is valid Lox code, we’re also tracking which rules match which parts of it so that we know what part of the language each token belongs to. Here’s the Lox expression grammar we put together in the last chapter:

但是在解析時，歧義意味著解析器可能會誤解使用者的程式碼。當我們進行解析時，我們不僅要確定字串是不是有效的Lox程式碼，還要記錄哪些規則與程式碼的哪些部分相匹配，以便我們知道每個標記屬於語言的哪一部分。下面是我們在上一章整理的Lox表示式語法：

expression     → literal
               | unary
               | binary
               | grouping ;

literal        → NUMBER | STRING | "true" | "false" | "nil" ;
grouping       → "(" expression ")" ;
unary          → ( "-" | "!" ) expression ;
binary         → expression operator expression ;
operator       → "==" | "!=" | "<" | "<=" | ">" | ">="
               | "+"  | "-"  | "*" | "/" ;

This is a valid string in that grammar:

下面是一個滿足語法的有效字串：

But there are two ways we could have generated it. One way is:

但是，有兩種方式可以生成該字串。其一是：

1. Starting at expression, pick binary.
2. For the left-hand expression, pick NUMBER, and use 6.
3. For the operator, pick "/".
4. For the right-hand expression, pick binary again.
5. In that nested binary expression, pick 3 - 1.

1. 從expression開始，選擇binary。
2. 對於左邊的expression，選擇NUMBER，並且使用6。
3. 對於運算子，選擇/。
4. 對於右邊的expression，再次選擇binary。
5. 在內層的binary 表示式中，選擇3-1。

Another is:

其二是：

1. Starting at expression, pick binary.
2. For the left-hand expression, pick binary again.
3. In that nested binary expression, pick 6 / 3.
4. Back at the outer binary, for the operator, pick "-".
5. For the right-hand expression, pick NUMBER, and use 1.

1. 從expression開始，選擇binary。
2. 對於左邊的expression，再次選擇binary。
3. 在內層的binary 表示式中，選擇6/3。
4. 返回外層的binary ，對於運算子，選擇-。
5. 對於右邊的expression，選擇NUMBER，並且使用1。

Those produce the same strings, but not the same syntax trees:

它們產生相同的字串，但對應的是不同的語法樹：

In other words, the grammar allows seeing the expression as (6 / 3) - 1 or 6 / (3 - 1). The binary rule lets operands nest any which way you want. That in turn affects the result of evaluating the parsed tree. The way mathematicians have addressed this ambiguity since blackboards were first invented is by defining rules for precedence and associativity.

換句話說，這個語法可以將該表示式看作是 (6 / 3) - 1或6 / (3 - 1)。binary 規則執行運算元以任意方式巢狀，這反過來又會影響解析數的計算結果。自從黑板被髮明以來，數學家們解決這種模糊性的方法就是定義優先順序和結合性規則。

• Precedence determines which operator is evaluated first in an expression containing a mixture of different operators. Precedence rules tell us that we evaluate the / before the - in the above example. Operators with higher precedence are evaluated before operators with lower precedence. Equivalently, higher precedence operators are said to “bind tighter”.

• 優先順序決定了在一個包含不同運算子的混合表示式中，哪個運算子先被執行³。優先順序規則告訴我們，在上面的例子中，我們在-之前先計算/。優先順序較高的運算子在優先順序較低的運算子之前計算。同樣，優先順序較高的運算子被稱為 "更嚴格的繫結"。

• Associativity determines which operator is evaluated first in a series of the same operator. When an operator is left-associative (think “left-to-right”), operators on the left evaluate before those on the right. Since - is left-associative, this expression:

• 結合性決定在一系列相同運算子中先計算哪個運算子。如果一個運算子是左結合的(可以認為是“從左到右”)時，左邊的運算子在右邊的運算子之前計算。因為-是左結合的，下面的表示式：

  5 - 3 - 1
  

  is equivalent to:

  等價於：

  (5 - 3) - 1
  

  Assignment, on the other hand, is right-associative. This:

  另一方面，賦值是右結合的。如：

  a = b = c
  

  is equivalent to:

  等價於：

  a = (b = c)
  

Without well-defined precedence and associativity, an expression that uses multiple operators is ambiguous—it can be parsed into different syntax trees, which could in turn evaluate to different results. We’ll fix that in Lox by applying the same precedence rules as C, going from lowest to highest.

如果沒有明確定義的優先順序和結合性，使用多個運算子的表示式可能就會變得有歧義——它可以被解析為不同的語法樹，而這些語法樹又可能會計算出不同的結果。我們在Lox中會解決這個問題，使用與C語言相同的優先順序規則，從低到高分別是：

Right now, the grammar stuffs all expression types into a single expression rule. That same rule is used as the non-terminal for operands, which lets the grammar accept any kind of expression as a subexpression, regardless of whether the precedence rules allow it.

現在，該語法將所有表示式型別都新增到一個 expression規則中。這條規則同樣作用於運算元中的非終止符，這使得語法中可以接受任何型別的表示式作為子表示式，而不管優先順序規則是否允許。

We fix that by stratifying the grammar. We define a separate rule for each precedence level.

我們透過對語法進行分層來解決這個問題。我們為每個優先順序定義一個單獨的規則⁴。

expression     → ...
equality       → ...
comparison     → ...
term           → ...
factor         → ...
unary          → ...
primary        → ...

Each rule here only matches expressions at its precedence level or higher. For example, unary matches a unary expression like !negated or a primary expression like 1234. And term can match 1 + 2 but also 3 * 4 / 5. The final primary rule covers the highest-precedence forms—literals and parenthesized expressions.

此處的每個規則僅匹配其當前優先順序或更高優先順序的表示式。 例如，unary 匹配一元表示式（如 !negated）或主表示式（如1234）。term可以匹配1 + 2，但也可以匹配3 * 4 /5。最後的primary 規則涵蓋優先順序最高的形式——字面量和括號表示式。

We just need to fill in the productions for each of those rules. We’ll do the easy ones first. The top expression rule matches any expression at any precedence level. Since equality has the lowest precedence, if we match that, then it covers everything.

我們只需要填寫每條規則的生成式。我們先從簡單的開始。頂級的expression 規則可以匹配任何優先順序的表示式。由於equality的優先順序最低，只要我們匹配了它，就涵蓋了一切⁵。

expression     → equality

Over at the other end of the precedence table, a primary expression contains all the literals and grouping expressions.

在優先順序表的另一端，primary表示式包括所有的字面量和分組表示式。

primary        → NUMBER | STRING | "true" | "false" | "nil"
               | "(" expression ")" ;

A unary expression starts with a unary operator followed by the operand. Since unary operators can nest—!!true is a valid if weird expression—the operand can itself be a unary operator. A recursive rule handles that nicely.

一元表示式以一元運算子開頭，後跟運算元。因為一元運算子可以巢狀——!!true雖奇怪也是可用的表示式——這個運算元本身可以是一個一元表示式。遞迴規則可以很好地解決這個問題。

unary          → ( "!" | "-" ) unary ;

But this rule has a problem. It never terminates.

但是這條規則有一個問題，它永遠不會終止。

Remember, each rule needs to match expressions at that precedence level or higher, so we also need to let this match a primary expression.

請記住，每個規則都需要匹配該優先順序或更高優先順序的表示式，因此我們還需要使其與主表示式匹配。

unary          → ( "!" | "-" ) unary
               | primary ;

That works.

這樣就可以了。

The remaining rules are all binary operators. We’ll start with the rule for multiplication and division. Here’s a first try:

剩下的規則就是二元運算子。我們先從乘法和除法的規則開始。下面是第一次嘗試：

factor         → factor ( "/" | "*" ) unary
               | unary ;

The rule recurses to match the left operand. That enables the rule to match a series of multiplication and division expressions like 1 * 2 / 3. Putting the recursive production on the left side and unary on the right makes the rule left-associative and unambiguous.

該規則遞迴匹配左運算元，這樣一來，就可以匹配一系列乘法和除法表示式，例如 1 * 2 / 3。將遞迴生成式放在左側並將unary 放在右側，可以使該規則具有左關聯性和明確性⁶。

All of this is correct, but the fact that the first symbol in the body of the rule is the same as the head of the rule means this production is left-recursive. Some parsing techniques, including the one we’re going to use, have trouble with left recursion. (Recursion elsewhere, like we have in unary and the indirect recursion for grouping in primary are not a problem.)

所有這些都是正確的，但規則主體中的第一個符號與規則頭部相同意味著這個生成式是左遞迴的。一些解析技術，包括我們將要使用的解析技術，在處理左遞迴時會遇到問題。(其他地方的遞迴，比如在unary中，以及在primary分組中的間接遞迴都不是問題。)

There are many grammars you can define that match the same language. The choice for how to model a particular language is partially a matter of taste and partially a pragmatic one. This rule is correct, but not optimal for how we intend to parse it. Instead of a left recursive rule, we’ll use a different one.

你可以定義很多符合同一種語言的語法。如何對某一特定語言進行建模，一部分是品味問題，一部分是實用主義問題。這個規則是正確的，但對於我們後續的解析來說它並不是最優的。我們將使用不同的規則來代替左遞迴規則。

factor         → unary ( ( "/" | "*" ) unary )* ;

We define a factor expression as a flat sequence of multiplications and divisions. This matches the same syntax as the previous rule, but better mirrors the code we’ll write to parse Lox. We use the same structure for all of the other binary operator precedence levels, giving us this complete expression grammar:

我們將因子表示式定義為乘法和除法的扁平序列。這與前面的規則語法相同，但更好地反映了我們將編寫的解析Lox的程式碼。我們對其它二元運算子的優先順序使用相同的結構，從而得到下面這個完整的表示式語法：

expression     → equality ;
equality       → comparison ( ( "!=" | "==" ) comparison )* ;
comparison     → term ( ( ">" | ">=" | "<" | "<=" ) term )* ;
term           → factor ( ( "-" | "+" ) factor )* ;
factor         → unary ( ( "/" | "*" ) unary )* ;
unary          → ( "!" | "-" ) unary
               | primary ;
primary        → NUMBER | STRING | "true" | "false" | "nil"
               | "(" expression ")" ;

This grammar is more complex than the one we had before, but in return we have eliminated the previous one’s ambiguity. It’s just what we need to make a parser.

這個語法比我們以前的那個更復雜，但反過來我們也消除了前一個語法定義中的歧義。這正是我們製作解析器時所需要的。

6 . 2 Recursive Descent Parsing

6.2 遞迴下降分析

There is a whole pack of parsing techniques whose names are mostly combinations of “L” and “R”—LL(k), LR(1), LALR—along with more exotic beasts like parser combinators, Earley parsers, the shunting yard algorithm, and packrat parsing. For our first interpreter, one technique is more than sufficient: recursive descent.

現在有一大堆解析技術，它們的名字大多是 "L "和 "R "的組合——LL(k)、LR(1)、LALR——還有更多的異類，比如解析器組合子、Earley parsers、分流碼演算法和packrat解析。對於我們的第一個直譯器來說，一種技術已經足夠了：遞迴下降。

Recursive descent is the simplest way to build a parser, and doesn’t require using complex parser generator tools like Yacc, Bison or ANTLR. All you need is straightforward handwritten code. Don’t be fooled by its simplicity, though. Recursive descent parsers are fast, robust, and can support sophisticated error handling. In fact, GCC, V8 (the JavaScript VM in Chrome), Roslyn (the C# compiler written in C#) and many other heavyweight production language implementations use recursive descent. It rocks.

遞迴下降是構建解析器最簡單的方法，不需要使用複雜的解析器生成工具，如Yacc、Bison或ANTLR。你只需要直接手寫程式碼。但是不要被它的簡單性所欺騙，遞迴下降解析器速度快、健壯，並且可以支援複雜的錯誤處理。事實上，GCC、V8 (Chrome中的JavaScript VM)、Roslyn(用c#編寫的c#編譯器)和許多其他重量級產品語言實現都使用了遞迴下降技術。它很好用。

Recursive descent is considered a top-down parser because it starts from the top or outermost grammar rule (here expression) and works its way down into the nested subexpressions before finally reaching the leaves of the syntax tree. This is in contrast with bottom-up parsers like LR that start with primary expressions and compose them into larger and larger chunks of syntax.

遞迴下降被認為是一種自頂向下解析器，因為它從最頂部或最外層的語法規則(這裡是expression)開始，一直向下進入巢狀子表示式，最後到達語法樹的葉子。這與LR等自下而上的解析器形成鮮明對比，後者從初級表示式(primary)開始，將其組成越來越大的語法塊⁷。

A recursive descent parser is a literal translation of the grammar’s rules straight into imperative code. Each rule becomes a function. The body of the rule translates to code roughly like:

遞迴下降解析器是一種將語法規則直接翻譯成命令式程式碼的文字翻譯器。每個規則都會變成一個函式，規則主體翻譯成程式碼大致是這樣的：

The descent is described as “recursive” because when a grammar rule refers to itself—directly or indirectly—that translates to a recursive function call.

下降被“遞迴”修飾是因為，如果一個規則引用自身（直接或間接）就會變為遞迴的函式呼叫。

6 . 2 . 1 The parser class

6.2.1 Parser類

Each grammar rule becomes a method inside this new class:

每個語法規則都成為新類中的一個方法:

lox/Parser.java，建立新檔案：

package com.craftinginterpreters.lox;

import java.util.List;

import static com.craftinginterpreters.lox.TokenType.*;

class Parser {
  private final List<Token> tokens;
  private int current = 0;

  Parser(List<Token> tokens) {
    this.tokens = tokens;
  }
}

Like the scanner, the parser consumes a flat input sequence, only now we’re reading tokens instead of characters. We store the list of tokens and use current to point to the next token eagerly waiting to be parsed.

與掃描器一樣，解析器也是消費一個扁平的輸入序列，只是這次我們要讀取的是語法標記而不是字元。我們會儲存標記列表並使用current指向待解析的下一個標記。

We’re going to run straight through the expression grammar now and translate each rule to Java code. The first rule, expression, simply expands to the equality rule, so that’s straightforward.

我們現在要直接執行表示式語法，並將每一條規則翻譯為Java程式碼。第一條規則expression，簡單地展開為equality規則，所以很直接：

lox/Parser.java，在 Parser()方法後新增：

  private Expr expression() {
    return equality();
  }

Each method for parsing a grammar rule produces a syntax tree for that rule and returns it to the caller. When the body of the rule contains a nonterminal—a reference to another rule—we call that other rule’s method.

每個解析語法規則的方法都會生成該規則對應的語法樹，並將其返回給呼叫者。當規則主體中包含一個非終止符——對另一條規則的引用時，我們就會呼叫另一條規則對應的方法⁸。

The rule for equality is a little more complex.

equality規則有一點複雜：

equality       → comparison ( ( "!=" | "==" ) comparison )* ;

In Java, that becomes:

在Java中，這會變成：

lox/Parser.java，在 expression()後面新增：

  private Expr equality() {
    Expr expr = comparison();

    while (match(BANG_EQUAL, EQUAL_EQUAL)) {
      Token operator = previous();
      Expr right = comparison();
      expr = new Expr.Binary(expr, operator, right);
    }

    return expr;
  }

Let’s step through it. The first comparison nonterminal in the body translates to the first call to comparison() in the method. We take that result and store it in a local variable.

讓我們一步步來。規則體中的第一個 comparison 非終止符變成了方法中對 comparison() 的第一次呼叫。我們獲取結果並將其儲存在一個區域性變數中。

Then, the ( ... )* loop in the rule maps to a while loop. We need to know when to exit that loop. We can see that inside the rule, we must first find either a != or == token. So, if we don’t see one of those, we must be done with the sequence of equality operators. We express that check using a handy match() method.

然後，規則中的( ... )*迴圈對映為一個while迴圈。我們需要知道何時退出這個迴圈。可以看到，在規則體中，我們必須先找到一個 != 或==標記。因此，如果我們沒有看到其中任一標記，我們必須結束相等(不相等)運算子的序列。我們使用一個方便的match()方法來執行這個檢查。

lox/Parser.java，在 equality()方法後新增：

  private boolean match(TokenType... types) {
    for (TokenType type : types) {
      if (check(type)) {
        advance();
        return true;
      }
    }

    return false;
  }

This checks to see if the current token has any of the given types. If so, it consumes the token and returns true. Otherwise, it returns false and leaves the current token alone. The match() method is defined in terms of two more fundamental operations.

這個檢查會判斷當前的標記是否屬於給定的型別之一。如果是，則消費該標記並返回true；否則，就返回false並保留當前標記。match()方法是由兩個更基本的操作來定義的。

The check() method returns true if the current token is of the given type. Unlike match(), it never consumes the token, it only looks at it.

如果當前標記屬於給定型別，則check()方法返回true。與match()不同的是，它從不消費標記，只是讀取。

lox/Parser.java，在 match()方法後新增：

  private boolean check(TokenType type) {
    if (isAtEnd()) return false;
    return peek().type == type;
  }

The advance() method consumes the current token and returns it, similar to how our scanner’s corresponding method crawled through characters.

advance()方法會消費當前的標記並返回它，類似於掃描器中對應方法處理字元的方式。

lox/Parser.java，在 check()方法後新增：

  private Token advance() {
    if (!isAtEnd()) current++;
    return previous();
  }

These methods bottom out on the last handful of primitive operations.

這些方法最後都歸結於幾個基本操作。

lox/Parser.java，在 advance()後新增：

  private boolean isAtEnd() {
    return peek().type == EOF;
  }

  private Token peek() {
    return tokens.get(current);
  }

  private Token previous() {
    return tokens.get(current - 1);
  }

isAtEnd() checks if we’ve run out of tokens to parse. peek() returns the current token we have yet to consume, and previous() returns the most recently consumed token. The latter makes it easier to use match() and then access the just-matched token.

isAtEnd()檢查我們是否處理完了待解析的標記。peek()方法返回我們還未消費的當前標記，而previous()會返回最近消費的標記。後者讓我們更容易使用match()，然後訪問剛剛匹配的標記。

That’s most of the parsing infrastructure we need. Where were we? Right, so if we are inside the while loop in equality(), then we know we have found a != or == operator and must be parsing an equality expression.

這就是我們需要的大部分解析基本工具。我們說到哪裡了？對，如果我們在equality()的while迴圈中，也就能知道我們已經找到了一個!=或==運算子，並且一定是在解析一個等式表示式。

We grab the matched operator token so we can track which kind of equality expression we have. Then we call comparison() again to parse the right-hand operand. We combine the operator and its two operands into a new Expr.Binary syntax tree node, and then loop around. For each iteration, we store the resulting expression back in the same expr local variable. As we zip through a sequence of equality expressions, that creates a left-associative nested tree of binary operator nodes.

我們獲取到匹配的運算子標記，這樣就可以知道我們要處理哪一類等式表示式。之後，我們再次呼叫comparison()解析右邊的運算元。我們將運算子和它的兩個運算元組合成一個新的Expr.Binary語法樹節點，然後開始迴圈。對於每一次迭代，我們都將結果表示式儲存在同一個expr區域性變數中。在對等式表示式序列進行壓縮時，會建立一個由二元運算子節點組成的左結合巢狀樹⁹。

The parser falls out of the loop once it hits a token that’s not an equality operator. Finally, it returns the expression. Note that if the parser never encounters an equality operator, then it never enters the loop. In that case, the equality() method effectively calls and returns comparison(). In that way, this method matches an equality operator or anything of higher precedence.

一旦解析器遇到一個不是等式運算子的標記，就會退出迴圈。最後，它會返回對應的表示式。請注意，如果解析器從未遇到過等式運算子，它就永遠不會進入迴圈。在這種情況下，equality()方法有效地呼叫並返回comparison()。這樣一來，這個方法就會匹配一個等式運算子或任何更高優先順序的表示式。

Moving on to the next rule . . .

繼續看下一個規則。

comparison     → term ( ( ">" | ">=" | "<" | "<=" ) term )* ;

Translated to Java:

翻譯成Java：

lox/Parser.java，在 equality()方法後新增：

  private Expr comparison() {
    Expr expr = term();

    while (match(GREATER, GREATER_EQUAL, LESS, LESS_EQUAL)) {
      Token operator = previous();
      Expr right = term();
      expr = new Expr.Binary(expr, operator, right);
    }

    return expr;
  }

The grammar rule is virtually identical to equality and so is the corresponding code. The only differences are the token types for the operators we match, and the method we call for the operands—now term() instead of comparison(). The remaining two binary operator rules follow the same pattern.

語法規則與equality幾乎完全相同，相應的程式碼也是如此。唯一的區別是匹配的運算子的標記型別，而且現在獲取運算元時呼叫的方法是term()而不是comparison()。其餘兩個二元運算子規則遵循相同的模式。

In order of precedence, first addition and subtraction:

按照優先順序順序，先做加減法：

lox/Parser.java，在 comparison()方法後新增：

  private Expr term() {
    Expr expr = factor();

    while (match(MINUS, PLUS)) {
      Token operator = previous();
      Expr right = factor();
      expr = new Expr.Binary(expr, operator, right);
    }

    return expr;
  }

And finally, multiplication and division:

最後，是乘除法：

lox/Parser.java，在 term()方法後面新增：

  private Expr factor() {
    Expr expr = unary();

    while (match(SLASH, STAR)) {
      Token operator = previous();
      Expr right = unary();
      expr = new Expr.Binary(expr, operator, right);
    }

    return expr;
  }

That’s all of the binary operators, parsed with the correct precedence and associativity. We’re crawling up the precedence hierarchy and now we’ve reached the unary operators.

這就是所有的二元運算子，已經按照正確的優先順序和結合性進行了解析。接下來，按照優先順序層級，我們要處理一元運算子了。

unary          → ( "!" | "-" ) unary
               | primary ;

The code for this is a little different.

該規則對應的程式碼有些不同。

lox/Parser.java，在 factor()方法後新增：

  private Expr unary() {
    if (match(BANG, MINUS)) {
      Token operator = previous();
      Expr right = unary();
      return new Expr.Unary(operator, right);
    }

    return primary();
  }

Again, we look at the current token to see how to parse. If it’s a ! or -, we must have a unary expression. In that case, we grab the token and then recursively call unary() again to parse the operand. Wrap that all up in a unary expression syntax tree and we’re done.

同樣的，我們先檢查當前的標記以確認要如何進行解析¹⁰。如果是!或-，我們一定有一個一元表示式。在這種情況下，我們使用當前的標記遞迴呼叫unary()來解析運算元。將所有這些都包裝到一元表示式語法樹中，我們就完成了。

Otherwise, we must have reached the highest level of precedence, primary expressions.

否則，我們就達到了最高階別的優先順序，即基本表示式。

primary        → NUMBER | STRING | "true" | "false" | "nil"
               | "(" expression ")" ;

Most of the cases for the rule are single terminals, so parsing is straightforward.

該規則中大部分都是終止符，可以直接進行解析。

lox/Parser.java，在 unary()方法後新增：

  private Expr primary() {
    if (match(FALSE)) return new Expr.Literal(false);
    if (match(TRUE)) return new Expr.Literal(true);
    if (match(NIL)) return new Expr.Literal(null);

    if (match(NUMBER, STRING)) {
      return new Expr.Literal(previous().literal);
    }

    if (match(LEFT_PAREN)) {
      Expr expr = expression();
      consume(RIGHT_PAREN, "Expect ')' after expression.");
      return new Expr.Grouping(expr);
    }
  }

The interesting branch is the one for handling parentheses. After we match an opening ( and parse the expression inside it, we must find a ) token. If we don’t, that’s an error.

有趣的一點是處理括號的分支。當我們匹配了一個開頭(並解析了裡面的表示式後，我們必須找到一個)標記。如果沒有找到，那就是一個錯誤。

6 . 3 Syntax Errors

6.3 語法錯誤

A parser really has two jobs:

解析器實際上有兩項工作：

1. Given a valid sequence of tokens, produce a corresponding syntax tree.

   給定一個有效的標記序列，生成相應的語法樹。

2. Given an invalid sequence of tokens, detect any errors and tell the user about their mistakes.

   給定一個無效的標記序列，檢測錯誤並告知使用者。

Don’t underestimate how important the second job is! In modern IDEs and editors, the parser is constantly reparsing code—often while the user is still editing it—in order to syntax highlight and support things like auto-complete. That means it will encounter code in incomplete, half-wrong states all the time.

不要低估第二項工作的重要性！在現代的IDE和編輯器中，為了語法高亮顯示和支援自動補齊等功能，當使用者還在編輯程式碼時，解析器就會不斷地重新解析程式碼。這也意味著解析器總是會遇到不完整的、半錯誤狀態的程式碼。

When the user doesn’t realize the syntax is wrong, it is up to the parser to help guide them back onto the right path. The way it reports errors is a large part of your language’s user interface. Good syntax error handling is hard. By definition, the code isn’t in a well-defined state, so there’s no infallible way to know what the user meant to write. The parser can’t read your mind.

當使用者沒有意識到語法錯誤時，解析器要幫助引導他們回到正確的道路上。在你的語言的人機互動中，錯誤反饋佔據了很大的比重。良好的語法錯誤處理是很難的。根據定義，程式碼並不是處於良好定義的狀態，所以沒有可靠的方法能夠知道使用者想要寫什麼。解析器無法讀懂你的思想。

There are a couple of hard requirements for when the parser runs into a syntax error. A parser must:

當解析器遇到語法錯誤時，有幾個硬性要求。解析器必須能夠：

• Detect and report the error. If it doesn’t detect the error and passes the resulting malformed syntax tree on to the interpreter, all manner of horrors may be summoned.

  檢測並報告錯誤。如果它沒有檢測到錯誤，並將由此產生的畸形語法樹傳遞給直譯器，就會出現各種可怕的情況。

• Avoid crashing or hanging. Syntax errors are a fact of life, and language tools have to be robust in the face of them. Segfaulting or getting stuck in an infinite loop isn’t allowed. While the source may not be valid code, it’s still a valid input to the parser because users use the parser to learn what syntax is allowed.

  避免崩潰或掛起。語法錯誤是生活中不可避免的事實，面對語法錯誤，語言工具必須非常健壯。段錯誤或陷入無限迴圈是不允許的。雖然原始碼可能不是有效的程式碼，但它仍然是解析器的有效輸入，因為使用者使用解析器來瞭解什麼是允許的語法。

Those are the table stakes if you want to get in the parser game at all, but you really want to raise the ante beyond that. A decent parser should:

如果你想參與到解析器的遊戲中來，這些就是桌面的籌碼，但你真的想提高賭注，除了這些。一個像樣的解析器還應該：

• Be fast. Computers are thousands of times faster than they were when parser technology was first invented. The days of needing to optimize your parser so that it could get through an entire source file during a coffee break are over. But programmer expectations have risen as quickly, if not faster. They expect their editors to reparse files in milliseconds after every keystroke.

  要快。計算機的速度比最初發明解析器技術時快了幾千倍。那種需要最佳化解析器，以便它能在喝咖啡的時候處理完整個原始檔的日子已經一去不復返了。但是程式設計師的期望值也上升得同樣快，甚至更快。他們希望他們的編輯器能在每次擊鍵後的幾毫秒內回覆檔案。

• Report as many distinct errors as there are. Aborting after the first error is easy to implement, but it’s annoying for users if every time they fix what they think is the one error in a file, a new one appears. They want to see them all.

  儘可能多地報告出不同的錯誤。在第一個錯誤後中止是很容易實現的，但是如果每次當使用者修復檔案中的一個錯誤時，又出現了另一個新的錯誤，這對使用者來說是很煩人的。他們希望一次看到所有的錯誤。

• Minimize *cascaded* errors. Once a single error is found, the parser no longer really knows what’s going on. It tries to get itself back on track and keep going, but if it gets confused, it may report a slew of ghost errors that don’t indicate other real problems in the code. When the first error is fixed, those phantoms disappear, because they reflect only the parser’s own confusion. Cascaded errors are annoying because they can scare the user into thinking their code is in a worse state than it is.

  最小化級聯錯誤。一旦發現一個錯誤，解析器就不再能知道發生了什麼。它會試圖讓自己回到正軌並繼續工作，但如果它感到混亂，它可能會報告大量的幽靈錯誤，而這些錯誤並不表明程式碼中存在其它問題。當第一個錯誤被修正後，這些幽靈錯誤就消失了，因為它們只反映瞭解析器自身的混亂。級聯錯誤很煩人，因為它們會讓使用者害怕，讓使用者認為自己的程式碼比實際情況更糟糕。

The last two points are in tension. We want to report as many separate errors as we can, but we don’t want to report ones that are merely side effects of an earlier one.

最後兩點是相互矛盾的。我們希望儘可能多地報告單獨的錯誤，但我們不想報告那些只是由早期錯誤的副作用導致的錯誤。

The way a parser responds to an error and keeps going to look for later errors is called error recovery. This was a hot research topic in the ’60s. Back then, you’d hand a stack of punch cards to the secretary and come back the next day to see if the compiler succeeded. With an iteration loop that slow, you really wanted to find every single error in your code in one pass.

解析器對一個錯誤做出反應，並繼續去尋找後面的錯誤的方式叫做錯誤恢復。這在60年代是一個熱門的研究課題。那時，你需要把一疊打孔卡交給秘書，第二天再來看看編譯器是否成功。在迭代迴圈如此緩慢的情況下，你真的會想在一次執行中找到程式碼中的每個錯誤。

Today, when parsers complete before you’ve even finished typing, it’s less of an issue. Simple, fast error recovery is fine.

如今，解析器在您甚至還沒有完成輸入之前就完成解析了，這不再是一個問題。 簡單，快速的錯誤恢復就可以了。

6 . 3 . 1 Panic mode error recovery

6.3.1 恐慌模式錯誤恢復

Of all the recovery techniques devised in yesteryear, the one that best stood the test of time is called—somewhat alarmingly—panic mode. As soon as the parser detects an error, it enters panic mode. It knows at least one token doesn’t make sense given its current state in the middle of some stack of grammar productions.

在過去設計的所有恢復技術中，最能經受住時間考驗的一種叫做恐慌模式（有點令人震驚）。一旦解析器檢測到一個錯誤，它就會進入恐慌模式。它知道至少有一個token是沒有意義的，因為它目前的狀態是在一些語法生成式的堆疊中間。

Before it can get back to parsing, it needs to get its state and the sequence of forthcoming tokens aligned such that the next token does match the rule being parsed. This process is called synchronization.

在程式繼續進行解析之前，它需要將自己的狀態和即將到來的標記序列對齊，使下一個標記能夠匹配正則解析的規則。這個過程稱為同步。

To do that, we select some rule in the grammar that will mark the synchronization point. The parser fixes its parsing state by jumping out of any nested productions until it gets back to that rule. Then it synchronizes the token stream by discarding tokens until it reaches one that can appear at that point in the rule.

為此，我們在語法中選擇一些規則來標記同步點。解析器會跳出所有巢狀的生成式直到回退至該規則中，來修復其解析狀態。然後，它會丟棄標記，直到遇到一個可以匹配該規則的標記，以此來同步標記流。

Any additional real syntax errors hiding in those discarded tokens aren’t reported, but it also means that any mistaken cascaded errors that are side effects of the initial error aren’t falsely reported either, which is a decent trade-off.

這些被丟棄的標記中隱藏的其它真正的語法錯誤都不會被報告，但是這也意味著由初始錯誤引起的其它級聯錯誤也不會被錯誤地報告出來，這是個不錯的權衡。

The traditional place in the grammar to synchronize is between statements. We don’t have those yet, so we won’t actually synchronize in this chapter, but we’ll get the machinery in place for later.

語法中傳統的要同步的地方是語句之間。我們還沒有這些，所以我們不會在這一章中真正地同步，但我們會在以後把這些機制準備好。

6 . 3 . 2 Entering panic mode

6.3.2 進入恐慌模式

Back before we went on this side trip around error recovery, we were writing the code to parse a parenthesized expression. After parsing the expression, it looks for the closing ) by calling consume(). Here, finally, is that method:

在我們討論錯誤恢復之前，我們正在編寫解析括號表示式的程式碼。在解析表示式之後，會呼叫consume()方法查詢收尾的)。這裡，終於可以實現那個方法了：

lox/Parser.java，在 match()方法後新增：

  private Token consume(TokenType type, String message) {
    if (check(type)) return advance();

    throw error(peek(), message);
  }

It’s similar to match() in that it checks to see if the next token is of the expected type. If so, it consumes it and everything is groovy. If some other token is there, then we’ve hit an error. We report it by calling this:

它和 match()方法類似，檢查下一個標記是否是預期的型別。如果是，它就會消費該標記，一切都很順利。如果是其它的標記，那麼我們就遇到了錯誤。我們透過呼叫下面的方法來報告錯誤：

lox/Parser.java，在 previous()方法後新增：

  private ParseError error(Token token, String message) {
    Lox.error(token, message);
    return new ParseError();
  }

First, that shows the error to the user by calling:

首先，透過呼叫下面的方法向用戶展示錯誤資訊：

lox/Lox.java，在 report()方法後新增：

  static void error(Token token, String message) {
    if (token.type == TokenType.EOF) {
      report(token.line, " at end", message);
    } else {
      report(token.line, " at '" + token.lexeme + "'", message);
    }
  }

This reports an error at a given token. It shows the token’s location and the token itself. This will come in handy later since we use tokens throughout the interpreter to track locations in code.

該方法會報告給定標記處的錯誤。它顯示了標記的位置和標記本身。這在以後會派上用場，因為我們在整個直譯器中使用標記來跟蹤程式碼中的位置。

After we report the error, the user knows about their mistake, but what does the parser do next? Back in error(), we create and return a ParseError, an instance of this new class:

在我們報告錯誤後，使用者知道了他們的錯誤，但接下來解析器要做什麼呢？回到error()方法中，我們建立並返回了一個ParseError，是下面這個新類的例項:

lox/Parser.java，在 Parser中嵌入內部類：

class Parser {  
  // 新增部分開始
  private static class ParseError extends RuntimeException {}
  // 新增部分結束
  private final List<Token> tokens;

This is a simple sentinel class we use to unwind the parser. The error() method returns the error instead of throwing it because we want to let the calling method inside the parser decide whether to unwind or not. Some parse errors occur in places where the parser isn’t likely to get into a weird state and we don’t need to synchronize. In those places, we simply report the error and keep on truckin’.

這是一個簡單的哨兵類，我們用它來幫助解析器擺脫錯誤。error()方法是返回錯誤而不是丟擲錯誤，因為我們希望解析器內的呼叫方法決定是否要跳脫出該錯誤。有些解析錯誤發生在解析器不可能進入異常狀態的地方，這時我們就不需要同步。在這些地方，我們只需要報告錯誤，然後繼續解析。

For example, Lox limits the number of arguments you can pass to a function. If you pass too many, the parser needs to report that error, but it can and should simply keep on parsing the extra arguments instead of freaking out and going into panic mode.

例如，Lox限制了你可以傳遞給一個函式的引數數量。如果你傳遞的引數太多，解析器需要報告這個錯誤，但它可以而且應該繼續解析額外的引數，而不是驚慌失措，進入恐慌模式¹¹。

In our case, though, the syntax error is nasty enough that we want to panic and synchronize. Discarding tokens is pretty easy, but how do we synchronize the parser’s own state?

但是，在我們的例子中，語法錯誤非常嚴重，以至於我們要進入恐慌模式並進行同步。丟棄標記非常簡單，但是我們如何同步解析器自己的狀態呢？

6 . 3 . 3 Synchronizing a recursive descent parser

6.3.3 同步遞迴下降解析器

With recursive descent, the parser’s state—which rules it is in the middle of recognizing—is not stored explicitly in fields. Instead, we use Java’s own call stack to track what the parser is doing. Each rule in the middle of being parsed is a call frame on the stack. In order to reset that state, we need to clear out those call frames.

在遞迴下降中，解析器的狀態（即它正在識別哪個規則）不是顯式儲存在欄位中的。相反，我們使用Java自身的呼叫棧來跟蹤解析器正在做什麼。每一條正在被解析的規則都是棧上的一個呼叫幀。為了重置狀態，我們需要清除這些呼叫幀。

The natural way to do that in Java is exceptions. When we want to synchronize, we throw that ParseError object. Higher up in the method for the grammar rule we are synchronizing to, we’ll catch it. Since we synchronize on statement boundaries, we’ll catch the exception there. After the exception is caught, the parser is in the right state. All that’s left is to synchronize the tokens.

在Java中，最自然的實現方式是異常。當我們想要同步時，我們丟擲ParseError物件。在我們正同步的語法規則的方法上層，我們將捕獲它。因為我們在語句邊界上同步，所以我們可以在那裡捕獲異常。捕獲異常後，解析器就處於正確的狀態。剩下的就是同步標記了。

We want to discard tokens until we’re right at the beginning of the next statement. That boundary is pretty easy to spot—it’s one of the main reasons we picked it. After a semicolon, we’re probably finished with a statement. Most statements start with a keyword—for, if, return, var, etc. When the next token is any of those, we’re probably about to start a statement.

我們想要丟棄標記，直至達到下一條語句的開頭。這個邊界很容易發現——這也是我們選其作為邊界的原因。在分號之後，我們可能就結束了一條語句¹²。大多數語句都透過一個關鍵字開頭——for、 if、 return、 var等等。當下一個標記是其中之一時，我們可能就要開始一條新語句了。

This method encapsulates that logic:

下面的方法封裝了這個邏輯：

lox/Parser.java，在 error()方法後新增：

  private void synchronize() {
    advance();

    while (!isAtEnd()) {
      if (previous().type == SEMICOLON) return;

      switch (peek().type) {
        case CLASS:
        case FUN:
        case VAR:
        case FOR:
        case IF:
        case WHILE:
        case PRINT:
        case RETURN:
          return;
      }

      advance();
    }
  }

It discards tokens until it thinks it has found a statement boundary. After catching a ParseError, we’ll call this and then we are hopefully back in sync. When it works well, we have discarded tokens that would have likely caused cascaded errors anyway, and now we can parse the rest of the file starting at the next statement.

該方法會不斷丟棄標記，直到它發現一個語句的邊界。在捕獲一個ParseError後，我們會呼叫該方法，然後我們就有望回到同步狀態。當它工作順利時，我們就已經丟棄了無論如何都可能會引起級聯錯誤的語法標記，現在我們可以從下一條語句開始解析檔案的其餘部分。

Alas, we don’t get to see this method in action, since we don’t have statements yet. We’ll get to that in a couple of chapters. For now, if an error occurs, we’ll panic and unwind all the way to the top and stop parsing. Since we can parse only a single expression anyway, that’s no big loss.

唉，我們還沒有看到這個方法的實際應用，因為我們目前還沒有語句。我們會在後面幾章中開始引入語句。現在，如果出現錯誤，我們就會進入恐慌模式，一直跳出到最頂層，並停止解析。由於我們只能解析一個表示式，所以這並不是什麼大損失。

6 . 4 Wiring up the Parser

6.4 調整解析器

We are mostly done parsing expressions now. There is one other place where we need to add a little error handling. As the parser descends through the parsing methods for each grammar rule, it eventually hits primary(). If none of the cases in there match, it means we are sitting on a token that can’t start an expression. We need to handle that error too.

我們現在基本上已經完成了對錶達式的解析。我們還需要在另一個地方新增一些錯誤處理。當解析器在每個語法規則的解析方法中下降時，它最終會進入primary()。如果該方法中的case都不匹配，就意味著我們正面對一個不是表示式開頭的語法標記。我們也需要處理這個錯誤。

lox/Parser.java，在 primary()方法中新增：

    if (match(LEFT_PAREN)) {
      Expr expr = expression();
      consume(RIGHT_PAREN, "Expect ')' after expression.");
      return new Expr.Grouping(expr);
    }
    // 新增部分開始
    throw error(peek(), "Expect expression.");
    // 新增部分結束
  }

With that, all that remains in the parser is to define an initial method to kick it off. That method is called, naturally enough, parse().

這樣，解析器中剩下的工作就是定義一個初始方法來啟動它。這個方法自然應該叫做parse()。

lox/Parser.java，在 Parser()方法後新增：

  Expr parse() {
    try {
      return expression();
    } catch (ParseError error) {
      return null;
    }
  }

We’ll revisit this method later when we add statements to the language. For now, it parses a single expression and returns it. We also have some temporary code to exit out of panic mode. Syntax error recovery is the parser’s job, so we don’t want the ParseError exception to escape into the rest of the interpreter.

稍後在向語言中新增語句時，我們將重新審視這個方法。目前，它只解析一個表示式並返回它。我們還有一些臨時程式碼用於退出恐慌模式。語法錯誤恢復是解析器的工作，所以我們不希望ParseError異常逃逸到直譯器的其它部分。

When a syntax error does occur, this method returns null. That’s OK. The parser promises not to crash or hang on invalid syntax, but it doesn’t promise to return a usable syntax tree if an error is found. As soon as the parser reports an error, hadError gets set, and subsequent phases are skipped.

當確實出現語法錯誤時，該方法會返回null。這沒關係。解析器承諾不會因為無效語法而崩潰或掛起，但它不承諾在發現錯誤時返回一個可用的語法樹。一旦解析器報告錯誤，就會對hadError賦值，然後跳過後續階段。

Finally, we can hook up our brand new parser to the main Lox class and try it out. We still don’t have an interpreter, so for now, we’ll parse to a syntax tree and then use the AstPrinter class from the last chapter to display it.

最後，我們可以將全新的解析器掛到Lox主類並進行試驗。我們仍然還沒有直譯器，所以現在，我們將表示式解析為一個語法樹，然後使用上一章中的AstPrinter類來顯示它。

Delete the old code to print the scanned tokens and replace it with this:

刪除列印已掃描標記的舊程式碼，將其替換為：

lox/Lox.java，在 run()方法中，替換其中5行

    List<Token> tokens = scanner.scanTokens();
    // 替換部分開始
    Parser parser = new Parser(tokens);
    Expr expression = parser.parse();

    // Stop if there was a syntax error.
    if (hadError) return;

    System.out.println(new AstPrinter().print(expression));
    // 替換部分結束
  }

Congratulations, you have crossed the threshold! That really is all there is to handwriting a parser. We’ll extend the grammar in later chapters with assignment, statements, and other stuff, but none of that is any more complex than the binary operators we tackled here.

祝賀你，你已經跨過了門檻!這就是手寫解析器的全部內容¹³。我們將在後面的章節中擴充套件賦值、語句和其它特性對應的語法，但這些都不會比我們本章處理的二元運算子更復雜。

Fire up the interpreter and type in some expressions. See how it handles precedence and associativity correctly? Not bad for less than 200 lines of code.

啟動直譯器並輸入一些表示式。檢視它是如何正確處理優先順序和結合性的?這對於不到200行程式碼來說已經很不錯了。

CHALLENGES

習題

1、In C, a block is a statement form that allows you to pack a series of statements where a single one is expected. The comma operator is an analogous syntax for expressions. A comma-separated series of expressions can be given where a single expression is expected (except inside a function call’s argument list). At runtime, the comma operator evaluates the left operand and discards the result. Then it evaluates and returns the right operand.

Add support for comma expressions. Give them the same precedence and associativity as in C. Write the grammar, and then implement the necessary parsing code.

1、在C語言中，塊是一種語句形式，它允許你把一系列的語句打包作為一個語句來使用。逗號運算子是表示式的類似語法。可以在需要單個表示式的地方給出以逗號分隔的表示式序列(函式呼叫的引數列表除外)。在執行時，逗號運算子計算左運算元並丟棄結果。然後計算並返回右運算元。

新增對逗號表示式的支援。賦予它們與c語言中相同的優先順序和結合性。編寫語法，然後實現必要的解析程式碼。

2、Likewise, add support for the C-style conditional or “ternary” operator ?:. What precedence level is allowed between the ? and :? Is the whole operator left-associative or right-associative?

2、同樣，新增對C風格的條件運算子或 "三元 "運算子?:的支援。在?和:之間採用什麼優先順序順序？整個運算子是左關聯還是右關聯？

3、Add error productions to handle each binary operator appearing without a left-hand operand. In other words, detect a binary operator appearing at the beginning of an expression. Report that as an error, but also parse and discard a right-hand operand with the appropriate precedence.

3、新增錯誤生成式處理沒有左運算元的二元運算子。換句話說，檢測出現在表示式開頭的二元運算子。將其作為錯誤報告給使用者，同時也要解析並丟棄具有相應優先順序的右運算元。

DESIGN NOTE: LOGIC VERSUS HISTORY

Let’s say we decide to add bitwise & and | operators to Lox. Where should we put them in the precedence hierarchy? C—and most languages that follow in C’s footsteps—place them below ==. This is widely considered a mistake because it means common operations like testing a flag require parentheses.

if (flags & FLAG_MASK == SOME_FLAG) { ... } // Wrong.
if ((flags & FLAG_MASK) == SOME_FLAG) { ... } // Right.

Should we fix this for Lox and put bitwise operators higher up the precedence table than C does? There are two strategies we can take.

You almost never want to use the result of an == expression as the operand to a bitwise operator. By making bitwise bind tighter, users don’t need to parenthesize as often. So if we do that, and users assume the precedence is chosen logically to minimize parentheses, they’re likely to infer it correctly.

This kind of internal consistency makes the language easier to learn because there are fewer edge cases and exceptions users have to stumble into and then correct. That’s good, because before users can use our language, they have to load all of that syntax and semantics into their heads. A simpler, more rational language makes sense.

But, for many users there is an even faster shortcut to getting our language’s ideas into their wetware—use concepts they already know. Many newcomers to our language will be coming from some other language or languages. If our language uses some of the same syntax or semantics as those, there is much less for the user to learn (and unlearn).

This is particularly helpful with syntax. You may not remember it well today, but way back when you learned your very first programming language, code probably looked alien and unapproachable. Only through painstaking effort did you learn to read and accept it. If you design a novel syntax for your new language, you force users to start that process all over again.

Taking advantage of what users already know is one of the most powerful tools you can use to ease adoption of your language. It’s almost impossible to overestimate how valuable this is. But it faces you with a nasty problem: What happens when the thing the users all know kind of sucks? C’s bitwise operator precedence is a mistake that doesn’t make sense. But it’s a familiar mistake that millions have already gotten used to and learned to live with.

Do you stay true to your language’s own internal logic and ignore history? Do you start from a blank slate and first principles? Or do you weave your language into the rich tapestry of programming history and give your users a leg up by starting from something they already know?

There is no perfect answer here, only trade-offs. You and I are obviously biased towards liking novel languages, so our natural inclination is to burn the history books and start our own story.

In practice, it’s often better to make the most of what users already know. Getting them to come to your language requires a big leap. The smaller you can make that chasm, the more people will be willing to cross it. But you can’t always stick to history, or your language won’t have anything new and compelling to give people a reason to jump over.

設計筆記：邏輯和歷史

假設我們決定在Lox中新增位元&和|運算子。我們應該將它們放在優先順序層次結構的哪個位置？ C（以及大多數跟隨C語言步伐的語言）將它們放在==之下。 目前普遍認為這是一個錯誤，因為這意味著檢測標誌位等常用操作都需要加括號。

if (flags & FLAG_MASK == SOME_FLAG) { ... } // Wrong.
if ((flags & FLAG_MASK) == SOME_FLAG) { ... } // Right.

我們是否應該在 Lox 中修正這個問題，為位運算子賦予比 C 中更高的優先順序？我們可以採取兩種策略。

幾乎可以肯定你不會想把==表示式的計算結果當作位運算的運算元。將位運算操作繫結更緊密，使用者就不需要像以前那樣經常使用括號。所以如果我們這樣做，並且使用者認為優先順序的選擇是合乎邏輯的，是為了儘量減少小括號，他們很可能會正確地推斷出來。

這種內部一致性使語言更容易學習，因為使用者需要糾正的邊界情況和異常變少了。這很好，因為使用者在使用我們的語言之前，需要先理解所有的語法和語義。一個更簡單、更合理的語言是有意義的。

但是，對於許多使用者來說，有一個更快的捷徑，可以將我們語言的思想融入他們的溼件中——使用他們已經知道的概念。許多我們語言的新使用者都使用過其它一門或多門語言。如果我們的語言使用了與那些語言相同的一些語法或語義，那麼使用者需要學習（和忘掉）的東西就會少很多。

這對詞法語法特別有幫助。您現在可能不太記得了，但是回想一下您學習第一門程式語言時，程式碼看起來似乎很陌生且難以理解。 只有透過艱苦的努力，您才學會閱讀和接受它。 如果你為你的新語言設計了一種新穎的語法，你就會迫使使用者重新開始這個過程。

利用使用者已經知道的知識，是你可以用來簡化語言採用的最強大的工具之一。這一點的價值怎麼估計都不過分。但它也給你帶來了一個棘手的問題：如果使用者都知道的東西有點糟糕時，會發生什麼？C語言的位運算運算子優先是一個沒有意義的錯誤。但這是一個數以百萬計的人已經習慣並學會忍受的熟悉錯誤。

你是否忠於語言的內在邏輯而忽略歷史？你是從一張白紙和基本原則開始的嗎？還是把你的語言編織到豐富的程式設計歷史中去，從使用者已經知道的東西開始，使您的使用者受益？

這裡沒有完美的答案，只有權衡取捨。你和我顯然都傾向於喜歡新奇的語言，所以我們的自然傾向是燒掉歷史書，開始我們自己的故事。

在實踐中，充分利用使用者已經知道的知識往往更好。讓他們來使用你的語言需要一個大的跨越。兩個語言間的鴻溝越小，人們就越願意跨越它。但你不能總是拘泥於歷史，否則你的語言就不會有什麼新穎的、令人信服的東西讓使用者們有理由跳過去。

1. 英語中的"Parse "來自古法語 "pars"，意為 "語言的一部分"。它的意思是取一篇文章，把每一個詞都對映到語言的語法上。我們在這裡使用它也是這個意思，只不過我們的語言比古法語更現代一些。 ↩

2. 可以想見，在那些老機器上進行彙編程式設計是多麼痛苦，以至於他們認為Fortran是一種改進。 ↩

3. 雖然現在並不常見，但有些語言規定某些運算子之間沒有相對優先順序。這種語言中，在表示式中混合使用這些運算子而不使用顯式分組是一種語法錯誤。同樣，有些運算子是非結合的。這意味著在語句序列中多次使用該運算子是錯誤的。例如，Perl的範圍運算子是非結合的，所以a ..b是可以的，但是a ..b . .c是錯誤的。 ↩

4. 一些解析器生成器並沒有將優先順序直接寫入語法規則中，而是允許你保持同樣的模糊但簡單的語法，然後在旁邊新增一點明確的運算子優先順序後設資料，以消除歧義。 ↩

5. 我們可以取消expression，而只是在其他包含表示式的規則中使用equality，但使用expression會使這些其他規則可讀性更好。另外，在後面的章節中，當我們將語法擴充套件到包括賦值和邏輯運算子時，我們只需要改變expression的生成式，而不需要修改每條包含expression的規則。 ↩

6. 原則上，你把乘法當作左關聯還是右關聯都沒有關係——無論你使用哪種方式都可以得到相同的結果。但是，在精度有限的情況下，舍入和溢位意味著關聯性會影響乘法序列的計算結果。如print 0. 1 * (0. 2 * 0. 3);和print (0.1 * 0.2) * 0.3;，在Lox等使用IEEE 754雙精度浮點數的語言中，第一個算式的計算結果是0.006，而第二個算式的計算結果是0.006000000000000001。有時，這種微小的差異很重要。可以在這裡瞭解更多資訊。 ↩

7. 該方法之所以被稱為“遞迴下降”，是因為它是沿著語法向下執行的。令人困惑的是，在談論“高”和“低”優先順序時，我們也使用方向來比喻，但是方向卻是相反的。在自頂向下的解析器中，首先達到優先順序最低的表示式，因為其中可能包含優先順序更高的子表示式。
   
   CS的人真的需要聚在一起理清他們的隱喻。甚至不要讓我開始討論堆疊向哪個方向生長，或者為什麼樹的根在上面。 ↩

8. 這就是為什麼左遞迴對於遞迴下降是有問題的。左遞迴規則的函式會立即呼叫自身，並迴圈往復，直到解析器遇到堆疊溢位並崩潰。 ↩

9. 解析a==b==c==d。對於每一次迭代，使用前一個子式結果作為左運算元並建立一個新的二元表示式。 ↩

10. 解析器提前觀察即將到來的標記來決定如何解析，這就把遞迴下降納入了預測性解析器的範疇。 ↩

11. 另一種處理常見語法錯誤的方法是錯誤生成式。你可以使用一個能成功匹配錯誤語法的規則來擴充語法。解析器可以對其進行安全地解析，但是不會生成語法樹，而是會報告一個錯誤。
    舉例來說，有些語言中有一元運算子+，如+123，但是Lox不支援。當解析器在表示式的開頭遇到一個+時，我們不必感到困惑，我們可以擴充套件一元規則來允許該語法。
    unary → ( "!" | "-" | "+" ) unary | primary ;
    這樣解析器就會消費+標記，而不是進入恐慌模式或讓解析器陷入奇怪的狀態。
    錯誤生成式的效果很好。因為你作為解析器的作者，知道程式碼的如何出錯的以及使用者想要做什麼。這意味著你可以給出一個更有用的資訊來幫助使用者回到正軌，比如，"不支援一元'+'表示式"。成熟的解析器往往會積累錯誤生成式，因為它們可以幫助使用者修復常見的錯誤。 ↩

12. 我說 "可能 "是因為我們可以在for迴圈中碰到分隔子句的分號。我們的同步並不完美，但這沒關係。我們已經準確地報告了第一個錯誤，所以之後的一切都算是 "盡力而為 "了。 ↩

13. 你可能會定義一個比Lox更復雜的語法，使用遞迴下降法難以對其解析。當你可能需要預先檢視大量的標記以弄清你面臨的情況時，預測性解析就變得很棘手。實際上，大多數語言都是為了避免這種情況而設計的。 即使情況並非如此，您通常也可以毫不費力地解決問題。 既然您可以使用遞迴下降來解析C ++（許多C ++編譯器都可以做到），那麼您就可以解析任何內容。 ↩

7.表示式求值

You are my creator, but I am your master; Obey!

​ —— Mary Shelley, Frankenstein

你是我的創造者，但我是你的主人，聽話！

​ ——Mary Shelley, 科學怪人

If you want to properly set the mood for this chapter, try to conjure up a thunderstorm, one of those swirling tempests that likes to yank open shutters at the climax of the story. Maybe toss in a few bolts of lightning. In this chapter, our interpreter will take breath, open its eyes, and execute some code.

如果你想為這一章適當地設定氣氛，試著想象一場雷雨，那種在故事高潮時喜歡拉開百葉窗的漩渦式暴風雨。也許再加上幾道閃電。在這一章中，我們的直譯器將開始呼吸，睜開眼睛，並執行一些程式碼。

There are all manner of ways that language implementations make a computer do what the user’s source code commands. They can compile it to machine code, translate it to another high-level language, or reduce it to some bytecode format for a virtual machine to run. For our first interpreter, though, we are going to take the simplest, shortest path and execute the syntax tree itself.

對於語言實現來說，有各種方式可以使計算機執行使用者的原始碼命令。它們可以將其編譯為機器程式碼，將其翻譯為另一種高階語言，或者將其還原為某種位元組碼格式，以便在虛擬機器中執行。不過對於我們的第一個直譯器，我們要選擇最簡單、最短的一條路，也就是執行語法樹本身。

Right now, our parser only supports expressions. So, to “execute” code, we will evaluate an expression and produce a value. For each kind of expression syntax we can parse—literal, operator, etc.—we need a corresponding chunk of code that knows how to evaluate that tree and produce a result. That raises two questions:

現在，我們的直譯器只支援表示式。因此，為了“執行”程式碼，我們要計算一個表示式時並生成一個值。對於我們可以解析的每一種表示式語法——字面量，運算子等——我們都需要一個相應的程式碼塊，該程式碼塊知道如何計算該語法樹併產生結果。這也就引出了兩個問題：

1. What kinds of values do we produce?

   我們要生成什麼型別的值？

2. How do we organize those chunks of code?

   我們如何組織這些程式碼塊？

Taking them on one at a time . . .

讓我們來逐個擊破。

7 . 1 Representing Values

7.1 值描述

In Lox, values are created by literals, computed by expressions, and stored in variables. The user sees these as Lox objects, but they are implemented in the underlying language our interpreter is written in. That means bridging the lands of Lox’s dynamic typing and Java’s static types. A variable in Lox can store a value of any (Lox) type, and can even store values of different types at different points in time. What Java type might we use to represent that?

在Lox中，值由字面量建立，由表示式計算，並儲存在變數中。使用者將其視作Lox物件¹，但它們是用編寫直譯器的底層語言實現的。這意味著要在Lox的動態型別和Java的靜態型別之間架起橋樑。Lox中的變數可以儲存任何（Lox）型別的值，甚至可以在不同時間儲存不同型別的值。我們可以用什麼Java型別來表示？

Given a Java variable with that static type, we must also be able to determine which kind of value it holds at runtime. When the interpreter executes a + operator, it needs to tell if it is adding two numbers or concatenating two strings. Is there a Java type that can hold numbers, strings, Booleans, and more? Is there one that can tell us what its runtime type is? There is! Good old java.lang.Object.

給定一個具有該靜態型別的Java變數，我們還必須能夠在執行時確定它持有哪種型別的值。當直譯器執行 +運算子時，它需要知道它是在將兩個數字相加還是在拼接兩個字串。有沒有一種Java型別可以容納數字、字串、布林值等等？有沒有一種型別可以告訴我們它的執行時型別是什麼？有的! 就是老牌的java.lang.Object。

In places in the interpreter where we need to store a Lox value, we can use Object as the type. Java has boxed versions of its primitive types that all subclass Object, so we can use those for Lox’s built-in types:

在直譯器中需要儲存Lox值的地方，我們可以使用Object作為型別。Java已經將其基本型別的所有子類物件裝箱了，因此我們可以將它們用作Lox的內建型別：

Given a value of static type Object, we can determine if the runtime value is a number or a string or whatever using Java’s built-in instanceof operator. In other words, the JVM’s own object representation conveniently gives us everything we need to implement Lox’s built-in types. We’ll have to do a little more work later when we add Lox’s notions of functions, classes, and instances, but Object and the boxed primitive classes are sufficient for the types we need right now.

給定一個靜態型別為Object的值，我們可以使用Java內建的instanceof運算子來確定執行時的值是數字、字串或其它什麼。換句話說，JVM自己的物件表示方便地為我們提供了實現Lox內建型別所需的一切²。當稍後新增Lox的函式、類和例項等概念時，我們還必須做更多的工作，但Object和基本型別的包裝類足以滿足我們現在的需要。

7 . 2 Evaluating Expressions

7.2 表示式求值

Next, we need blobs of code to implement the evaluation logic for each kind of expression we can parse. We could stuff that code into the syntax tree classes in something like an interpret() method. In effect, we could tell each syntax tree node, “Interpret thyself”. This is the Gang of Four’s Interpreter design pattern. It’s a neat pattern, but like I mentioned earlier, it gets messy if we jam all sorts of logic into the tree classes.

接下來，我們需要大量的程式碼實現我們可解析的每種表示式對應的求值邏輯。我們可以把這些程式碼放在語法樹的類中，比如新增一個interpret()方法。然後，我們可以告訴每一個語法樹節點“解釋你自己”，這就是四人組的直譯器模式。這是一個整潔的模式，但正如我前面提到的，如果我們將各種邏輯都塞進語法樹類中，就會變得很混亂。

Instead, we’re going to reuse our groovy Visitor pattern. In the previous chapter, we created an AstPrinter class. It took in a syntax tree and recursively traversed it, building up a string which it ultimately returned. That’s almost exactly what a real interpreter does, except instead of concatenating strings, it computes values.

相反，我們將重用我們的訪問者模式。在前面的章節中，我們建立了一個AstPrinter類。它接受一個語法樹，並遞迴地遍歷它，構建一個最終返回的字串。這幾乎就是一個真正的直譯器所做的事情，只不過直譯器不是連線字串，而是計算值。

We start with a new class.

我們先建立一個新類。

lox/Interpreter.java，建立新檔案：

package com.craftinginterpreters.lox;

class Interpreter implements Expr.Visitor<Object> {
}

The class declares that it’s a visitor. The return type of the visit methods will be Object, the root class that we use to refer to a Lox value in our Java code. To satisfy the Visitor interface, we need to define visit methods for each of the four expression tree classes our parser produces. We’ll start with the simplest . . .

這個類宣告它是一個訪問者。訪問方法的返回型別將是Object，即我們在Java程式碼中用來引用Lox值的根類。為了實現Visitor介面，我們需要為解析器生成的四個表示式樹類中分別定義訪問方法。我們從最簡單的開始…

7 . 2 . 1 Evaluating literals

7.2.1 字面量求值

The leaves of an expression tree—the atomic bits of syntax that all other expressions are composed of—are literals. Literals are almost values already, but the distinction is important. A literal is a bit of syntax that produces a value. A literal always appears somewhere in the user’s source code. Lots of values are produced by computation and don’t exist anywhere in the code itself. Those aren’t literals. A literal comes from the parser’s domain. Values are an interpreter concept, part of the runtime’s world.

一個表示式樹的葉子節點（構成其它表示式的語法原子單位）是字面量³。字面符號幾乎已經是值了，但兩者的區別很重要。字面量是產生一個值的語法單元。字面量總是出現在使用者的原始碼中的某個地方。而很多值是透過計算產生的，並不存在於程式碼中的任何地方，這些都不是字面量。字面量來自於解析器領域，而值是一個直譯器的概念，是執行時世界的一部分。

So, much like we converted a literal token into a literal syntax tree node in the parser, now we convert the literal tree node into a runtime value. That turns out to be trivial.

因此，就像我們在解析器中將字面量標記轉換為字面量語法樹節點一樣，現在我們將字面量樹節點轉換為執行時值。這其實很簡單。

lox/Interpreter.java，在 Interpreter類中新增：

  @Override
  public Object visitLiteralExpr(Expr.Literal expr) {
    return expr.value;
  }

We eagerly produced the runtime value way back during scanning and stuffed it in the token. The parser took that value and stuck it in the literal tree node, so to evaluate a literal, we simply pull it back out.

我們早在掃描過程中就即時生成了執行時的值，並把它放進了語法標記中。解析器獲取該值並將其插入字面量語法樹節點中，所以要對字面量求值，我們只需把它存的值取出來。

7 . 2 . 2 Evaluating parentheses

7.2.2 括號求值

The next simplest node to evaluate is grouping—the node you get as a result of using explicit parentheses in an expression.

下一個要求值的節點是分組——在表示式中顯式使用括號時產生的語法樹節點。

lox/Interpreter.java，在 Interpreter類中新增：

  @Override
  public Object visitGroupingExpr(Expr.Grouping expr) {
    return evaluate(expr.expression);
  }

A grouping node has a reference to an inner node for the expression contained inside the parentheses. To evaluate the grouping expression itself, we recursively evaluate that subexpression and return it.

一個分組節點中包含一個引用指向對應於括號內的表示式的內部節點⁴。要想計算括號表示式，我們只需要遞迴地對子表示式求值並返回結果即可。

We rely on this helper method which simply sends the expression back into the interpreter’s visitor implementation:

我們依賴於下面這個輔助方法，它只是將表示式發送回直譯器的訪問者實現中：

lox/Interpreter.java，在 Interpreter類中新增：

  private Object evaluate(Expr expr) {
    return expr.accept(this);

7 . 2 . 3 Evaluating unary expressions

7.2.3 一元表示式求值

Like grouping, unary expressions have a single subexpression that we must evaluate first. The difference is that the unary expression itself does a little work afterwards.

像分組表示式一樣，一元表示式也有一個必須先求值的子表示式。不同的是，一元表示式自身在完成求值之後還會做一些工作。

lox/Interpreter.java，在 visitLiteralExpr()方法後新增：

  @Override
  public Object visitUnaryExpr(Expr.Unary expr) {
    Object right = evaluate(expr.right);

    switch (expr.operator.type) {
      case MINUS:
        return -(double)right;
    }

    // Unreachable.
    return null;
  }

First, we evaluate the operand expression. Then we apply the unary operator itself to the result of that. There are two different unary expressions, identified by the type of the operator token.

首先，我們計算運算元表示式，然後我們將一元運算子作用於子表示式的結果。我們有兩種不同的一元表示式，由運算子標記的型別來區分。

Shown here is -, which negates the result of the subexpression. The subexpression must be a number. Since we don’t statically know that in Java, we cast it before performing the operation. This type cast happens at runtime when the - is evaluated. That’s the core of what makes a language dynamically typed right there.

這裡展示的是-，它會對子表示式的結構取負。子表示式結果必須是數字。因為我們在Java中無法靜態地知道這一點，所以我們在執行操作之前先對其進行強制轉換。這個型別轉換是在執行時對-求值時發生的。這就是將語言動態型別化的核心所在。

You can start to see how evaluation recursively traverses the tree. We can’t evaluate the unary operator itself until after we evaluate its operand subexpression. That means our interpreter is doing a post-order traversal—each node evaluates its children before doing its own work.

你可以看到求值過程是如何遞迴遍歷語法樹的。在對一元運算子本身進行計算之前，我們必須先對其運算元子表示式求值。這表明，直譯器正在進行後序遍歷——每個節點在自己求值之前必須先對子節點求值。

The other unary operator is logical not.

另一個一元運算子是邏輯非。

lox/Interpreter.java，在visitUnaryExpr()方法中新增：

		switch (expr.operator.type) { 
      // 新增部分開始  
			case BANG:
        return !isTruthy(right);
      // 新增部分結束
      case MINUS:

The implementation is simple, but what is this “truthy” thing about? We need to make a little side trip to one of the great questions of Western philosophy: What is truth?

實現很簡單，但是這裡的“真實”指的是什麼呢？我們需要簡單地討論一下西方哲學中的一個偉大問題：什麼是真理？

7 . 2 . 4 Truthiness and falsiness

7.2.4 真與假

OK, maybe we’re not going to really get into the universal question, but at least inside the world of Lox, we need to decide what happens when you use something other than true or false in a logic operation like ! or any other place where a Boolean is expected.

好吧，我們不會真正深入這個普世的問題，但是至少在Lox的世界中，我們需要確定當您在邏輯運算（如!或其他任何需要布林值的地方）中使用非true或false以外的東西時會發生什麼？

We could just say it’s an error because we don’t roll with implicit conversions, but most dynamically typed languages aren’t that ascetic. Instead, they take the universe of values of all types and partition them into two sets, one of which they define to be “true”, or “truthful”, or (my favorite) “truthy”, and the rest which are “false” or “falsey”. This partitioning is somewhat arbitrary and gets weird in a few languages.

我們可以說這是一個錯誤，因為我們沒有使用隱式轉換，但是大多數動態型別語言並不那麼嚴格。相反，他們把所有型別的值分成兩組，其中一組他們定義為“真”，其餘為“假”。這種劃分有些武斷，在一些語言中會變得很奇怪⁵。

Lox follows Ruby’s simple rule: false and nil are falsey, and everything else is truthy. We implement that like so:

Lox遵循Ruby的簡單規則：false和nil是假的，其他都是真的。我們是這樣實現的：

lox/Interpreter.java，在 visitUnaryExpr()方法後新增：

  private boolean isTruthy(Object object) {
    if (object == null) return false;
    if (object instanceof Boolean) return (boolean)object;
    return true;
  }

7 . 2 . 5 Evaluating binary operators

7.2.5 二元運算子求值

On to the last expression tree class, binary operators. There’s a handful of them, and we’ll start with the arithmetic ones.

來到最後的表示式樹類——二元運算子，其中包含很多運算子，我們先從數學運算開始。

lox/Interpreter.java，在 evaluate()方法後新增⁶：

  @Override
  public Object visitBinaryExpr(Expr.Binary expr) {
    Object left = evaluate(expr.left);
    Object right = evaluate(expr.right); 

    switch (expr.operator.type) {
      case MINUS:
        return (double)left - (double)right;
      case SLASH:
        return (double)left / (double)right;
      case STAR:
        return (double)left * (double)right;
    }

    // Unreachable.
    return null;
  }

I think you can figure out what’s going on here. The main difference from the unary negation operator is that we have two operands to evaluate.

我想你能理解這裡的實現。與一元取負運算子的主要區別是，我們有兩個運算元要計算。

I left out one arithmetic operator because it’s a little special.

我漏掉了一個算術運算子，因為它有點特殊。

lox/Interpreter.java，在 visitBinaryExpr()方法中新增：

    switch (expr.operator.type) {
      case MINUS:
        return (double)left - (double)right;
      // 新增部分開始
      case PLUS:
        if (left instanceof Double && right instanceof Double) {
          return (double)left + (double)right;
        } 

        if (left instanceof String && right instanceof String) {
          return (String)left + (String)right;
        }

        break;
      // 新增部分結束
      case SLASH:

The + operator can also be used to concatenate two strings. To handle that, we don’t just assume the operands are a certain type and cast them, we dynamically check the type and choose the appropriate operation. This is why we need our object representation to support instanceof.

+運算子也可以用來拼接兩個字串。為此，我們不能只是假設運算元是某種型別並將其強制轉換，而是要動態地檢查運算元型別並選擇適當的操作。這就是為什麼我們需要物件表示能支援instanceof。

Next up are the comparison operators.

接下來是比較運算子。

lox/Interpreter.java，在 visitBinaryExpr()方法中新增：

    switch (expr.operator.type) {
			// 新增部分開始
      case GREATER:
        return (double)left > (double)right;
      case GREATER_EQUAL:
        return (double)left >= (double)right;
      case LESS:
        return (double)left < (double)right;
      case LESS_EQUAL:
        return (double)left <= (double)right;
      // 新增部分結束
      case MINUS:

They are basically the same as arithmetic. The only difference is that where the arithmetic operators produce a value whose type is the same as the operands (numbers or strings), the comparison operators always produce a Boolean.

它們基本上與算術運算子相同。唯一的區別是，算術運算子產生的值的型別與運算元（數字或字串）相同，而比較運算子總是產生一個布林值。

The last pair of operators are equality.

最後一對是等式運算子。

lox/Interpreter.java，在 visitBinaryExpr()方法中新增：

      case BANG_EQUAL: return !isEqual(left, right);
      case EQUAL_EQUAL: return isEqual(left, right);

Unlike the comparison operators which require numbers, the equality operators support operands of any type, even mixed ones. You can’t ask Lox if 3 is less than "three", but you can ask if it’s equal to it.

與需要數字的比較運算子不同，等式運算子支援任何型別的運算元，甚至是混合型別。你不能問Lox 3是否小於"three"，但你可以問它3是否等於"three"。

Like truthiness, the equality logic is hoisted out into a separate method.

與真假判斷一樣，相等判斷也被提取到了單獨的方法中。

lox/Interpreter.java，在 isTruthy()方法後新增：

  private boolean isEqual(Object a, Object b) {
    if (a == null && b == null) return true;
    if (a == null) return false;

    return a.equals(b);
  }

This is one of those corners where the details of how we represent Lox objects in terms of Java matter. We need to correctly implement Lox’s notion of equality, which may be different from Java’s.

這是我們使用Java表示Lox物件的細節一角。我們需要正確地實現Lox的相等概念，這可能與Java中不同。

Fortunately, the two are pretty similar. Lox doesn’t do implicit conversions in equality and Java does not either. We do have to handle nil/null specially so that we don’t throw a NullPointerException if we try to call equals() on null. Otherwise, we’re fine. Java’s .equals() method on Boolean, Double, and String have the behavior we want for Lox.

幸運的是，這兩者很相似。Lox不會在等式中做隱式轉換，Java也不會。我們必須對 nil/null 做特殊處理，這樣就不會在對null呼叫equals()方法時丟擲NullPointerException。其它情況下，都是沒問題的。Java中的.equals()方法對Boolean、Double和 String的處理都符合Lox的要求⁷。

And that’s it! That’s all the code we need to correctly interpret a valid Lox expression. But what about an invalid one? In particular, what happens when a subexpression evaluates to an object of the wrong type for the operation being performed?

就這樣了! 這就是我們要正確解釋一個有效的Lox表示式所需要的全部程式碼。但是無效的表示式呢？尤其是，當一個子表示式的計算結果型別與待執行的操作不符時會發生什麼？

7 . 3 Runtime Errors

7.3 執行時錯誤

I was cavalier about jamming casts in whenever a subexpression produces an Object and the operator requires it to be a number or a string. Those casts can fail. Even though the user’s code is erroneous, if we want to make a usable language, we are responsible for handling that error gracefully.

每當子表示式產生一個物件，而運算子要求它是一個數字或字串時，我都會輕率地插入強制型別轉換。這些型別轉換可能會失敗。如果我們想做出一個可用的語言，即使使用者的程式碼是錯誤的，我們也有責任優雅地處理這個錯誤⁸。

It’s time for us to talk about runtime errors. I spilled a lot of ink in the previous chapters talking about error handling, but those were all syntax or static errors. Those are detected and reported before any code is executed. Runtime errors are failures that the language semantics demand we detect and report while the program is running (hence the name).

現在是時候討論執行時錯誤了。在前面的章節中，我花了很多筆墨討論錯誤處理，但這些都是語法或靜態錯誤。這些都是在程式碼執行之前進行檢測和報告的。執行時錯誤是語言語義要求我們在程式執行時檢測和報告的故障（因此得名）。

Right now, if an operand is the wrong type for the operation being performed, the Java cast will fail and the JVM will throw a ClassCastException. That unwinds the whole stack and exits the application, vomiting a Java stack trace onto the user. That’s probably not what we want. The fact that Lox is implemented in Java should be a detail hidden from the user. Instead, we want them to understand that a Lox runtime error occurred, and give them an error message relevant to our language and their program.

現在，如果運算元對於正在執行的操作來說是錯誤的型別，那麼Java轉換將失敗，JVM將丟擲一個ClassCastException。這將跳脫出整個呼叫堆疊並退出應用程式，然後向用戶丟擲Java堆疊跟蹤資訊。這可能不是我們想要的。Lox是用Java實現的這一事實應該是一個對使用者隱藏的細節。相反，我們希望他們理解此時發生的是Lox執行時錯誤，並給他們一個與我們的語言和他們的程式相關的錯誤資訊。

The Java behavior does have one thing going for it, though. It correctly stops executing any code when the error occurs. Let’s say the user enters some expression like:

不過，Java的行為確實有一個優點。當錯誤發生時，它會正確地停止執行程式碼。比方說，使用者輸入了一些表示式，比如：

2 * (3 / -"muffin")

You can’t negate a muffin, so we need to report a runtime error at that inner - expression. That in turn means we can’t evaluate the / expression since it has no meaningful right operand. Likewise for the *. So when a runtime error occurs deep in some expression, we need to escape all the way out.

你無法對"muffin"取負，所以我們需要在內部的-表示式中報告一個執行時錯誤。這又意味著我們無法計算/表示式，因為它的右運算元無意義，對於*表示式也是如此。因此，當某個表示式深處出現執行時錯誤時，我們需要一直跳出到最外層。

We could print a runtime error and then abort the process and exit the application entirely. That has a certain melodramatic flair. Sort of the programming language interpreter equivalent of a mic drop.

我們可以列印一個執行時錯誤，然後中止程序並完全退出應用程式。這有一點戲劇性，有點像程式語言直譯器中的 "mic drop"。

Tempting as that is, we should probably do something a little less cataclysmic. While a runtime error needs to stop evaluating the expression, it shouldn’t kill the interpreter. If a user is running the REPL and has a typo in a line of code, they should still be able to keep the session going and enter more code after that.

儘管這種處理方式很誘人，我們或許應該做一些不那麼災難性的事情。雖然執行時錯誤需要停止對錶達式的計算，但它不應該殺死直譯器。如果使用者正在執行REPL，並且在一行程式碼中出現了錯誤，他們應該仍然能夠保持會話，並在之後繼續輸入更多的程式碼。

7 . 3 . 1 Detecting runtime errors

7.3.1 檢測執行時錯誤

Our tree-walk interpreter evaluates nested expressions using recursive method calls, and we need to unwind out of all of those. Throwing an exception in Java is a fine way to accomplish that. However, instead of using Java’s own cast failure, we’ll define a Lox-specific one so that we can handle it how we want.

我們的樹遍歷型直譯器透過遞迴方法呼叫計算巢狀的表示式，而且我們需要能夠跳脫出所有的呼叫層。在Java中丟擲異常是實現這一點的好方法。但是，我們不使用Java自己的轉換失敗錯誤，而是定義一個Lox專用的錯誤，這樣我們就可以按照我們想要的方式處理它。

Before we do the cast, we check the object’s type ourselves. So, for unary -, we add:

在進行強制轉換之前，我們先自己檢查物件的型別。因此，對於一元運算子-，我們需要新增程式碼：

lox/Interpreter.java，在visitUnaryExpr()方法中新增：

      case MINUS:
        // 新增部分開始
       	checkNumberOperand(expr.operator, right);
       	// 新增部分結束
        return -(double)right;

The code to check the operand is:

檢查運算元的程式碼如下：

lox/Interpreter.java，在 visitUnaryExpr()方法後新增：

  private void checkNumberOperand(Token operator, Object operand) {
    if (operand instanceof Double) return;
    throw new RuntimeError(operator, "Operand must be a number.");
  }

When the check fails, it throws one of these:

當檢查失敗時，程式碼會丟擲一個以下的錯誤：

lox/RuntimeError.java，新建原始碼檔案：

package com.craftinginterpreters.lox;

class RuntimeError extends RuntimeException {
  final Token token;

  RuntimeError(Token token, String message) {
    super(message);
    this.token = token;
  }
}

Unlike the Java cast exception, our class tracks the token that identifies where in the user’s code the runtime error came from. As with static errors, this helps the user know where to fix their code.

與Java轉換異常不同，我們的類會跟蹤語法標記，可以指明使用者程式碼中丟擲執行時錯誤的位置⁹。與靜態錯誤一樣，這有助於使用者知道去哪裡修復程式碼。

We need similar checking for the binary operators. Since I promised you every single line of code needed to implement the interpreters, I’ll run through them all.

我們需要對二元運算子進行類似的檢查。既然我答應了要展示實現直譯器所需的每一行程式碼，那麼我就把它們逐一介紹一遍。

Greater than:

大於：

lox/Interpreter.java，在 visitBinaryExpr()方法中新增：

      case GREATER:  
				// 新增部分開始
        checkNumberOperands(expr.operator, left, right);
        // 新增部分結束
        return (double)left > (double)right;

Greater than or equal to:

大於等於：

lox/Interpreter.java，在 visitBinaryExpr()方法中新增：

      case GREATER_EQUAL:  
				// 新增部分開始
        checkNumberOperands(expr.operator, left, right);
        // 新增部分結束
        return (double)left >= (double)right;

Less than:

小於：

lox/Interpreter.java，在 visitBinaryExpr()方法中新增：

      case LESS:  
				// 新增部分開始
        checkNumberOperands(expr.operator, left, right);
        // 新增部分結束
        return (double)left < (double)right;

Less than or equal to:

小於等於：

lox/Interpreter.java，在 visitBinaryExpr()方法中新增：

      case LESS_EQUAL:  
				// 新增部分開始
        checkNumberOperands(expr.operator, left, right);
        // 新增部分結束
        return (double)left <= (double)right;

Subtraction:

減法：

lox/Interpreter.java，在 visitBinaryExpr()方法中新增：

      case MINUS:  
				// 新增部分開始
        checkNumberOperands(expr.operator, left, right);
        // 新增部分結束
        return (double)left - (double)right;

Division:

除法：

lox/Interpreter.java，在 visitBinaryExpr()方法中新增：

      case SLASH:  
				// 新增部分開始
        checkNumberOperands(expr.operator, left, right);
        // 新增部分結束
        return (double)left / (double)right;

Multiplication:

乘法：

lox/Interpreter.java，在 visitBinaryExpr()方法中新增：

      case STAR:  
				// 新增部分開始
        checkNumberOperands(expr.operator, left, right);
        // 新增部分結束
        return (double)left * (double)right;

All of those rely on this validator, which is virtually the same as the unary one:

所有這些都依賴於下面這個驗證器，它實際上與一元驗證器相同¹⁰：

lox/Interpreter.java，在 checkNumberOperand()方法後新增：

  private void checkNumberOperands(Token operator, Object left, Object right) {
    if (left instanceof Double && right instanceof Double) return;
    
    throw new RuntimeError(operator, "Operands must be numbers.");
  }

The last remaining operator, again the odd one out, is addition. Since + is overloaded for numbers and strings, it already has code to check the types. All we need to do is fail if neither of the two success cases match.

剩下的最後一個運算子，也是最奇怪的一個，就是加法。由於+已經對數字和字串進行過載，其中已經有檢查型別的程式碼。我們需要做的就是在這兩種情況都不匹配時失敗。

lox/Interpreter.java，在 visitBinaryExpr()方法中替換一行：

          return (String)left + (String)right;
        }
        // 替換部分開始
        throw new RuntimeError(expr.operator,
            "Operands must be two numbers or two strings.");
        // 替換部分結束
      case SLASH:

That gets us detecting runtime errors deep in the bowels of the evaluator. The errors are getting thrown. The next step is to write the code that catches them. For that, we need to wire up the Interpreter class into the main Lox class that drives it.

這樣我們就可以在計算器的內部檢測執行時錯誤。錯誤已經被拋出了。下一步就是編寫能捕獲這些錯誤的程式碼。為此，我們需要將Interpreter類連線到驅動它的Lox主類中。

7 . 4 Hooking Up the Interpreter

7.4 連線直譯器

The visit methods are sort of the guts of the Interpreter class, where the real work happens. We need to wrap a skin around them to interface with the rest of the program. The Interpreter’s public API is simply one method.

visit方法是Interpreter類的核心部分，真正的工作是在這裡進行的。我們需要給它們包上一層皮，以便與程式的其他部分對接。直譯器的公共API只是一種方法。

lox/Interpreter.java，在 Interpreter類中新增：

  void interpret(Expr expression) { 
    try {
      Object value = evaluate(expression);
      System.out.println(stringify(value));
    } catch (RuntimeError error) {
      Lox.runtimeError(error);
    }
  }

This takes in a syntax tree for an expression and evaluates it. If that succeeds, evaluate() returns an object for the result value. interpret() converts that to a string and shows it to the user. To convert a Lox value to a string, we rely on:

該方法會接收一個表示式對應的語法樹，並對其進行計算。如果成功了，evaluate()方法會返回一個物件作為結果值。interpret()方法將結果轉為字串並展示給使用者。要將Lox值轉為字串，我們要依賴下面的方法：

lox/Interpreter.java，在 isEqual()方法後新增：

  private String stringify(Object object) {
    if (object == null) return "nil";

    if (object instanceof Double) {
      String text = object.toString();
      if (text.endsWith(".0")) {
        text = text.substring(0, text.length() - 2);
      }
      return text;
    }

    return object.toString();
  }

This is another of those pieces of code like isTruthy() that crosses the membrane between the user’s view of Lox objects and their internal representation in Java.

這是一段像isTruthy()一樣的程式碼，它連線了Lox物件的使用者檢視和它們在Java中的內部表示。

It’s pretty straightforward. Since Lox was designed to be familiar to someone coming from Java, things like Booleans look the same in both languages. The two edge cases are nil, which we represent using Java’s null, and numbers.

這很簡單。由於Lox的設計旨在使Java使用者熟悉，因此Boolean之類的東西在兩種語言中看起來是一樣的。只有兩種邊界情況是nil(我們用Java的null表示)和數字。

Lox uses double-precision numbers even for integer values. In that case, they should print without a decimal point. Since Java has both floating point and integer types, it wants you to know which one you’re using. It tells you by adding an explicit .0 to integer-valued doubles. We don’t care about that, so we hack it off the end.

Lox即使對整數值也使用雙精度數字¹¹。在這種情況下，列印時應該不帶小數點。 由於Java同時具有浮點型和整型，它希望您知道正在使用的是哪一種型別。它透過在整數值的雙數上新增一個明確的.0來告知使用者。我們不關心這個，所以我們把它去掉。

7 . 4 . 1 Reporting runtime errors

7.4.1 報告執行時錯誤

If a runtime error is thrown while evaluating the expression, interpret() catches it. This lets us report the error to the user and then gracefully continue. All of our existing error reporting code lives in the Lox class, so we put this method there too:

如果在計算表示式時出現了執行時錯誤，interpret()方法會將其捕獲。這樣我們可以向用戶報告這個錯誤，然後優雅地繼續執行。我們現有的所有錯誤報告程式碼都在Lox類中，所以我們也把這個方法放在其中：

lox/Lox.java，在 error()方法後新增：

  static void runtimeError(RuntimeError error) {
    System.err.println(error.getMessage() +
        "\n[line " + error.token.line + "]");
    hadRuntimeError = true;
  }

We use the token associated with the RuntimeError to tell the user what line of code was executing when the error occurred. Even better would be to give the user an entire call stack to show how they got to be executing that code. But we don’t have function calls yet, so I guess we don’t have to worry about it.

我們使用與RuntimeError關聯的標記來告訴使用者錯誤發生時正在執行哪一行程式碼。更好的做法是給使用者一個完整的呼叫堆疊，來顯示他們是如何執行該程式碼的。但我們目前還沒有函式呼叫，所以我想我們不必擔心這個問題。

After showing the error, runtimeError() sets this field:

展示錯誤之後，runtimeError()會設定以下欄位：

lox/Lox.java，在 Lox類中新增：

  static boolean hadError = false;
  // 新增部分開始
  static boolean hadRuntimeError = false;
  // 新增部分結束
  public static void main(String[] args) throws IOException {

That field plays a small but important role.

這個欄位擔任著很小但很重要的角色。

lox/Lox.java，在 runFile()方法中新增：

    run(new String(bytes, Charset.defaultCharset()));

    // Indicate an error in the exit code.
    if (hadError) System.exit(65);
    // 新增部分開始
    if (hadRuntimeError) System.exit(70);
    // 新增部分結束
  }

If the user is running a Lox script from a file and a runtime error occurs, we set an exit code when the process quits to let the calling process know. Not everyone cares about shell etiquette, but we do.

如果使用者從檔案中執行Lox指令碼，並且發生了執行時錯誤，我們在程序退出時設定一個退出碼，以便讓呼叫程序知道。不是每個人都在乎shell的規矩，但我們在乎¹²。

7 . 4 . 2 Running the interpreter

7.4.2 執行直譯器

Now that we have an interpreter, the Lox class can start using it.

現在我們有了直譯器，Lox類可以開始使用它了。

lox/Lox.java，在 Lox類中新增：

public class Lox {
  // 新增部分開始
  private static final Interpreter interpreter = new Interpreter();
  // 新增部分結束
  static boolean hadError = false;

We make the field static so that successive calls to run() inside a REPL session reuse the same interpreter. That doesn’t make a difference now, but it will later when the interpreter stores global variables. Those variables should persist throughout the REPL session.

我們把這個欄位設定為靜態的，這樣在一個REPL會話中連續呼叫run()時就會重複使用同一個直譯器。目前這一點沒有什麼區別，但以後當直譯器需要儲存全域性變數時就會有區別。這些全域性變數應該在整個REPL會話中持續存在。

Finally, we remove the line of temporary code from the last chapter for printing the syntax tree and replace it with this:

最後，我們刪除上一章中用於列印語法樹的那行臨時程式碼，並將其替換為：

lox/Lox.java，在 run()方法中替換一行：

    // Stop if there was a syntax error.
    if (hadError) return;
    // 替換部分開始
    interpreter.interpret(expression);
    // 替換部分結束
  }

We have an entire language pipeline now: scanning, parsing, and execution. Congratulations, you now have your very own arithmetic calculator.

我們現在有一個完整的語言管道：掃描、解析和執行。恭喜你，你現在有了你自己的算術計算器。

As you can see, the interpreter is pretty bare bones. But the Interpreter class and the Visitor pattern we’ve set up today form the skeleton that later chapters will stuff full of interesting guts—variables, functions, etc. Right now, the interpreter doesn’t do very much, but it’s alive!

如您所見，這個直譯器是非常簡陋的。但是我們今天建立的直譯器類和訪問者模式構成了一個骨架，後面的章節中將填充入有趣的內容（變數，函式等）。現在，直譯器的功能並不多，但它是活的!

CHALLENGES

習題

1、Allowing comparisons on types other than numbers could be useful. The operators might have a reasonable interpretation for strings. Even comparisons among mixed types, like 3 < "pancake" could be handy to enable things like ordered collections of heterogeneous types. Or it could simply lead to bugs and confusion.

Would you extend Lox to support comparing other types? If so, which pairs of types do you allow and how do you define their ordering? Justify your choices and compare them to other languages.

1、允許對數字之外的型別進行比較可能是個有用的特性。運算子可能對字串有合理的解釋。即使是混合型別之間的比較，如3<"pancake"，也可以方便地支援異構型別的有序集合。否則可能導致錯誤和混亂。

你是否會擴充套件Lox以支援對其他型別的比較？如果是，您允許哪些型別間的比較，以及如何定義它們的順序？證明你的選擇並與其他語言進行比較。

2、Many languages define + such that if either operand is a string, the other is converted to a string and the results are then concatenated. For example, "scone" + 4 would yield scone4. Extend the code in visitBinaryExpr() to support that.

2、許多語言對+的定義是，如果其中一個運算元是字串，另一個運算元就會被轉換成字串，然後將兩個結果拼接起來。例如，"scone "+4的結果應該是scone4。擴充套件visitBinaryExpr()中的程式碼以支援該特性。

3、What happens right now if you divide a number by zero? What do you think should happen? Justify your choice. How do other languages you know handle division by zero, and why do they make the choices they do?

Change the implementation in visitBinaryExpr() to detect and report a runtime error for this case.

3、如果你用一個數除以0會發生什麼？你認為應該發生什麼？證明你的選擇。你知道的其他語言是如何處理除零的，為什麼他們會做出這樣的選擇？

更改visitBinaryExpr()中的實現程式碼，以檢測並報告執行時錯誤。

DESIGN NOTE: STATIC AND DYNAMIC TYPING

設計筆記：靜態型別和動態型別

Some languages, like Java, are statically typed which means type errors are detected and reported at compile time before any code is run. Others, like Lox, are dynamically typed and defer checking for type errors until runtime right before an operation is attempted. We tend to consider this a black-and-white choice, but there is actually a continuum between them.

It turns out even most statically typed languages do some type checks at runtime. The type system checks most type rules statically, but inserts runtime checks in the generated code for other operations.

For example, in Java, the static type system assumes a cast expression will always safely succeed. After you cast some value, you can statically treat it as the destination type and not get any compile errors. But downcasts can fail, obviously. The only reason the static checker can presume that casts always succeed without violating the language’s soundness guarantees, is because the cast is checked at runtime and throws an exception on failure.

A more subtle example is covariant arrays in Java and C#. The static subtyping rules for arrays allow operations that are not sound. Consider:

Object[] stuff = new Integer[1];
stuff[0] = "not an int!";

This code compiles without any errors. The first line upcasts the Integer array and stores it in a variable of type Object array. The second line stores a string in one of its cells. The Object array type statically allows that—strings are Objects—but the actual Integer array that stuff refers to at runtime should never have a string in it! To avoid that catastrophe, when you store a value in an array, the JVM does a runtime check to make sure it’s an allowed type. If not, it throws an ArrayStoreException.

Java could have avoided the need to check this at runtime by disallowing the cast on the first line. It could make arrays invariant such that an array of Integers is not an array of Objects. That’s statically sound, but it prohibits common and safe patterns of code that only read from arrays. Covariance is safe if you never write to the array. Those patterns were particularly important for usability in Java 1.0 before it supported generics.

James Gosling and the other Java designers traded off a little static safety and performance—those array store checks take time—in return for some flexibility.

There are few modern statically typed languages that don’t make that trade-off somewhere. Even Haskell will let you run code with non-exhaustive matches. If you find yourself designing a statically typed language, keep in mind that you can sometimes give users more flexibility without sacrificing too many of the benefits of static safety by deferring some type checks until runtime.

On the other hand, a key reason users choose statically typed languages is because of the confidence the language gives them that certain kinds of errors can never occur when their program is run. Defer too many type checks until runtime, and you erode that confidence.

有些語言，如Java，是靜態型別的，這意味著在任何程式碼執行之前，會在編譯時檢測和報告型別錯誤。其他語言，如Lox，是動態型別的，將型別錯誤的檢查推遲到執行時嘗試執行具體操作之前。我們傾向於認為這是一個非黑即白的選擇，但實際上它們之間是連續統一的。

事實證明，大多數靜態型別的語言也會在執行時進行一些型別檢查。型別系統會靜態地檢查多數型別規則，但在生成的程式碼中插入了執行時檢查以支援其它操作。

例如，在Java中，靜態型別系統會假定強制轉換表示式總是能安全地成功執行。在轉換某個值之後，可以將其靜態地視為目標型別，而不會出現任何編譯錯誤。但向下轉換顯然會失敗。靜態檢查器之所以能夠在不違反語言的合理性保證的情況下假定轉換總是成功的，唯一原因是，強制轉換操作會在執行時進行型別檢查，並在失敗時丟擲異常。

一個更微妙的例子是Java和c#中的協變陣列。陣列的靜態子型別規則允許不健全的操作。考慮以下程式碼：

Object[] stuff = new Integer[1];
stuff[0] = "not an int!";

這段程式碼在編譯時沒有任何錯誤。第一行程式碼將整數陣列向上轉換並儲存到一個物件陣列型別的變數中。第二行程式碼將字串儲存在其中一個單元格里。物件陣列型別靜態地允許該操作——字串也是物件——但是stuff在執行時引用的整數陣列中不應該包含字串！為了避免這種災難，當你在陣列中儲存一個值時，JVM會進行執行時檢查，以確保該值是允許的型別。如果不是，則丟擲ArrayStoreException。

Java可以透過禁止對第一行進行強制轉換來避免在執行時檢查這一點。它可以使陣列保持不變，這樣整型陣列就不是物件陣列。這在靜態型別角度是合理的，但它禁止了只從陣列中讀取資料的常見安全的程式碼模式。如果你從來不向陣列寫入內容，那麼協變是安全的。在支援泛型之前，這些模式對於Java 1.0的可用性尤為重要。

James Gosling和其他Java設計師犧牲了一點靜態安全和效能（這些陣列儲存檢查需要花費時間）來換取一些靈活性。

幾乎所有的現代靜態型別語言都在某些方面做出了權衡。即使Haskell也允許您執行非窮舉性匹配的程式碼。如果您自己正在設計一種靜態型別語言，請記住，有時你可以透過將一些型別檢查推遲到執行時來給使用者更多的靈活性，而不會犧牲靜態安全的太多好處。

另一方面，使用者選擇靜態型別語言的一個關鍵原因是，這種語言讓他們相信：在他們的程式執行時，某些型別的錯誤永遠不會發生。將過多的型別檢查推遲到執行時，就會破壞使用者的這種信心。

1. 在這裡，我基本可以互換地使用 "值 "和 "物件"。稍後在C直譯器中，我們會對它們稍作區分，但這主要是針對實現的兩個不同方面（本地資料和堆分配資料）使用不同的術語。從使用者的角度來看，這些術語是同義的。 ↩

2. 我們需要對值做的另一件事是管理它們的記憶體，Java也能做到這一點。方便的物件表示和非常好的垃圾收集器是我們用Java編寫第一個直譯器的主要原因。 ↩

3. 在下一章，當我們實現變數時，我們將新增識別符號表示式，它也是葉子節點。 ↩

4. 有些解析器不為圓括號單獨定義樹節點。相應地，在解析帶圓括號的表示式時，它們只返回內部表示式的節點。在Lox中，我們確實為圓括號建立了一個節點，因為稍後我們需要用它來正確處理賦值表示式的左值。 ↩

5. 在JavaScript中，字串是真的，但空字串不是。陣列是真的，但空陣列是......也是真的。數字0是假的，但字串 "0 "是真的。
   在 Python 中，空字串是假的，就像在 JS 中一樣，但其他空序列也是假的。
   在PHP中，數字0和字串 "0 "都是假的。大多數其他非空字串是真實的。明白了嗎？ ↩

6. 你是否注意到我們在這裡固定了語言語義的一個細微的點？在二元表示式中，我們按從左到右的順序計算運算元。如果這些運算元有副作用，那這個選擇應該是使用者可見的，所以這不是一個簡單的實現細節。如果我們希望我們的兩個直譯器是一致的（提示：我們是一致的），我們就需要確保 clox 也是這樣做的。 ↩

7. 你希望這個表示式的計算結果是什麼？(0 / 0) == (0 / 0)。根據IEEE 754（它規定了雙精度數的行為），用0除以0會得到特殊的NaN（不是一個數字）值。奇怪的是，NaN不等於它自己。
   在Java中，基本型別double的==操作滿足該規範，但是封裝類Double的equals()方法不滿足。Lox使用了後者，因此不遵循IEEE。這類微妙的不相容問題佔據了語言開發者生活中令人沮喪的一部分。 ↩

8. 我們完全可以不檢測或報告一個型別錯誤。當你在C語言中把一個指標轉換到與實際被指向的資料不匹配的型別上，C語言就是這樣做的。C語言透過允許這樣的操作獲得了靈活性和速度，但它也是出了名的危險。一旦你錯誤地解釋了記憶體中的資料，一切都完了。很少有現代語言接受這樣的不安全操作。相反，大多數語言都是記憶體安全的，並透過靜態和執行時檢查的組合，確保程式永遠不會錯誤地解釋儲存在記憶體中的值。 ↩

9. 我承認 "RuntimeError "這個名字令人困惑，因為Java定義了一個RuntimeException類。關於構建直譯器的一件惱人的事情就是，您使用的名稱經常與實現語言中已經使用的名稱衝突。等我們支援Lox類就好了。 ↩

10. 另一個微妙的語義選擇：在檢查兩個運算元的型別之前，我們先計算這兩個運算元。假設我們有一個函式say()，它會列印其介紹的引數，然後返回。 我們使用這個函式寫出表示式：say("left") - say("right");。我們的直譯器在報告執行時錯誤之前會先列印"left"和"right"。相對地，我們也可以指定在計算右運算元之前先檢查左運算元。 ↩

11. 同樣，我們要處理這種數字的邊界情況，以確保jlox和clox的工作方式相同。像這樣處理語言的一個奇怪的邊界可能會讓你抓狂，但這是工作的一個重要部分。使用者會有意或無意地依賴於這些細節，如果實現不一致，他們的程式在不同的直譯器上執行時將會中斷。 ↩

12. 如果使用者正在執行REPL，則我們不必跟蹤執行時錯誤。在錯誤被報告之後，我們只需要迴圈，讓使用者輸入新的程式碼，然後繼續執行。 ↩

8.表示式和狀態 Statements and State

All my life, my heart has yearned for a thing I cannot name.

​ —— André Breton, Mad Love

終我一生，我們的內心都在渴求一種我無法名狀的東西。

The interpreter we have so far feels less like programming a real language and more like punching buttons on a calculator. “Programming” to me means building up a system out of smaller pieces. We can’t do that yet because we have no way to bind a name to some data or function. We can’t compose software without a way to refer to the pieces.

到目前為止，我們提供直譯器的感覺不太像是在使用一種真正的語言進行程式設計，更像是在計算器上按按鈕。對我來說，"程式設計 "意味著用較小的部分構建出一個系統。我們目前還不支援這樣做，因為我們還無法將一個名稱繫結到某個資料或函式。我們不能在無法引用小片段的情況下編寫軟體。

To support bindings, our interpreter needs internal state. When you define a variable at the beginning of the program and use it at the end, the interpreter has to hold on to the value of that variable in the meantime. So in this chapter, we will give our interpreter a brain that can not just process, but remember.

為了支援繫結，我們的直譯器需要儲存內部狀態。如果你在程式開始處定義了一個變數，並在結束處使用它，那麼直譯器必須在這期間保持該變數的值。所以在這一章中，我們會給直譯器一個大腦，它不僅可以運算，而且可以記憶。

State and statements go hand in hand. Since statements, by definition, don’t evaluate to a value, they need to do something else to be useful. That something is called a side effect. It could mean producing user-visible output or modifying some state in the interpreter that can be detected later. The latter makes them a great fit for defining variables or other named entities.

狀態和語句是相輔相成的。因為根據定義，語句不會計算出一個具體值，而是需要做一些事情來發揮作用。這些事情被稱為副作用(side effect)。它可能意味著產生使用者可見的輸出，或者修改直譯器中的一些狀態，而這些狀態後續可以被檢測到。第二個特性使得語句非常適合於定義變數或其他命名實體。

In this chapter, we’ll do all of that. We’ll define statements that produce output (print) and create state (var). We’ll add expressions to access and assign to variables. Finally, we’ll add blocks and local scope. That’s a lot to stuff into one chapter, but we’ll chew through it all one bite at a time.

在這一章中，我們會實現所有這些。我們會定義可以產生輸出和建立狀態的語句，然後會新增表示式來訪問和賦值給這些變數，最後，我們會引入程式碼塊和區域性作用域。這一章要講的內容太多了，但是我們會一點一點地把它們嚼碎。

8 . 1 Statements

8.1 語句

We start by extending Lox’s grammar with statements. They aren’t very different from expressions. We start with the two simplest kinds:

我們首先擴充套件Lox的語法以支援語句。 語句與表示式並沒有很大的不同，我們從兩種最簡單的型別開始：

1. An expression statement lets you place an expression where a statement is expected. They exist to evaluate expressions that have side effects. You may not notice them, but you use them all the time in C, Java, and other languages. Any time you see a function or method call followed by a ;, you’re looking at an expression statement.

   表示式語句可以讓您將表示式放在需要語句的位置。它們的存在是為了計算有副作用的表示式。您可能沒有注意到它們，但其實你在C、Java和其他語言中一直在使用表示式語句¹。如果你看到一個函式或方法呼叫後面跟著一個;，您看到的其實就是一個表示式語句。

2. A print statement evaluates an expression and displays the result to the user. I admit it’s weird to bake printing right into the language instead of making it a library function. Doing so is a concession to the fact that we’re building this interpreter one chapter at a time and want to be able to play with it before it’s all done. To make print a library function, we’d have to wait until we had all of the machinery for defining and calling functions before we could witness any side effects.

   print語句會計算一個表示式，並將結果展示給使用者。我承認把print直接放進語言中，而不是把它變成一個庫函式，這很奇怪²。這樣做是基於本書的編排策略的讓步，即我們會以章節為單位逐步構建這個直譯器，並希望能夠在完成直譯器的所有功能之前能夠使用它。如果讓print成為一個標準庫函式，我們必須等到擁有了定義和呼叫函式的所有機制之後，才能看到它發揮作用。

New syntax means new grammar rules. In this chapter, we finally gain the ability to parse an entire Lox script. Since Lox is an imperative, dynamically typed language, the “top level” of a script is simply a list of statements. The new rules are:

新的詞法意味著新的語法規則。在本章中，我們終於獲得瞭解析整個Lox指令碼的能力。由於Lox是一種命令式的、動態型別的語言，所以指令碼的“頂層”也只是一組語句。新的規則如下：

program        → statement* EOF ;

statement      → exprStmt
               | printStmt ;

exprStmt       → expression ";" ;
printStmt      → "print" expression ";" ;

The first rule is now program, which is the starting point for the grammar and represents a complete Lox script or REPL entry. A program is a list of statements followed by the special “end of file” token. The mandatory end token ensures the parser consumes the entire input and doesn’t silently ignore erroneous unconsumed tokens at the end of a script.

現在第一條規則是program，這也是語法的起點，代表一個完整的Lox指令碼或REPL輸入項。程式是一個語句列表，後面跟著特殊的“檔案結束”(EOF)標記。強制性的結束標記可以確保解析器能夠消費所有輸入內容，而不會默默地忽略指令碼結尾處錯誤的、未消耗的標記。

Right now, statement only has two cases for the two kinds of statements we’ve described. We’ll fill in more later in this chapter and in the following ones. The next step is turning this grammar into something we can store in memory—syntax trees.

目前，statement只有兩種情況，分別對應於我們描述的兩類語句。我們將在本章後面和接下來的章節中補充更多內容。接下來就是將這個語法轉化為我們可以儲存在記憶體中的東西——語法樹。。

8 . 1 . 1 Statement syntax trees

8.1.1 Statement語法樹

There is no place in the grammar where both an expression and a statement are allowed. The operands of, say, + are always expressions, never statements. The body of a while loop is always a statement.

語法中沒有地方既允許使用表示式，也允許使用語句。 運算子（如+）的運算元總是表示式，而不是語句。while迴圈的主體總是一個語句。

Since the two syntaxes are disjoint, we don’t need a single base class that they all inherit from. Splitting expressions and statements into separate class hierarchies enables the Java compiler to help us find dumb mistakes like passing a statement to a Java method that expects an expression.

因為這兩種語法是不相干的，所以我們不需要提供一個它們都繼承的基類。將表示式和語句拆分為單獨的類結構，可使Java編譯器幫助我們發現一些愚蠢的錯誤，例如將語句傳遞給需要表示式的Java方法。

That means a new base class for statements. As our elders did before us, we will use the cryptic name “Stmt”. With great foresight, I have designed our little AST metaprogramming script in anticipation of this. That’s why we passed in “Expr” as a parameter to defineAst(). Now we add another call to define Stmt and its subclasses.

這意味著要為語句建立一個新的基類。正如我們的前輩那樣，我們將使用“Stmt”這個隱秘的名字。我很有遠見，在設計我們的AST超程式設計指令碼時就已經預見到了這一點。這就是為什麼我們把“Expr”作為引數傳給了defineAst()。現在我們新增另一個方法呼叫來定義Stmt和它的子類。

tool/GenerateAst.java，在 main()方法中新增：

      "Unary    : Token operator, Expr right"
    ));
    // 新增部分開始
    defineAst(outputDir, "Stmt", Arrays.asList(
      "Expression : Expr expression",
      "Print      : Expr expression"
    ));
    // 新增部分結束
  }

新節點對應的生成程式碼可以參考附錄： Appendix II: Expression statement, Print statement.

Run the AST generator script and behold the resulting “Stmt.java” file with the syntax tree classes we need for expression and print statements. Don’t forget to add the file to your IDE project or makefile or whatever.

執行AST生成器指令碼，檢視生成的Stmt.java檔案，其中包含表示式和print語句所需的語法樹類。不要忘記將該檔案新增到IDE專案或makefile或其他檔案中。

8 . 1 . 2 Parsing statements

8.1.2 解析語句

The parser’s parse() method that parses and returns a single expression was a temporary hack to get the last chapter up and running. Now that our grammar has the correct starting rule, program, we can turn parse() into the real deal.

解析器的parse()方法會解析並返回一個表示式，這是一個臨時方案，是為了讓上一章的程式碼能啟動並執行起來。現在，我們的語法已經有了正確的起始規則，即program，我們可以正式編寫parse()方法了。

lox/Parser.java， parse()方法，替換7行：

  List<Stmt> parse() {
    List<Stmt> statements = new ArrayList<>();
    while (!isAtEnd()) {
      statements.add(statement());
    }

    return statements; 
  }

This parses a series of statements, as many as it can find until it hits the end of the input. This is a pretty direct translation of the program rule into recursive descent style. We must also chant a minor prayer to the Java verbosity gods since we are using ArrayList now.

該方法會盡可能多地解析一系列語句，直到命中輸入內容的結尾為止。這是一種非常直接的將program規則轉換為遞迴下降風格的方式。由於我們現在使用ArrayList，所以我們還必須向Java的冗長之神做一個小小的祈禱。

lox/Parser.java，新增程式碼：

package com.craftinginterpreters.lox;
// 新增部分開始
import java.util.ArrayList;
// 新增部分結束
import java.util.List;

A program is a list of statements, and we parse one of those statements using this method:

一個程式就是一系列的語句，而我們可以透過下面的方法解析每一條語句：

lox/Parser.java，在 expression()方法後新增：

  private Stmt statement() {
    if (match(PRINT)) return printStatement();

    return expressionStatement();
  }

A little bare bones, but we’ll fill it in with more statement types later. We determine which specific statement rule is matched by looking at the current token. A print token means it’s obviously a print statement.

這是一個簡單的框架，但是稍後我們將會填充更多的語句型別。我們透過檢視當前標記來確定匹配哪條語句規則。print標記意味著它顯然是一個print語句。

If the next token doesn’t look like any known kind of statement, we assume it must be an expression statement. That’s the typical final fallthrough case when parsing a statement, since it’s hard to proactively recognize an expression from its first token.

如果下一個標記看起來不像任何已知型別的語句，我們就認為它一定是一個表示式語句。這是解析語句時典型的最終失敗分支，因為我們很難透過第一個標記主動識別出一個表示式。

Each statement kind gets its own method. First print:

每種語句型別都有自己的方法。首先是print：

lox/Parser.java，在 statement()方法後新增：

  private Stmt printStatement() {
    Expr value = expression();
    consume(SEMICOLON, "Expect ';' after value.");
    return new Stmt.Print(value);
  }

Since we already matched and consumed the print token itself, we don’t need to do that here. We parse the subsequent expression, consume the terminating semicolon, and emit the syntax tree.

因為我們已經匹配並消費了print標記本身，所以這裡不需要重複消費。我們先解析隨後的表示式，消費表示語句終止的分號，並生成語法樹。

If we didn’t match a print statement, we must have one of these:

如果我們沒有匹配到print語句，那一定是一條下面的語句：

lox/Parser.java，在 printStatement()方法後新增：

  private Stmt expressionStatement() {
    Expr expr = expression();
    consume(SEMICOLON, "Expect ';' after expression.");
    return new Stmt.Expression(expr);
  }

Similar to the previous method, we parse an expression followed by a semicolon. We wrap that Expr in a Stmt of the right type and return it.

與前面的方法類似，我們解析一個後面帶分號的表示式。我們將Expr封裝在一個正確型別的Stmt中，並返回它。

8 . 1 . 3 Executing statements

8.1.3 執行語句

We’re running through the previous couple of chapters in microcosm, working our way through the front end. Our parser can now produce statement syntax trees, so the next and final step is to interpret them. As in expressions, we use the Visitor pattern, but we have a new visitor interface, Stmt.Visitor, to implement since statements have their own base class.

我們在前面幾章一步一步地慢慢完成了直譯器的前端工作。我們的解析器現在可以產生語句語法樹，所以下一步，也是最後一步，就是對其進行解釋。和表示式一樣，我們使用的是Visitor模式，但是我們需要實現一個新的訪問者介面Stmt.Visitor，因為語句有自己的基類。

We add that to the list of interfaces Interpreter implements.

我們將其新增到Interpreter實現的介面列表中。

lox/Interpreter.java，替換1行³：

// 替換部分開始
class Interpreter implements Expr.Visitor<Object>,
                             Stmt.Visitor<Void> {
// 替換部分結束
  void interpret(Expr expression) { 

Unlike expressions, statements produce no values, so the return type of the visit methods is Void, not Object. We have two statement types, and we need a visit method for each. The easiest is expression statements.

與表示式不同，語句不會產生值，因此visit方法的返回型別是Void，而不是Object。我們有兩種語句型別，每種型別都需要一個visit方法。最簡單的是表示式語句：

lox/Interpreter.java，在 evaluate()方法後新增：

  @Override
  public Void visitExpressionStmt(Stmt.Expression stmt) {
    evaluate(stmt.expression);
    return null;
  }

We evaluate the inner expression using our existing evaluate() method and discard the value. Then we return null. Java requires that to satisfy the special capitalized Void return type. Weird, but what can you do?

我們使用現有的evaluate()方法計算內部表示式，並丟棄其結果值。然後我們返回null，因為Java要求為特殊的大寫Void返回型別返回該值。很奇怪，但你能有什麼辦法呢？

The print statement’s visit method isn’t much different.

print語句的visit方法沒有太大的不同。

lox/Interpreter.java，在 visitExpressionStmt()方法後新增：

  @Override
  public Void visitPrintStmt(Stmt.Print stmt) {
    Object value = evaluate(stmt.expression);
    System.out.println(stringify(value));
    return null;
  }

Before discarding the expression’s value, we convert it to a string using the stringify() method we introduced in the last chapter and then dump it to stdout.

在丟棄表示式的值之前，我們使用上一章引入的stringify()方法將其轉換為字串，然後將其輸出到stdout。

Our interpreter is able to visit statements now, but we have some work to do to feed them to it. First, modify the old interpret() method in the Interpreter class to accept a list of statements—in other words, a program.

我們的直譯器現在可以處理語句了，但是我們還需要做一些工作將語句輸入到直譯器中。首先，修改Interpreter類中原有的interpret() 方法，讓其能夠接受一組語句——即一段程式。

lox/Interpreter.java，修改 interpret()方法，替換8行：

  void interpret(List<Stmt> statements) {
    try {
      for (Stmt statement : statements) {
        execute(statement);
      }
    } catch (RuntimeError error) {
      Lox.runtimeError(error);
    }
  }

This replaces the old code which took a single expression. The new code relies on this tiny helper method:

這段程式碼替換了原先處理單個表示式的舊程式碼。新程式碼依賴於下面的小輔助方法。

lox/Interpreter.java，在 evaluate()方法後新增：

  private void execute(Stmt stmt) {
    stmt.accept(this);
  }

That’s the statement analogue to the evaluate() method we have for expressions. Since we’re working with lists now, we need to let Java know.

這類似於處理表示式的evaluate()方法，這是這裡處理語句。因為我們要使用列表，所以我們需要在Java中引入一下。

lox/Interpreter.java

package com.craftinginterpreters.lox;
// 新增部分開始
import java.util.List;
// 新增部分結束
class Interpreter implements Expr.Visitor<Object>,

The main Lox class is still trying to parse a single expression and pass it to the interpreter. We fix the parsing line like so:

Lox主類中仍然是隻解析單個表示式並將其傳給直譯器。我們將其修正如下：

lox/Lox.java，在 run()方法中替換一行：

    Parser parser = new Parser(tokens);
    // 替換部分開始
    List<Stmt> statements = parser.parse();
    // 替換部分結束
    // Stop if there was a syntax error.

And then replace the call to the interpreter with this:

然後將對直譯器的呼叫替換如下：

lox/Lox.java，在 run()方法中替換一行：

    if (hadError) return;
    // 替換部分開始
    interpreter.interpret(statements);
    // 替換部分結束
  }

Basically just plumbing the new syntax through. OK, fire up the interpreter and give it a try. At this point, it’s worth sketching out a little Lox program in a text file to run as a script. Something like:

基本就是對新語法進行遍歷。 OK，啟動直譯器並測試一下。 現在有必要在文字檔案中草擬一個小的Lox程式來作為指令碼執行。 就像是：

print "one";
print true;
print 2 + 1;

It almost looks like a real program! Note that the REPL, too, now requires you to enter a full statement instead of a simple expression. Don’t forget your semicolons.

它看起來就像一個真實的程式！ 請注意，REPL現在也要求你輸入完整的語句，而不是簡單的表示式。 所以不要忘記後面的分號。

8 . 2 Global Variables

8.2 全域性變數

Now that we have statements, we can start working on state. Before we get into all of the complexity of lexical scoping, we’ll start off with the easiest kind of variables—globals. We need two new constructs.

現在我們已經有了語句，可以開始處理狀態了。在深入探討語法作用域的複雜性之前，我們先從最簡單的變數（全域性變數）開始⁴。我們需要兩個新的結構。

1. A variable declaration statement brings a new variable into the world.

   變數宣告語句用於建立一個新變數。

   var beverage = "espresso";
   

   This creates a new binding that associates a name (here “beverage”) with a value (here, the string "espresso").

   該語句將建立一個新的繫結，將一個名稱（這裡是 beverage）和一個值（這裡是字串 "espresso"）關聯起來。

2. Once that’s done, a variable expression accesses that binding. When the identifier “beverage” is used as an expression, it looks up the value bound to that name and returns it.

   一旦宣告完成，變量表達式就可以訪問該繫結。當識別符號“beverage”被用作一個表示式時，程式會查詢與該名稱繫結的值並返回。

   print beverage; // "espresso".
   

Later, we’ll add assignment and block scope, but that’s enough to get moving.

稍後，我們會新增賦值和塊作用域，但是這些已經足夠繼續後面的學習了。

8 . 2 . 1 Variable syntax

8.2.1 變數語法

As before, we’ll work through the implementation from front to back, starting with the syntax. Variable declarations are statements, but they are different from other statements, and we’re going to split the statement grammar in two to handle them. That’s because the grammar restricts where some kinds of statements are allowed.

與前面一樣，我們將從語法開始，從前到後依次完成實現。變數宣告是一種語句，但它們不同於其他語句，我們把statement語法一分為二來處理該情況。這是因為語法要限制某個位置上哪些型別的語句是被允許的。

The clauses in control flow statements—think the then and else branches of an if statement or the body of a while—are each a single statement. But that statement is not allowed to be one that declares a name. This is OK:

控制流語句中的子句——比如，if或while語句體中的then和else分支——都是一個語句。但是這個語句不應該是一個宣告名稱的語句。下面的程式碼是OK的：

if (monday) print "Ugh, already?";

But this is not:

但是下面的程式碼不行：

if (monday) var beverage = "espresso";

We could allow the latter, but it’s confusing. What is the scope of that beverage variable? Does it persist after the if statement? If so, what is its value on days other than Monday? Does the variable exist at all on those days?

我們也可以允許後者，但是會令人困惑。 beverage變數的作用域是什麼？if語句結束之後它是否還繼續存在？如果存在的話，在其它條件下它的值是什麼？這個變數是否在其它情形下也一直存在？

Code like this is weird, so C, Java, and friends all disallow it. It’s as if there are two levels of “precedence” for statements. Some places where a statement is allowed—like inside a block or at the top level—allow any kind of statement, including declarations. Others allow only the “higher” precedence statements that don’t declare names.

這樣的程式碼有點奇怪，所以C、Java及類似語言中都不允許這種寫法。語句就好像有兩個“優先順序”。有些允許語句的地方——比如在程式碼塊內或程式頂層⁵——可以允許任何型別的語句，包括變數宣告。而其他地方只允許那些不宣告名稱的、優先順序更高的語句。

To accommodate the distinction, we add another rule for kinds of statements that declare names.

為了適應這種區別，我們為宣告名稱的語句型別添加了另一條規則：

program        → declaration* EOF ;

declaration    → varDecl
               | statement ;

statement      → exprStmt
               | printStmt ;

Declaration statements go under the new declaration rule. Right now, it’s only variables, but later it will include functions and classes. Any place where a declaration is allowed also allows non-declaring statements, so the declaration rule falls through to statement. Obviously, you can declare stuff at the top level of a script, so program routes to the new rule.

宣告語句屬於新的 declaration規則。目前，這裡只有變數，但是後面還會包含函式和類。任何允許宣告的地方都允許一個非宣告式的語句，所以 declaration 規則會下降到statement。顯然，你可以在指令碼的頂層宣告一些內容，所以program規則需要路由到新規則。

The rule for declaring a variable looks like:

宣告一個變數的規則如下：

varDecl        → "var" IDENTIFIER ( "=" expression )? ";" ;

Like most statements, it starts with a leading keyword. In this case, var. Then an identifier token for the name of the variable being declared, followed by an optional initializer expression. Finally, we put a bow on it with the semicolon.

像大多數語句一樣，它以一個前置關鍵字開頭，這裡是var。然後是一個識別符號標記，作為宣告變數的名稱，後面是一個可選的初始化式表示式。最後，以一個分號作為結尾。

To access a variable, we define a new kind of primary expression.

為了訪問變數，我們還需要定義一個新型別的基本表示式：

primary        → "true" | "false" | "nil"
               | NUMBER | STRING
               | "(" expression ")"
               | IDENTIFIER ;

That IDENTIFIER clause matches a single identifier token, which is understood to be the name of the variable being accessed.

IDENTIFIER 子語句會匹配單個識別符號標記，該標記會被理解為正在訪問的變數的名稱。

These new grammar rules get their corresponding syntax trees. Over in the AST generator, we add a new statement tree for a variable declaration.

這些新的語法規則需要其相應的語法樹。在AST生成器中，我們為變數宣告新增一個新的語句樹。

tool/GenerateAst.java，在 main()方法中新增一行，前一行需要加,：

      "Expression : Expr expression",
      "Print      : Expr expression",
      // 新增部分開始
      "Var        : Token name, Expr initializer"
      // 新增部分結束
    ));

It stores the name token so we know what it’s declaring, along with the initializer expression. (If there isn’t an initializer, that field is null.)

這裡儲存了名稱標記，以便我們知道該語句宣告瞭什麼，此外還有初始化表示式（如果沒有，欄位就是null）。

Then we add an expression node for accessing a variable.

然後我們新增一個表示式節點用於訪問變數。

tool/GenerateAst.java，在 main()方法中新增一行，前一行需要加,：

      "Literal  : Object value",
      "Unary    : Token operator, Expr right",
      // 新增部分開始
      "Variable : Token name"
      // 新增部分結束
    ));

It’s simply a wrapper around the token for the variable name. That’s it. As always, don’t forget to run the AST generator script so that you get updated “Expr.java” and “Stmt.java” files.

這只是對變數名稱標記的簡單包裝，就是這樣。像往常一樣，別忘了執行AST生成器指令碼，這樣你就能得到更新的 "Expr.java "和 "Stmt.java "檔案。

8 . 2 . 2 Parsing variables

8.2.2 解析變數

Before we parse variable statements, we need to shift around some code to make room for the new declaration rule in the grammar. The top level of a program is now a list of declarations, so the entrypoint method to the parser changes.

在解析變數語句之前，我們需要修改一些程式碼，為語法中的新規則declaration騰出一些空間。現在，程式的最頂層是宣告語句的列表，所以解析器方法的入口需要更改：

lox/Parser.java，在 parse()方法中替換1行：

    List<Stmt> parse() {
    List<Stmt> statements = new ArrayList<>();
    while (!isAtEnd()) {  
      // 替換部分開始
      statements.add(declaration());
      // 替換部分結束
    }

    return statements; 
  }

That calls this new method:

這裡會呼叫下面的新方法：

lox/Parser.java，在 expression()方法後新增：

  private Stmt declaration() {
    try {
      if (match(VAR)) return varDeclaration();

      return statement();
    } catch (ParseError error) {
      synchronize();
      return null;
    }
  }

Hey, do you remember way back in that earlier chapter when we put the infrastructure in place to do error recovery? We are finally ready to hook that up.

你還記得前面的章節中，我們建立了一個進行錯誤恢復的框架嗎？現在我們終於可以用起來了。

This declaration() method is the method we call repeatedly when parsing a series of statements in a block or a script, so it’s the right place to synchronize when the parser goes into panic mode. The whole body of this method is wrapped in a try block to catch the exception thrown when the parser begins error recovery. This gets it back to trying to parse the beginning of the next statement or declaration.

當我們解析塊或指令碼中的 一系列語句時， declaration() 方法會被重複呼叫。因此當解析器進入恐慌模式時，它就是進行同步的正確位置。該方法的整個主體都封裝在一個try塊中，以捕獲解析器開始錯誤恢復時拋出的異常。這樣可以讓解析器跳轉到解析下一個語句或宣告的開頭。

The real parsing happens inside the try block. First, it looks to see if we’re at a variable declaration by looking for the leading var keyword. If not, it falls through to the existing statement() method that parses print and expression statements.

真正的解析工作發生在try塊中。首先，它透過查詢前面的var關鍵字判斷是否是變數宣告語句。如果不是的話，就會進入已有的statement()方法中，解析print和語句表示式。

Remember how statement() tries to parse an expression statement if no other statement matches? And expression() reports a syntax error if it can’t parse an expression at the current token? That chain of calls ensures we report an error if a valid declaration or statement isn’t parsed.

還記得 statement() 會在沒有其它語句匹配時會嘗試解析一個表示式語句嗎？而expression()如果無法在當前語法標記處解析表示式，則會丟擲一個語法錯誤？這一系列呼叫鏈可以保證在解析無效的宣告或語句時會報告錯誤。

When the parser matches a var token, it branches to:

當解析器匹配到一個var標記時，它會跳轉到：

lox/Parser.java，在 printStatement()方法後新增：

  private Stmt varDeclaration() {
    Token name = consume(IDENTIFIER, "Expect variable name.");

    Expr initializer = null;
    if (match(EQUAL)) {
      initializer = expression();
    }

    consume(SEMICOLON, "Expect ';' after variable declaration.");
    return new Stmt.Var(name, initializer);
  }

As always, the recursive descent code follows the grammar rule. The parser has already matched the var token, so next it requires and consumes an identifier token for the variable name.

與之前一樣，遞迴下降程式碼會遵循語法規則。解析器已經匹配了var標記，所以接下來要消費一個識別符號標記作為變數的名稱。

Then, if it sees an = token, it knows there is an initializer expression and parses it. Otherwise, it leaves the initializer null. Finally, it consumes the required semicolon at the end of the statement. All this gets wrapped in a Stmt.Var syntax tree node and we’re groovy.

然後，如果找到=標記，解析器就知道後面有一個初始化表示式，並對其進行解析。否則，它會將初始器保持為null。最後，會消費語句末尾所需的分號。然後將所有這些都封裝到一個Stmt.Var語法樹節點中。

Parsing a variable expression is even easier. In primary(), we look for an identifier token.

解析變量表達式甚至更簡單。在primary()中，我們需要查詢一個識別符號標記。

lox/Parser.java，在 primary()方法中新增：

      return new Expr.Literal(previous().literal);
    }
    // 新增部分開始
    if (match(IDENTIFIER)) {
      return new Expr.Variable(previous());
    }
    // 新增部分結束
    if (match(LEFT_PAREN)) {

That gives us a working front end for declaring and using variables. All that’s left is to feed it into the interpreter. Before we get to that, we need to talk about where variables live in memory.

這為我們提供了宣告和使用變數的可用前端，剩下的就是將其接入直譯器中。在此之前，我們需要討論變數在記憶體中的位置。

8 . 3 Environments

8.3 環境

The bindings that associate variables to values need to be stored somewhere. Ever since the Lisp folks invented parentheses, this data structure has been called an environment.

變數與值之間的繫結關係需要儲存在某個地方。自從Lisp發明圓括號以來，這種資料結構就被稱為環境。

You can think of it like a map where the keys are variable names and the values are the variable’s, uh, values. In fact, that’s how we’ll implement it in Java. We could stuff that map and the code to manage it right into Interpreter, but since it forms a nicely delineated concept, we’ll pull it out into its own class.

你可以把它想象成一個對映，其中鍵是變數名稱，值就是變數的值⁶。實際上，這也就是我們在Java中採用的實現方式。我們可以直接在直譯器中加入該對映及其管理程式碼，但是因為它形成了一個很好的概念，我們可以將其提取到單獨的類中。

Start a new file and add:

開啟新檔案，新增以下程式碼：

lox/Environment.java，建立新檔案

package com.craftinginterpreters.lox;

import java.util.HashMap;
import java.util.Map;

class Environment {
  private final Map<String, Object> values = new HashMap<>();
}

There’s a Java Map in there to store the bindings. It uses bare strings for the keys, not tokens. A token represents a unit of code at a specific place in the source text, but when it comes to looking up variables, all identifier tokens with the same name should refer to the same variable (ignoring scope for now). Using the raw string ensures all of those tokens refer to the same map key.

其中使用一個Java Map來儲存繫結關係。這裡使用原生字串作為鍵，而不是使用標記。一個標記表示源文字中特定位置的一個程式碼單元，但是在查詢變數時，具有相同名稱的識別符號標記都應該指向相同的變數（暫時忽略作用域）。使用原生字串可以保證所有這些標記都會指向相同的對映鍵。

There are two operations we need to support. First, a variable definition binds a new name to a value.

我們需要支援兩個操作。首先，是變數定義操作，可以將一個新的名稱與一個值進行繫結。

lox/Environment.java，在 Environment類中新增：

  void define(String name, Object value) {
    values.put(name, value);
  }

Not exactly brain surgery, but we have made one interesting semantic choice. When we add the key to the map, we don’t check to see if it’s already present. That means that this program works:

不算困難，但是我們這裡也做出了一個有趣的語義抉擇。當我們向對映中新增鍵時，沒有檢查該鍵是否已存在。這意味著下面的程式碼是有效的：

var a = "before";
print a; // "before".
var a = "after";
print a; // "after".

A variable statement doesn’t just define a new variable, it can also be used to redefine an existing variable. We could choose to make this an error instead. The user may not intend to redefine an existing variable. (If they did mean to, they probably would have used assignment, not var.) Making redefinition an error would help them find that bug.

變數語句不僅可以定義一個新變數，也可以用於重新定義一個已有的變數。我們可以選擇將其作為一個錯誤來處理。使用者可能不打算重新定義已有的變數（如果他們想這樣做，可能會使用賦值，而不是var），將重定義作為錯誤可以幫助使用者發現這個問題。

However, doing so interacts poorly with the REPL. In the middle of a REPL session, it’s nice to not have to mentally track which variables you’ve already defined. We could allow redefinition in the REPL but not in scripts, but then users would have to learn two sets of rules, and code copied and pasted from one form to the other might not work.

然而，這樣做與REPL的互動很差。在與REPL的互動中，最好是讓使用者不必在腦子記錄已經定義了哪些變數。我們可以在REPL中允許重定義，在指令碼中不允許。但是這樣一來，使用者就不得不學習兩套規則，而且一種形式的程式碼複製貼上到另一種形式後可能無法執行⁷。

So, to keep the two modes consistent, we’ll allow it—at least for global variables. Once a variable exists, we need a way to look it up.

所以，為了保證兩種模式的統一，我們選擇允許重定義——至少對於全域性變數如此。一旦一個變數存在，我們就需要可以查詢該變數的方法。

lox/Environment.java，在 Environment類中新增：

class Environment {
  private final Map<String, Object> values = new HashMap<>();
  // 新增部分開始
  Object get(Token name) {
    if (values.containsKey(name.lexeme)) {
      return values.get(name.lexeme);
    }

    throw new RuntimeError(name,
        "Undefined variable '" + name.lexeme + "'.");
  }
  // 新增部分結束
  void define(String name, Object value) {

This is a little more semantically interesting. If the variable is found, it simply returns the value bound to it. But what if it’s not? Again, we have a choice:

這在語義上更有趣一些。如果找到了這個變數，只需要返回與之繫結的值。但如果沒有找到呢？我們又需要做一個選擇：

• Make it a syntax error.

  丟擲語法錯誤

• Make it a runtime error.

  丟擲執行時錯誤

• Allow it and return some default value like nil.

  允許該操作並返回預設值（如nil）

Lox is pretty lax, but the last option is a little too permissive to me. Making it a syntax error—a compile-time error—seems like a smart choice. Using an undefined variable is a bug, and the sooner you detect the mistake, the better.

Lox是很寬鬆的，但最後一個選項對我來說有點過於寬鬆了。把它作為語法錯誤（一個編譯時的錯誤）似乎是一個明智的選擇。使用未定義的變數確實是一個錯誤，使用者越早發現這個錯誤就越好。

The problem is that using a variable isn’t the same as referring to it. You can refer to a variable in a chunk of code without immediately evaluating it if that chunk of code is wrapped inside a function. If we make it a static error to mention a variable before it’s been declared, it becomes much harder to define recursive functions.

問題在於，使用一個變數並不等同於引用它。如果程式碼塊封裝在函式中，則可以在程式碼塊中引用變數，而不必立即對其求值。如果我們把引用未宣告的變數當作一個靜態錯誤，那麼定義遞迴函式就變得更加困難了。

We could accommodate single recursion—a function that calls itself—by declaring the function’s own name before we examine its body. But that doesn’t help with mutually recursive procedures that call each other. Consider:

透過在檢查函式體之前先宣告函式名稱，我們可以支援單一遞迴——呼叫自身的函式。但是，這無法處理互相呼叫的遞迴程式⁸。考慮以下程式碼：

fun isOdd(n) {
  if (n == 0) return false;
  return isEven(n - 1);
}

fun isEven(n) {
  if (n == 0) return true;
  return isOdd(n - 1);
}

The isEven() function isn’t defined by the time we are looking at the body of isOdd() where it’s called. If we swap the order of the two functions, then isOdd() isn’t defined when we’re looking at isEven()’s body.

當我們檢視isOdd()方法時， isEven() 方法被呼叫的時候還沒有被宣告。如果我們交換著兩個函式的順序，那麼在檢視isEven()方法體時會發現isOdd()方法未被定義⁹。

Since making it a static error makes recursive declarations too difficult, we’ll defer the error to runtime. It’s OK to refer to a variable before it’s defined as long as you don’t evaluate the reference. That lets the program for even and odd numbers work, but you’d get a runtime error in:

因為將其當作靜態錯誤會使遞迴宣告過於困難，因此我們把這個錯誤推遲到執行時。在一個變數被定義之前引用它是可以的，只要你不對引用進行求值。這樣可以讓前面的奇偶數程式碼正常工作。但是執行以下程式碼時，你會得到一個執行時錯誤：

print a;
var a = "too late!";

As with type errors in the expression evaluation code, we report a runtime error by throwing an exception. The exception contains the variable’s token so we can tell the user where in their code they messed up.

與表示式計算程式碼中的型別錯誤一樣，我們透過丟擲一個異常來報告執行時錯誤。異常中包含變數的標記，以便我們告訴使用者程式碼的什麼位置出現了錯誤。

8 . 3 . 1 Interpreting global variables

8.3.1 解釋全域性變數

The Interpreter class gets an instance of the new Environment class.

Interpreter類會獲取Environment類的一個例項。

lox/Interpreter.java，在 Interpreter類中新增：

class Interpreter implements Expr.Visitor<Object>,
                             Stmt.Visitor<Void> {  
  // 新增部分開始                           
  private Environment environment = new Environment();
  // 新增部分結束                             
  void interpret(List<Stmt> statements) {

We store it as a field directly in Interpreter so that the variables stay in memory as long as the interpreter is still running.

我們直接將它作為一個欄位儲存在直譯器中，這樣，只要直譯器仍在執行，變數就會留在記憶體中。

We have two new syntax trees, so that’s two new visit methods. The first is for declaration statements.

我們有兩個新的語法樹，所以這就是兩個新的訪問方法。第一個是關於宣告語句的。

lox/Interpreter.java，在 visitPrintStmt()方法後新增：

  @Override
  public Void visitVarStmt(Stmt.Var stmt) {
    Object value = null;
    if (stmt.initializer != null) {
      value = evaluate(stmt.initializer);
    }

    environment.define(stmt.name.lexeme, value);
    return null;
  }

If the variable has an initializer, we evaluate it. If not, we have another choice to make. We could have made this a syntax error in the parser by requiring an initializer. Most languages don’t, though, so it feels a little harsh to do so in Lox.

如果該變數有初始化式，我們就對其求值。如果沒有，我們就需要做一個選擇。我們可以透過在解析器中要求初始化式令其成為一個語法錯誤。但是，大多數語言都不會這麼做，所以在Lox中這樣做感覺有點苛刻。

We could make it a runtime error. We’d let you define an uninitialized variable, but if you accessed it before assigning to it, a runtime error would occur. It’s not a bad idea, but most dynamically typed languages don’t do that. Instead, we’ll keep it simple and say that Lox sets a variable to nil if it isn’t explicitly initialized.

我們可以使其成為執行時錯誤。我們允許您定義一個未初始化的變數，但如果您在對其賦值之前訪問它，就會發生執行時錯誤。這不是一個壞主意，但是大多數動態型別的語言都不會這樣做。相反，我們使用最簡單的方式。或者說，如果變數沒有被顯式初始化，Lox會將變數設定為nil。

var a;
print a; // "nil".

Thus, if there isn’t an initializer, we set the value to null, which is the Java representation of Lox’s nil value. Then we tell the environment to bind the variable to that value.

因此，如果沒有初始化式，我們將值設為null，這也是Lox中的nil值的Java表示形式。然後，我們告訴環境上下文將變數與該值進行繫結。

Next, we evaluate a variable expression.

接下來，我們要對變量表達式求值。

lox/Interpreter.java，在 visitUnaryExpr()方法後新增：

  @Override
  public Object visitVariableExpr(Expr.Variable expr) {
    return environment.get(expr.name);
  }

This simply forwards to the environment which does the heavy lifting to make sure the variable is defined. With that, we’ve got rudimentary variables working. Try this out:

這裡只是簡單地將操作轉發到環境上下文中，環境做了一些繁重的工作保證變數已被定義。這樣，我們就可以支援基本的變數操作了。嘗試以下程式碼：

var a = 1;
var b = 2;
print a + b;

We can’t reuse code yet, but we can start to build up programs that reuse data.

我們還不能複用程式碼，但是我們可以構建能夠複用資料的程式。

8 . 4 Assignment

8.4 賦值

It’s possible to create a language that has variables but does not let you reassign—or mutate—them. Haskell is one example. SML supports only mutable references and arrays—variables cannot be reassigned. Rust steers you away from mutation by requiring a mut modifier to enable assignment.

你可以建立一種語言，其中有變數，但是不支援對該變數重新賦值（或更改）。Haskell就是一個例子。SML只支援可變引用和陣列——變數不能被重新賦值。Rust則透過要求mut識別符號開啟賦值，從而引導使用者遠離可更改變數。

Mutating a variable is a side effect and, as the name suggests, some language folks think side effects are dirty or inelegant. Code should be pure math that produces values—crystalline, unchanging ones—like an act of divine creation. Not some grubby automaton that beats blobs of data into shape, one imperative grunt at a time.

更改變數是一種副作用，顧名思義，一些語言專家認為副作用是骯髒或不優雅的。程式碼應該是純粹的數學，它會產生值——純淨的、不變的值——就像上帝造物一樣。而不是一些骯髒的自動機器，將資料塊轉換成各種形式，一次執行一條命令。

Lox is not so austere. Lox is an imperative language, and mutation comes with the territory. Adding support for assignment doesn’t require much work. Global variables already support redefinition, so most of the machinery is there now. Mainly, we’re missing an explicit assignment notation.

Lox沒有這麼嚴苛。Lox是一個命令式語言，可變性是與生俱來的，新增對賦值操作的支援並不需要太多工作。全域性變數已經支援了重定義，所以該機制的大部分功能已經存在。主要的是，我們缺少顯式的賦值符號。

8 . 4 . 1 Assignment syntax

8.4.1 賦值語法

That little = syntax is more complex than it might seem. Like most C-derived languages, assignment is an expression and not a statement. As in C, it is the lowest precedence expression form. That means the rule slots between expression and equality (the next lowest precedence expression).

這個小小的=語法比看起來要更復雜。像大多數C派生語言一樣，賦值是一個表示式，而不是一個語句。和C語言中一樣，它是優先順序最低的表示式形式。這意味著該規則在語法中處於 expression 和equality（下一個優先順序的表示式）之間。

expression     → assignment ;
assignment     → IDENTIFIER "=" assignment
               | equality ;

This says an assignment is either an identifier followed by an = and an expression for the value, or an equality (and thus any other) expression. Later, assignment will get more complex when we add property setters on objects, like:

這就是說，一個assignment（賦值式）要麼是一個識別符號，後跟一個=和一個對應值的表示式；要麼是一個等式（也就是任何其它）表示式。稍後，當我們在物件中新增屬性設定式時，賦值將會變得更加複雜，比如：

instance.field = "value";

The easy part is adding the new syntax tree node.

最簡單的部分就是新增新的語法樹節點。

tool/GenerateAst.java，在 main()方法中新增：

    defineAst(outputDir, "Expr", Arrays.asList(
      // 新增部分開始
      "Assign   : Token name, Expr value",
      // 新增部分結束
      "Binary   : Expr left, Token operator, Expr right",

It has a token for the variable being assigned to, and an expression for the new value. After you run the AstGenerator to get the new Expr.Assign class, swap out the body of the parser’s existing expression() method to match the updated rule.

其中包含被賦值變數的標記，一個計算新值的表示式。執行AstGenerator得到新的Expr.Assign類之後，替換掉解析器中現有的expression()方法的方法體，以匹配最新的規則。

lox/Parser.java，在 expression()方法中替換一行：

  private Expr expression() {
    // 替換部分開始
    return assignment();
    // 替換部分結束
  }

Here is where it gets tricky. A single token lookahead recursive descent parser can’t see far enough to tell that it’s parsing an assignment until after it has gone through the left-hand side and stumbled onto the =. You might wonder why it even needs to. After all, we don’t know we’re parsing a + expression until after we’ve finished parsing the left operand.

這裡開始變得棘手。單個標記前瞻遞迴下降解析器直到解析完左側標記並且遇到=標記之後，才能判斷出來正在解析的是賦值語句。你可能會想，為什麼需要這樣做？畢竟，我們也是完成左運算元的解析之後才知道正在解析的是+表示式。

The difference is that the left-hand side of an assignment isn’t an expression that evaluates to a value. It’s a sort of pseudo-expression that evaluates to a “thing” you can assign to. Consider:

區別在於，賦值表示式的左側不是可以求值的表示式，而是一種偽表示式，計算出的是一個你可以賦值的“東西”。考慮以下程式碼：

var a = "before";
a = "value";

On the second line, we don’t evaluate a (which would return the string “before”). We figure out what variable a refers to so we know where to store the right-hand side expression’s value. The classic terms for these two constructs are l-value and r-value. All of the expressions that we’ve seen so far that produce values are r-values. An l-value “evaluates” to a storage location that you can assign into.

在第二行中，我們不會對a進行求值（如果求值會返回“before”）。我們要弄清楚a指向的是什麼變數，這樣我們就知道該在哪裡儲存右側表示式的值。這兩個概念的經典術語是左值和右值。到目前為止，我們看到的所有產生值的表示式都是右值。左值"計算"會得到一個儲存位置，你可以向其賦值。

We want the syntax tree to reflect that an l-value isn’t evaluated like a normal expression. That’s why the Expr.Assign node has a Token for the left-hand side, not an Expr. The problem is that the parser doesn’t know it’s parsing an l-value until it hits the =. In a complex l-value, that may occur many tokens later.

我們希望語法樹能夠反映出左值不會像常規表示式那樣計算。這也是為什麼Expr.Assign節點的左側是一個Token，而不是Expr。問題在於，解析器直到遇到=才知道正在解析一個左值。在一個複雜的左值中，可能在出現很多標記之後才能識別到。

makeList().head.next = node;

We have only a single token of lookahead, so what do we do? We use a little trick, and it looks like this:

我們只會前瞻一個標記，那我們該怎麼辦呢？我們使用一個小技巧，看起來像下面這樣¹⁰：

lox/Parser.java，在 expressionStatement()方法後新增：

  private Expr assignment() {
    Expr expr = equality();

    if (match(EQUAL)) {
      Token equals = previous();
      Expr value = assignment();

      if (expr instanceof Expr.Variable) {
        Token name = ((Expr.Variable)expr).name;
        return new Expr.Assign(name, value);
      }

      error(equals, "Invalid assignment target."); 
    }

    return expr;
  }

Most of the code for parsing an assignment expression looks similar to that of the other binary operators like +. We parse the left-hand side, which can be any expression of higher precedence. If we find an =, we parse the right-hand side and then wrap it all up in an assignment expression tree node.

解析賦值表示式的大部分程式碼看起來與解析其它二元運算子（如+）的程式碼類似。我們解析左邊的內容，它可以是任何優先順序更高的表示式。如果我們發現一個=，就解析右側內容，並把它們封裝到一個複雜表示式樹節點中。

One slight difference from binary operators is that we don’t loop to build up a sequence of the same operator. Since assignment is right-associative, we instead recursively call assignment() to parse the right-hand side.

與二元運算子的一個細微差別在於，我們不會迴圈構建相同運算子的序列。因為賦值操作是右關聯的，所以我們遞迴呼叫 assignment()來解析右側的值。

The trick is that right before we create the assignment expression node, we look at the left-hand side expression and figure out what kind of assignment target it is. We convert the r-value expression node into an l-value representation.

訣竅在於，在建立賦值表示式節點之前，我們先檢視左邊的表示式，弄清楚它是什麼型別的賦值目標。然後我們將右值表示式節點轉換為左值的表示形式。

This conversion works because it turns out that every valid assignment target happens to also be valid syntax as a normal expression. Consider a complex field assignment like:

這種轉換是有效的，因為事實證明，每個有效的賦值目標正好也是符合普通表示式的有效語法¹¹。考慮一個複雜的屬性賦值操作，如下：

newPoint(x + 2, 0).y = 3;

The left-hand side of that assignment could also work as a valid expression.

該賦值表示式的左側也是一個有效的表示式。

newPoint(x + 2, 0).y;

The first example sets the field, the second gets it.

第一個例子設定該欄位，第二個例子獲取該欄位。

This means we can parse the left-hand side as if it were an expression and then after the fact produce a syntax tree that turns it into an assignment target. If the left-hand side expression isn’t a valid assignment target, we fail with a syntax error. That ensures we report an error on code like this:

這意味著，我們可以像解析表示式一樣解析左側內容，然後生成一個語法樹，將其轉換為賦值目標。如果左邊的表示式不是一個有效的賦值目標，就會出現一個語法錯誤¹²。這樣可以確保在遇到類似下面的程式碼時會報告錯誤：

a + b = c;

Right now, the only valid target is a simple variable expression, but we’ll add fields later. The end result of this trick is an assignment expression tree node that knows what it is assigning to and has an expression subtree for the value being assigned. All with only a single token of lookahead and no backtracking.

現在，唯一有效的賦值目標就是一個簡單的變量表達式，但是我們後面會新增屬性欄位。這個技巧的最終結果是一個賦值表示式樹節點，該節點知道要向什麼賦值，並且有一個表示式子樹用於計算要使用的值。所有這些都只用了一個前瞻標記，並且沒有回溯。

8 . 4 . 2 Assignment semantics

We have a new syntax tree node, so our interpreter gets a new visit method.

我們有了一個新的語法樹節點，所以我們的直譯器也需要一個新的訪問方法。

lox/Interpreter.java，在 visitVarStmt()方法後新增：

  @Override
  public Object visitAssignExpr(Expr.Assign expr) {
    Object value = evaluate(expr.value);
    environment.assign(expr.name, value);
    return value;
  }

For obvious reasons, it’s similar to variable declaration. It evaluates the right-hand side to get the value, then stores it in the named variable. Instead of using define() on Environment, it calls this new method:

很明顯，這與變數宣告很類似。首先，對右側表示式運算以獲取值，然後將其儲存到命名變數中。這裡不使用Environment中的 define()，而是呼叫下面的新方法：

lox/Environment.java，在 get()方法後新增：

  void assign(Token name, Object value) {
    if (values.containsKey(name.lexeme)) {
      values.put(name.lexeme, value);
      return;
    }

    throw new RuntimeError(name,
        "Undefined variable '" + name.lexeme + "'.");
  }

The key difference between assignment and definition is that assignment is not allowed to create a new variable. In terms of our implementation, that means it’s a runtime error if the key doesn’t already exist in the environment’s variable map.

賦值與定義的主要區別在於，賦值操作不允許建立新變數。就我們的實現而言，這意味著如果環境的變數對映中不存在變數的鍵，那就是一個執行時錯誤¹³。

The last thing the visit() method does is return the assigned value. That’s because assignment is an expression that can be nested inside other expressions, like so:

visit()方法做的最後一件事就是返回要賦給變數的值。這是因為賦值是一個表示式，可以巢狀在其他表示式裡面，就像這樣:

var a = 1;
print a = 2; // "2".

Our interpreter can now create, read, and modify variables. It’s about as sophisticated as early BASICs. Global variables are simple, but writing a large program when any two chunks of code can accidentally step on each other’s state is no fun. We want local variables, which means it’s time for scope.

我們的直譯器現在可以建立、讀取和修改變數。這和早期的BASICs一樣複雜。全域性變數很簡單，但是在編寫一個大型程式時，任何兩塊程式碼都可能不小心修改對方的狀態，這就不好玩了。我們需要區域性變數，這意味著是時候討論作用域了。

8 . 5 Scope

8.5 作用域

A scope defines a region where a name maps to a certain entity. Multiple scopes enable the same name to refer to different things in different contexts. In my house, “Bob” usually refers to me. But maybe in your town you know a different Bob. Same name, but different dudes based on where you say it.

作用域定義了名稱對映到特定實體的一個區域。多個作用域允許同一個名稱在不同的上下文中指向不同的內容。在我家，“Bob”通常指的是我自己，但是在你的身邊，你可能認識另外一個Bob。同一個名字，基於你的所知所見指向了不同的人。

Lexical scope (or the less commonly heard static scope) is a specific style of scoping where the text of the program itself shows where a scope begins and ends. In Lox, as in most modern languages, variables are lexically scoped. When you see an expression that uses some variable, you can figure out which variable declaration it refers to just by statically reading the code.

詞法作用域（或者比較少見的靜態作用域）是一種特殊的作用域定義方式，程式本身的文字顯示了作用域的開始和結束位置¹⁴。Lox，和大多數現代語言一樣，變數在詞法作用域內有效。當你看到使用了某些變數的表示式時，你透過靜態地閱讀程式碼就可以確定其指向的變數宣告。

For example:

舉例來說：

{
  var a = "first";
  print a; // "first".
}

{
  var a = "second";
  print a; // "second".
}

Here, we have two blocks with a variable a declared in each of them. You and I can tell just from looking at the code that the use of a in the first print statement refers to the first a, and the second one refers to the second.

這裡，我們在兩個塊中都定義了一個變數a。我們可以從程式碼中看出，在第一個print語句中使用的a指的是第一個a，第二個語句指向的是第二個變數。

This is in contrast to dynamic scope where you don’t know what a name refers to until you execute the code. Lox doesn’t have dynamically scoped variables, but methods and fields on objects are dynamically scoped.

這與動態作用域形成了對比，在動態作用域中，直到執行程式碼時才知道名稱指向的是什麼。Lox沒有動態作用域變數，但是物件上的方法和欄位是動態作用域的。

class Saxophone {
  play() {
    print "Careless Whisper";
  }
}

class GolfClub {
  play() {
    print "Fore!";
  }
}

fun playIt(thing) {
  thing.play();
}

When playIt() calls thing.play(), we don’t know if we’re about to hear “Careless Whisper” or “Fore!” It depends on whether you pass a Saxophone or a GolfClub to the function, and we don’t know that until runtime.

當playIt()呼叫thing.play()時，我們不知道我們將要聽到的是 "Careless Whisper "還是 "Fore!" 。這取決於你向函式傳遞的是Saxophone還是GolfClub，而我們在執行時才知道這一點。

Scope and environments are close cousins. The former is the theoretical concept, and the latter is the machinery that implements it. As our interpreter works its way through code, syntax tree nodes that affect scope will change the environment. In a C-ish syntax like Lox’s, scope is controlled by curly-braced blocks. (That’s why we call it block scope.)

作用域和環境是近親，前者是理論概念，而後者是實現它的機制。當我們的直譯器處理程式碼時，影響作用域的語法樹節點會改變環境上下文。在像Lox這樣的類C語言語法中，作用域是由花括號的塊控制的。（這就是為什麼我們稱它為塊範圍）。

{
  var a = "in block";
}
print a; // Error! No more "a".

The beginning of a block introduces a new local scope, and that scope ends when execution passes the closing }. Any variables declared inside the block disappear.

塊的開始引入了一個新的區域性作用域，當執行透過結束的}時，這個作用域就結束了。塊內宣告的任何變數都會消失。

8 . 5 . 1 Nesting and shadowing

8.5.1 巢狀和遮蔽

A first cut at implementing block scope might work like this:

實現塊作用域的第一步可能是這樣的：

1. As we visit each statement inside the block, keep track of any variables declared.

   當訪問塊內的每個語句時，跟蹤所有宣告的變數。

2. After the last statement is executed, tell the environment to delete all of those variables.

   執行完最後一條語句後，告訴環境將這些變數全部刪除。

That would work for the previous example. But remember, one motivation for local scope is encapsulation—a block of code in one corner of the program shouldn’t interfere with some other block. Check this out:

這對前面的例子是可行的。但是請記住，區域性作用域的一個目的是封裝——程式中一個塊內的程式碼，不應該幹擾其他程式碼塊。看看下面的例子：

// How loud?
var volume = 11;

// Silence.
volume = 0;

// Calculate size of 3x4x5 cuboid.
{
  var volume = 3 * 4 * 5;
  print volume;
}

Look at the block where we calculate the volume of the cuboid using a local declaration of volume. After the block exits, the interpreter will delete the global volume variable. That ain’t right. When we exit the block, we should remove any variables declared inside the block, but if there is a variable with the same name declared outside of the block, that’s a different variable. It shouldn’t get touched.

請看這個程式碼塊，在這裡我們宣告瞭一個區域性變數volume來計算長方體的體積。該程式碼塊退出後，直譯器將刪除全域性volume變數。這是不對的。當我們退出程式碼塊時，我們應該刪除在塊內宣告的所有變數，但是如果在程式碼塊外宣告瞭相同名稱的變數，那就是一個不同的變數。它不應該被刪除。

When a local variable has the same name as a variable in an enclosing scope, it shadows the outer one. Code inside the block can’t see it any more—it is hidden in the “shadow” cast by the inner one—but it’s still there.

當區域性變數與外圍作用域中的變數具有相同的名稱時，內部變數會遮蔽外部變數。程式碼塊內部不能再看到外部變數——它被遮蔽在內部變數的陰影中——但它仍然是存在的。

When we enter a new block scope, we need to preserve variables defined in outer scopes so they are still around when we exit the inner block. We do that by defining a fresh environment for each block containing only the variables defined in that scope. When we exit the block, we discard its environment and restore the previous one.

當進入一個新的塊作用域時，我們需要保留在外部作用域中定義的變數，這樣當我們退出內部程式碼塊時這些外部變數仍然存在。為此，我們為每個程式碼塊定義一個新的環境，該環境只包含該作用域中定義的變數。當我們退出程式碼塊時，我們將丟棄其環境並恢復前一個環境。

We also need to handle enclosing variables that are not shadowed.

我們還需要處理沒有被遮蔽的外圍變數。

var global = "outside";
{
  var local = "inside";
  print global + local;
}

Here, global lives in the outer global environment and local is defined inside the block’s environment. In that print statement, both of those variables are in scope. In order to find them, the interpreter must search not only the current innermost environment, but also any enclosing ones.

這段程式碼中，global在外部全域性環境中，local則在塊環境中定義。在執行print`語句時，這兩個變數都在作用域內。為了找到它們，直譯器不僅要搜尋當前最內層的環境，還必須搜尋所有外圍的環境。

We implement this by chaining the environments together. Each environment has a reference to the environment of the immediately enclosing scope. When we look up a variable, we walk that chain from innermost out until we find the variable. Starting at the inner scope is how we make local variables shadow outer ones.

我們透過將環境連結在一起來實現這一點。每個環境都有一個對直接外圍作用域的環境的引用。當我們查詢一個變數時，我們從最內層開始遍歷環境鏈直到找到該變數。從內部作用域開始，就是我們使區域性變數遮蔽外部變數的方式。

Before we add block syntax to the grammar, we’ll beef up our Environment class with support for this nesting. First, we give each environment a reference to its enclosing one.

在我們新增塊語法之前，我們要強化Environment類對這種巢狀的支援。首先，我們在每個環境中新增一個對其外圍環境的引用。

lox/Environment.java，在 Environment類中新增：

class Environment {
  // 新增部分開始
  final Environment enclosing;
  // 新增部分結束
  private final Map<String, Object> values = new HashMap<>();

This field needs to be initialized, so we add a couple of constructors.

這個欄位需要初始化，所以我們新增兩個建構函式。

lox/Environment.java，在 Environment類中新增：

  Environment() {
    enclosing = null;
  }

  Environment(Environment enclosing) {
    this.enclosing = enclosing;
  }

The no-argument constructor is for the global scope’s environment, which ends the chain. The other constructor creates a new local scope nested inside the given outer one.

無參建構函式用於全域性作用域環境，它是環境鏈的結束點。另一個建構函式用來建立一個巢狀在給定外部作用域內的新的區域性作用域。

We don’t have to touch the define() method—a new variable is always declared in the current innermost scope. But variable lookup and assignment work with existing variables and they need to walk the chain to find them. First, lookup:

我們不必修改define()方法——因為新變數總是在當前最內層的作用域中宣告。但是變數的查詢和賦值是結合已有的變數一起處理的，需要遍歷環境鏈以找到它們。首先是查詢操作：

lox/Environment.java，在 get()方法中新增：

      return values.get(name.lexeme);
    }
    // 新增部分開始
    if (enclosing != null) return enclosing.get(name);
    // 新增部分結束
    throw new RuntimeError(name,
        "Undefined variable '" + name.lexeme + "'.");

If the variable isn’t found in this environment, we simply try the enclosing one. That in turn does the same thing recursively, so this will ultimately walk the entire chain. If we reach an environment with no enclosing one and still don’t find the variable, then we give up and report an error as before.

如果當前環境中沒有找到變數，就在外圍環境中嘗試。然後遞迴地重複該操作，最終會遍歷完整個鏈路。如果我們到達了一個沒有外圍環境的環境，並且仍然沒有找到這個變數，那我們就放棄，並且像之前一樣報告一個錯誤。

Assignment works the same way.

賦值也是如此。

lox/Environment.java，在 assign()方法中新增：

      values.put(name.lexeme, value);
      return;
    }
    // 新增部分開始
    if (enclosing != null) {
      enclosing.assign(name, value);
      return;
    }
    // 新增部分結束
    throw new RuntimeError(name,

Again, if the variable isn’t in this environment, it checks the outer one, recursively.

同樣，如果變數不在此環境中，它會遞迴地檢查外圍環境。

8 . 5 . 2 Block syntax and semantics

8.5.2 塊語法和語義

Now that Environments nest, we’re ready to add blocks to the language. Behold the grammar:

現在環境已經嵌套了，我們就準備向語言中新增塊了。請看以下語法：

statement      → exprStmt
               | printStmt
               | block ;

block          → "{" declaration* "}" ;

A block is a (possibly empty) series of statements or declarations surrounded by curly braces. A block is itself a statement and can appear anywhere a statement is allowed. The syntax tree node looks like this:

塊是由花括號包圍的一系列語句或宣告(可能是空的)。塊本身就是一條語句，可以出現在任何允許語句的地方。語法樹節點如下所示。

tool/GenerateAst.java，在 main()方法中新增：

    defineAst(outputDir, "Stmt", Arrays.asList(
      // 新增部分開始
      "Block      : List<Stmt> statements",
      // 新增部分結束
      "Expression : Expr expression",

It contains the list of statements that are inside the block. Parsing is straightforward. Like other statements, we detect the beginning of a block by its leading token—in this case the {. In the statement() method, we add:

它包含塊中語句的列表。解析很簡單。與其他語句一樣，我們透過塊的字首標記(在本例中是{)來檢測塊的開始。在statement()方法中，我們新增程式碼：

lox/Parser.java，在 statement()方法中新增：

    if (match(PRINT)) return printStatement();
    // 新增部分開始
    if (match(LEFT_BRACE)) return new Stmt.Block(block());
    // 新增部分結束
    return expressionStatement();

All the real work happens here:

真正的工作都在這裡進行：

lox/Parser.java，在 expressionStatement()方法後新增：

  private List<Stmt> block() {
    List<Stmt> statements = new ArrayList<>();

    while (!check(RIGHT_BRACE) && !isAtEnd()) {
      statements.add(declaration());
    }

    consume(RIGHT_BRACE, "Expect '}' after block.");
    return statements;
  }

We create an empty list and then parse statements and add them to the list until we reach the end of the block, marked by the closing }. Note that the loop also has an explicit check for isAtEnd(). We have to be careful to avoid infinite loops, even when parsing invalid code. If the user forgets a closing }, the parser needs to not get stuck.

我們先建立一個空列表，然後解析語句並將其放入列表中，直至遇到塊的結尾（由}符號標識）¹⁵。注意，該迴圈還有一個明確的isAtEnd()檢查。我們必須小心避免無限迴圈，即使在解析無效程式碼時也是如此。如果使用者忘記了結尾的}，解析器需要保證不能被阻塞。

That’s it for syntax. For semantics, we add another visit method to Interpreter.

語法到此為止。對於語義，我們要在Interpreter中新增另一個訪問方法。

lox/Interpreter.java，在 execute()方法後新增：

  @Override
  public Void visitBlockStmt(Stmt.Block stmt) {
    executeBlock(stmt.statements, new Environment(environment));
    return null;
  }

To execute a block, we create a new environment for the block’s scope and pass it off to this other method:

要執行一個塊，我們先為該塊作用域建立一個新的環境，然後將其傳入下面這個方法：

lox/Interpreter.java，在execute()方法後新增：

  void executeBlock(List<Stmt> statements,
                    Environment environment) {
    Environment previous = this.environment;
    try {
      this.environment = environment;

      for (Stmt statement : statements) {
        execute(statement);
      }
    } finally {
      this.environment = previous;
    }
  }

This new method executes a list of statements in the context of a given environment. Up until now, the environment field in Interpreter always pointed to the same environment—the global one. Now, that field represents the current environment. That’s the environment that corresponds to the innermost scope containing the code to be executed.

這個新方法會在給定的環境上下文中執行一系列語句。在此之前，直譯器中的 environment 欄位總是指向相同的環境——全域性環境。現在，這個欄位會指向當前環境，也就是與要執行的程式碼的最內層作用域相對應的環境¹⁶。

To execute code within a given scope, this method updates the interpreter’s environment field, visits all of the statements, and then restores the previous value. As is always good practice in Java, it restores the previous environment using a finally clause. That way it gets restored even if an exception is thrown.

為了在給定作用域內執行程式碼，該方法會先更新直譯器的 environment 欄位，執行所有的語句，然後恢復之前的環境。基於Java中一貫的優良傳統，它使用finally子句來恢復先前的環境。這樣一來，即使拋出了異常，環境也會被恢復。

Surprisingly, that’s all we need to do in order to fully support local variables, nesting, and shadowing. Go ahead and try this out:

出乎意料的是，這就是我們為了完全支援區域性變數、巢狀和遮蔽所需要做的全部事情。試執行下面的程式碼：

var a = "global a";
var b = "global b";
var c = "global c";
{
  var a = "outer a";
  var b = "outer b";
  {
    var a = "inner a";
    print a;
    print b;
    print c;
  }
  print a;
  print b;
  print c;
}
print a;
print b;
print c;

Our little interpreter can remember things now. We are inching closer to something resembling a full-featured programming language.

我們的小直譯器現在可以記住東西了，我們距離全功能程式語言又近了一步。

a = 3;   // OK.
(a) = 3; // Error.

CHALLENGES

習題

1、The REPL no longer supports entering a single expression and automatically printing its result value. That’s a drag. Add support to the REPL to let users type in both statements and expressions. If they enter a statement, execute it. If they enter an expression, evaluate it and display the result value.

1、REPL不再支援輸入一個表示式並自動列印其結果值。這是個累贅。在 REPL 中增加支援，讓使用者既可以輸入語句又可以輸入表示式。如果他們輸入一個語句，就執行它。如果他們輸入一個表示式，則對錶達式求值並顯示結果值。

2、Maybe you want Lox to be a little more explicit about variable initialization. Instead of implicitly initializing variables to nil, make it a runtime error to access a variable that has not been initialized or assigned to, as in:

2、也許你希望Lox對變數的初始化更明確一些。與其隱式地將變數初始化為nil，不如將訪問一個未被初始化或賦值的變數作為一個執行時錯誤，如：

// No initializers.
var a;
var b;

a = "assigned";
print a; // OK, was assigned first.

print b; // Error!

3、What does the following program do?

3、下面的程式碼會怎麼執行？

var a = 1;
{
  var a = a + 2;
  print a;
}

What did you expect it to do? Is it what you think it should do? What does analogous code in other languages you are familiar with do? What do you think users will expect this to do?

你期望它怎麼執行？它是按照你的想法執行的嗎？你所熟悉的其他語言中的類似程式碼怎麼執行？你認為使用者會期望它怎麼執行？

DESIGN NOTE: IMPLICIT VARIABLE DECLARATION

設計筆記：隱式變數宣告

Lox has distinct syntax for declaring a new variable and assigning to an existing one. Some languages collapse those to only assignment syntax. Assigning to a non-existent variable automatically brings it into being. This is called implicit variable declaration and exists in Python, Ruby, and CoffeeScript, among others. JavaScript has an explicit syntax to declare variables, but can also create new variables on assignment. Visual Basic has an option to enable or disable implicit variables.

When the same syntax can assign or create a variable, each language must decide what happens when it isn’t clear about which behavior the user intends. In particular, each language must choose how implicit declaration interacts with shadowing, and which scope an implicitly declared variable goes into.

• In Python, assignment always creates a variable in the current function’s scope, even if there is a variable with the same name declared outside of the function.
• Ruby avoids some ambiguity by having different naming rules for local and global variables. However, blocks in Ruby (which are more like closures than like “blocks” in C) have their own scope, so it still has the problem. Assignment in Ruby assigns to an existing variable outside of the current block if there is one with the same name. Otherwise, it creates a new variable in the current block’s scope.
• CoffeeScript, which takes after Ruby in many ways, is similar. It explicitly disallows shadowing by saying that assignment always assigns to a variable in an outer scope if there is one, all the way up to the outermost global scope. Otherwise, it creates the variable in the current function scope.
• In JavaScript, assignment modifies an existing variable in any enclosing scope, if found. If not, it implicitly creates a new variable in the global scope.

The main advantage to implicit declaration is simplicity. There’s less syntax and no “declaration” concept to learn. Users can just start assigning stuff and the language figures it out.

Older, statically typed languages like C benefit from explicit declaration because they give the user a place to tell the compiler what type each variable has and how much storage to allocate for it. In a dynamically typed, garbage-collected language, that isn’t really necessary, so you can get away with making declarations implicit. It feels a little more “scripty”, more “you know what I mean”.

But is that a good idea? Implicit declaration has some problems.

• A user may intend to assign to an existing variable, but may have misspelled it. The interpreter doesn’t know that, so it goes ahead and silently creates some new variable and the variable the user wanted to assign to still has its old value. This is particularly heinous in JavaScript where a typo will create a global variable, which may in turn interfere with other code.
• JS, Ruby, and CoffeeScript use the presence of an existing variable with the same name—even in an outer scope—to determine whether or not an assignment creates a new variable or assigns to an existing one. That means adding a new variable in a surrounding scope can change the meaning of existing code. What was once a local variable may silently turn into an assignment to that new outer variable.
• In Python, you may want to assign to some variable outside of the current function instead of creating a new variable in the current one, but you can’t.

Over time, the languages I know with implicit variable declaration ended up adding more features and complexity to deal with these problems.

• Implicit declaration of global variables in JavaScript is universally considered a mistake today. “Strict mode” disables it and makes it a compile error.
• Python added a global statement to let you explicitly assign to a global variable from within a function. Later, as functional programming and nested functions became more popular, they added a similar nonlocal statement to assign to variables in enclosing functions.
• Ruby extended its block syntax to allow declaring certain variables to be explicitly local to the block even if the same name exists in an outer scope.

Given those, I think the simplicity argument is mostly lost. There is an argument that implicit declaration is the right default but I personally find that less compelling.

My opinion is that implicit declaration made sense in years past when most scripting languages were heavily imperative and code was pretty flat. As programmers have gotten more comfortable with deep nesting, functional programming, and closures, it’s become much more common to want access to variables in outer scopes. That makes it more likely that users will run into the tricky cases where it’s not clear whether they intend their assignment to create a new variable or reuse a surrounding one.

So I prefer explicitly declaring variables, which is why Lox requires it.

Lox使用不同的語法來宣告新變數和為已有變數賦值。有些語言將其簡化為只有賦值語法。對一個不存在的變數進行賦值時會自動生成該變數。這被稱為隱式變數宣告，存在於Python、Ruby和CoffeeScript以及其他語言中。JavaScript有一個顯式的語法來宣告變數，但是也可以在賦值時建立新變數。Visual Basic有一個選項可以啟用或停用隱式變數。

當同樣的語法既可以對變數賦值，也可以建立變數時，語言實現就必須決定在不清楚使用者的預期行為時該怎麼辦。特別是，每種語言必須選擇隱式變數宣告與變數遮蔽的互動方式，以及隱式變數應該屬於哪個作用域。

• 在Python中，賦值總是會在當前函式的作用域內建立一個變數，即使在函式外部宣告瞭同名變數。
• Ruby透過對區域性變數和全域性變數使用不同的命名規則，避免了一些歧義。 但是，Ruby中的塊（更像閉包，而不是C中的“塊”）具有自己的作用域，因此仍然存在問題。在Ruby中，如果已經存在一個同名的變數，則賦值會賦給當前塊之外的現有變數。否則，就會在當前塊的作用域中建立一個新變數。
• CoffeeScript在許多方面都效仿Ruby，這一點也類似。它明確禁止變數遮蔽，要求賦值時總是優先賦給外部作用域中現有的變數（一直到最外層的全域性作用域）。如果變數不存在的話，它會在當前函式作用域中建立新變數。
• 在JavaScript中，賦值會修改任意外部作用域中的一個現有變數（如果能找到該變數的話）。如果變數不存在，它就隱式地在全域性作用域內建立一個新的變數。

隱式宣告的主要優點是簡單。語法較少，無需學習“宣告”概念。使用者可以直接開始賦值，然後語言就能解決其它問題。

像C這樣較早的靜態型別語言受益於顯式宣告，是因為它們給使用者提供了一個地方，讓他們告訴編譯器每個變數的型別以及為它分配多少儲存空間。在動態型別、垃圾收集的語言中，這其實是沒有必要的，所以你可以透過隱式宣告來實現。這感覺更 "指令碼化"，更像是 "你懂我的意思吧"。

但這是就個好主意嗎？隱式宣告還存在一些問題。

• 使用者可能打算為現有變數賦值，但是出現拼寫錯誤。直譯器不知道這一點，所以它悄悄地建立了一些新變數，而使用者想要賦值的變數仍然是原來的值。這在JavaScript中尤其令人討厭，因為一個拼寫錯誤會建立一個全域性變數，這反過來又可能會干擾其它程式碼。
• JS、Ruby和CoffeeScript透過判斷是否存在同名變數——包括外部作用域——來確定賦值是建立新變數還是賦值給現有變數。這意味著在外圍作用域中新增一個新變數可能會改變現有程式碼的含義，原先的區域性變數可能會默默地變成對新的外部變數的賦值。
• 在Python中，你可能想要賦值給當前函式之外的某個變數，而不是在當前函式中建立一個新變數，但是你做不到。

隨著時間的推移，我所知道的具有隱式變數宣告的語言最後都增加了更多的功能和複雜性來處理這些問題。

• 現在，普遍認為JavaScript中全域性變數的隱式宣告是一個錯誤。“Strict mode ”停用了它，並將其成為一個編譯錯誤。
• Python添加了一個global語句，讓使用者可以在函式內部顯式地賦值給一個全域性變數。後來，隨著函數語言程式設計和巢狀函式越來越流行，他們添加了一個類似的nonlocal語句來賦值給外圍函式中的變數。
• Ruby擴充套件了它的塊語法，允許在塊中顯式地宣告某些變數，即使外部作用域中存在同名的變數。

考慮到這些，我認為簡單性的論點已經失去了意義。有一種觀點認為隱式宣告是正確的預設選項，但我個人認為這種說法不太有說服力。

我的觀點是，隱式宣告在過去的幾年裡是有意義的，當時大多數指令碼語言都是非常命令式的，程式碼是相當簡單直觀的。隨著程式設計師對深度巢狀、函數語言程式設計和閉包越來越熟悉，訪問外部作用域中的變數變得越來越普遍。這使得使用者更有可能遇到棘手的情況，即不清楚他們的賦值是要建立一個新變數還是重用外圍的已有變數。

所以我更喜歡顯式宣告變數，這就是Lox要這樣做的原因。

1. Pascal是一個異類。它區分了過程和函式。函式可以返回值，但過程不能。語言中有一個語句形式用於呼叫過程，但函式只能在需要表示式的地方被呼叫。在Pascal中沒有表示式語句。 ↩

2. 我只想說，BASIC和Python有專門的print語句，而且它們是真正的語言。當然，Python確實在3.0中刪除了print語句。 ↩

3. Java不允許使用小寫的void作為泛型型別引數，這是因為一些與型別擦除和堆疊有關的隱晦原因。相應的，提供了一個單獨的Void型別專門用於此用途，相當於裝箱後的void，就像Integer與int的關係。 ↩

4. 全域性狀態的名聲不好。當然，過多的全域性狀態（尤其是可變狀態）使維護大型程式變得困難。一個出色的軟體工程師會盡量減少使用全域性變數。但是，如果你正在拼湊一種簡單的程式語言，甚至是在學習第一種語言時，全域性變數的簡單性會有所幫助。我學習的第一門語言是BASIC，雖然我最後不再使用了，但是在我能夠熟練使用計算機完成有趣的工作之前，如果能夠不需要考慮作用域規則，這一點很好。 ↩

5. 程式碼塊語句的形式類似於表示式中的括號。“塊”本身處於“較高”的優先順序，並且可以在任何地方使用，如if語句的子語句中。而其中包含的可以是優先順序較低的語句。你可以在塊中宣告變數或其它名稱。透過大括號，你可以在只允許某些語句的位置書寫完整的語句語法。 ↩

6. Java中稱之為對映或雜湊對映。其他語言稱它們為雜湊表、字典(Python和c#)、雜湊表(Ruby和Perl)、表(Lua)或關聯陣列(PHP)。很久以前，它們被稱為分散表。 ↩

7. 我關於變數和作用域的原則是，“如果有疑問，參考Scheme的做法”。Scheme的開發人員可能比我們花了更多的時間來考慮變數範圍的問題——Scheme的主要目標之一就是向世界介紹詞法作用域，所以如果你跟隨他們的腳步，就很難出錯。Scheme允許在頂層重新定義變數。 ↩

8. 當然，這可能不是判斷一個數字是奇偶性的最有效方法（更不用說如果傳入一個非整數或負數，程式會發生不可控的事情）。忍耐一下吧。 ↩

9. 一些靜態型別的語言，如Java和C#，透過規定程式的頂層不是一連串的命令式語句來解決這個問題。相應的，它們認為程式是一組同時出現的宣告。語言實現在檢視任何函式的主體之前，會先宣告所有的名字。
   像C和Pascal這樣的老式語言並不是這樣工作的。相反，它們會強制使用者新增明確的前向宣告，從而在名稱完全定義之前先宣告它。這是對當時有限的計算能力的一種讓步。它們希望能夠透過一次文字遍歷就編譯完一個原始檔，因此這些編譯器不能在處理函式體之前先收集所有宣告。 ↩

10. 如果左側不是有效的賦值目標，我們會報告一個錯誤，但我們不會丟擲該錯誤，因為解析器並沒有處於需要進入恐慌模式和同步的混亂狀態。 ↩

11. 即使存在不是有效表示式的賦值目標，你也可以使用這個技巧。定義一個覆蓋語法，一個可以接受所有有效表示式和賦值目標的寬鬆語法。如果你遇到了=，並且左側不是有效的賦值目標則報告錯誤。相對地，如果沒有遇到=，而且左側不是有效的表示式也報告一個錯誤。 ↩

12. 早在解析一章，我就說過我們要在語法樹中表示圓括號表示式，因為我們以後會用到。這就是為什麼。我們需要能夠區分這些情況： ↩

13. 與Python和Ruby不同，Lox不做隱式變數宣告。 ↩

14. “詞法”來自希臘語“ lexikos”，意思是“與單詞有關”。 當我們在程式語言中使用它時，通常意味著您無需執行任何操作即可從原始碼本身中獲取到一些東西。詞法作用域是隨著ALGOL出現的。早期的語言通常是動態作用域的。當時的電腦科學家認為，動態作用域的執行速度更快。今天，多虧了早期的Scheme研究者，我們知道這不是真的。甚至可以說，情況恰恰相反。變數的動態作用域仍然存在於某些角落。Emacs Lisp預設為變數的動態作用域。Clojure中的binding宏也提供了。JavaScript中普遍不被喜歡的with語句將物件上的屬性轉換為動態作用域變數。 ↩

15. 讓block()返回原始的語句列表，並在statement()方法中將該列表封裝在Stmt.Block中，這看起來有點奇怪。我這樣做是因為稍後我們會重用block()來解析函式體，我們當然不希望函式體被封裝在Stmt.Block中。 ↩

16. 手動修改和恢復一個可變的environment欄位感覺很不優雅。另一種經典方法是顯式地將環境作為引數傳遞給每個訪問方法。如果要“改變”環境，就在沿樹向下遞迴時傳入一個不同的環境。你不必恢復舊的環境，因為新的環境存在於 Java 堆疊中，當直譯器從塊的訪問方法返回時，該環境會被隱式丟棄。我曾考慮過在jlox中這樣做，但在每一個訪問方法中加入一個環境引數，這有點繁瑣和冗長。為了讓這本書更簡單，我選擇了可變欄位。 ↩

9.控制流 Control Flow

Logic, like whiskey, loses its beneficial effect when taken in too large quantities.

​ —— Edward John Moreton Drax Plunkett, Lord Dunsany

邏輯和威士忌一樣，如果攝入太多，就會失去其有益的效果。

Compared to last chapter’s grueling marathon, today is a lighthearted frolic through a daisy meadow. But while the work is easy, the reward is surprisingly large.

與上一章艱苦的馬拉松相比，這一章就是在雛菊草地上的輕鬆嬉戲。雖然工作很簡單，但回報卻驚人的大。

Right now, our interpreter is little more than a calculator. A Lox program can only do a fixed amount of work before completing. To make it run twice as long you have to make the source code twice as lengthy. We’re about to fix that. In this chapter, our interpreter takes a big step towards the programming language major leagues: Turing-completeness.

現在，我們的解釋器只不過是一個計算器而已。一個Lox程序在結束之前只能做固定的工作量。要想讓它的運行時間延長一倍，你就必須讓源代碼的長度增加一倍。我們即將解決這個問題。在本章中，我們的解釋器向編程語言大聯盟邁出了一大步：圖靈完備性。

9 . 1Turing Machines (Briefly)

9.1 圖靈機（簡介）

In the early part of last century, mathematicians stumbled into a series of confusing paradoxes that led them to doubt the stability of the foundation they had built their work upon. To address that crisis, they went back to square one. Starting from a handful of axioms, logic, and set theory, they hoped to rebuild mathematics on top of an impervious foundation.

在上世紀初，數學家們陷入了一系列令人困惑的悖論之中，導致他們對自己工作所依賴的基礎的穩定性產生懷疑¹。為瞭解決這一危機，他們又回到了原點。他們希望從少量的公理、邏輯和集合理論開始，在一個不透水的地基上重建數學。

They wanted to rigorously answer questions like, “Can all true statements be proven?”, “Can we compute all functions that we can define?”, or even the more general question, “What do we mean when we claim a function is ‘computable’?”

他們想要嚴格地回答這樣的問題：“所有真實的陳述都可以被證明嗎？”，“我們可以計算我們能定義的所有函數嗎？”，甚至是更一般性的問題，“當我們聲稱一個函數是'可計算的'時，代表什麼意思？”

They presumed the answer to the first two questions would be “yes”. All that remained was to prove it. It turns out that the answer to both is “no”, and astonishingly, the two questions are deeply intertwined. This is a fascinating corner of mathematics that touches fundamental questions about what brains are able to do and how the universe works. I can’t do it justice here.

他們認為前兩個問題的答案應該是“是”，剩下的就是去證明它。但事實證明這兩個問題的答案都是“否”。而且令人驚訝的是，這兩個問題是深深地交織在一起的。這是數學的一個迷人的角落，它觸及了關於大腦能夠做什麼和宇宙如何運作的基本問題。我在這裡說不清楚。

What I do want to note is that in the process of proving that the answer to the first two questions is “no”, Alan Turing and Alonzo Church devised a precise answer to the last question—a definition of what kinds of functions are computable. They each crafted a tiny system with a minimum set of machinery that is still powerful enough to compute any of a (very) large class of functions.

我想指出的是，在證明前兩個問題的答案是 "否 "的過程中，艾倫·圖靈和阿隆佐·邱奇為最後一個問題設計了一個精確的答案，即定義了什麼樣的函數是可計算的。他們各自設計了一個具有最小機械集的微型系統，該系統仍然強大到足以計算一個超大類函數中的任何一個。

These are now considered the “computable functions”. Turing’s system is called a Turing machine. Church’s is the lambda calculus. Both are still widely used as the basis for models of computation and, in fact, many modern functional programming languages use the lambda calculus at their core.

這些現在被認為是“可計算函數”。圖靈的系統被稱為圖靈機²，邱奇的系統是lambda演算。這兩種方法仍然被廣泛用作計算模型的基礎，事實上，許多現代函數式編程語言的核心都是lambda演算。

Turing machines have better name recognition—there’s no Hollywood film about Alonzo Church yet—but the two formalisms are equivalent in power. In fact, any programming language with some minimal level of expressiveness is powerful enough to compute any computable function.

圖靈機的知名度更高——目前還沒有關於阿隆佐·邱奇的好萊塢電影，但這兩種形式在能力上是等價的。事實上，任何具有最低表達能力的編程語言都足以計算任何可計算函數。

You can prove that by writing a simulator for a Turing machine in your language. Since Turing proved his machine can compute any computable function, by extension, that means your language can too. All you need to do is translate the function into a Turing machine, and then run that on your simulator.

你可以用自己的語言為圖靈機編寫一個模擬器來證明這一點。由於圖靈證明瞭他的機器可以計算任何可計算函數，推而廣之，這意味著你的語言也可以。你所需要做的就是把函數翻譯成圖靈機，然後在你的模擬器上運行它。

If your language is expressive enough to do that, it’s considered Turing-complete. Turing machines are pretty dang simple, so it doesn’t take much power to do this. You basically need arithmetic, a little control flow, and the ability to allocate and use (theoretically) arbitrary amounts of memory. We’ve got the first. By the end of this chapter, we’ll have the second.

如果你的語言有足夠的表達能力來做到這一點，它就被認為是圖靈完備的。圖靈機非常簡單，所以它不需要太多的能力。您基本上只需要算術、一點控制流以及分配和使用(理論上)任意數量內存的能力。我們已經具備了第一個條件³。在本章結束時，我們將具備第二個條件。

9 . 2Conditional Execution

9.2 條件執行

Enough history, let’s jazz up our language. We can divide control flow roughly into two kinds:

說完了歷史，現在讓我們把語言優化一下。我們大致可以把控制流分為兩類：

• Conditional or branching control flow is used to not execute some piece of code. Imperatively, you can think of it as jumping ahead over a region of code.

  條件或分支控制流是用來不執行某些代碼的。意思是，你可以把它看作是跳過了代碼的一個區域。

• Looping control flow executes a chunk of code more than once. It jumps back so that you can do something again. Since you don’t usually want infinite loops, it typically has some conditional logic to know when to stop looping as well.

  循環控制流是用於多次執行一塊代碼的。它會向回跳轉，從而能再次執行某些代碼。用戶通常不需要無限循環，所以一般也會有一些條件邏輯用於判斷何時停止循環。

Branching is simpler, so we’ll start there. C-derived languages have two main conditional execution features, the if statement and the perspicaciously named “conditional” operator (?:). An if statement lets you conditionally execute statements and the conditional operator lets you conditionally execute expressions.

分支更簡單一些，所以我們先從分支開始實現。C衍生語言中包含兩個主要的條件執行功能，即if語句和“條件”運算符（?:）⁴。if語句使你可以按條件執行語句，而條件運算符使你可以按條件執行表達式。

For simplicity’s sake, Lox doesn’t have a conditional operator, so let’s get our if statement on. Our statement grammar gets a new production.

為了簡單起見，Lox沒有條件運算符，所以讓我們直接開始if語句吧。我們的語句語法需要一個新的生成式。

statement      → exprStmt
               | ifStmt
               | printStmt
               | block ;

ifStmt         → "if" "(" expression ")" statement
               ( "else" statement )? ;

An if statement has an expression for the condition, then a statement to execute if the condition is truthy. Optionally, it may also have an else keyword and a statement to execute if the condition is falsey. The syntax tree node has fields for each of those three pieces.

if語句有一個表達式作為條件，然後是一個在條件為真時要執行的語句。另外，它還可以有一個else關鍵字和條件為假時要執行的語句。語法樹節點中對語法的這三部分都有對應的字段。

tool/GenerateAst.java，在 main()方法中添加：

      "Expression : Expr expression",
      // 新增部分開始
      "If         : Expr condition, Stmt thenBranch," +
                  " Stmt elseBranch",
      // 新增部分結束
      "Print      : Expr expression",

Like other statements, the parser recognizes an if statement by the leading if keyword.

與其它語句類似，解析器通過開頭的if關鍵字來識別if語句。

lox/Parser.java，在 statement()方法中添加：

  private Stmt statement() {
    // 新增部分開始
    if (match(IF)) return ifStatement();
    // 新增部分結束
    if (match(PRINT)) return printStatement();

When it finds one, it calls this new method to parse the rest:

如果發現了if關鍵字，就調用下面的新方法解析其餘部分⁵：

lox/Parser.java，在 statement()方法後添加：

  private Stmt ifStatement() {
    consume(LEFT_PAREN, "Expect '(' after 'if'.");
    Expr condition = expression();
    consume(RIGHT_PAREN, "Expect ')' after if condition."); 

    Stmt thenBranch = statement();
    Stmt elseBranch = null;
    if (match(ELSE)) {
      elseBranch = statement();
    }

    return new Stmt.If(condition, thenBranch, elseBranch);
  }

As usual, the parsing code hews closely to the grammar. It detects an else clause by looking for the preceding else keyword. If there isn’t one, the elseBranch field in the syntax tree is null.

跟之前一樣，解析代碼嚴格遵循語法。它通過查找前面的else關鍵字來檢測else子句。如果沒有，語法樹中的elseBranch字段為null。

That seemingly innocuous optional else has, in fact, opened up an ambiguity in our grammar. Consider:

實際上，這個看似無傷大雅的可選項在我們的語法中造成了歧義。考慮以下代碼：

if (first) if (second) whenTrue(); else whenFalse();

Here’s the riddle: Which if statement does that else clause belong to? This isn’t just a theoretical question about how we notate our grammar. It actually affects how the code executes:

謎題是這樣的:這裡的else子句屬於哪個if語句?這不僅僅是一個關於如何標註語法的理論問題。它實際上會影響代碼的執行方式：

• If we attach the else to the first if statement, then whenFalse() is called if first is falsey, regardless of what value second has.

  如果我們將else語句關聯到第一個if語句，那麼當first為假時，無論second的值是多少，都將調用whenFalse()。

• If we attach it to the second if statement, then whenFalse() is only called if first is truthy and second is falsey.

  如果我們將else語句關聯到第二個if語句，那麼只有當first為真並且second為假時，才會調用whenFalse()。

Since else clauses are optional, and there is no explicit delimiter marking the end of the if statement, the grammar is ambiguous when you nest ifs in this way. This classic pitfall of syntax is called the dangling else problem.

由於else子句是可選的，而且沒有明確的分隔符來標記if語句的結尾，所以當你以這種方式嵌套if時，語法是不明確的。這種典型的語法陷阱被稱為懸空的else問題。

It is possible to define a context-free grammar that avoids the ambiguity directly, but it requires splitting most of the statement rules into pairs, one that allows an if with an else and one that doesn’t. It’s annoying.

也可以定義一個上下文無關的語法來直接避免歧義，但是需要將大部分語句規則拆分成對，一個是允許帶有else的if語句，另一個不允許。這很煩人。

Instead, most languages and parsers avoid the problem in an ad hoc way. No matter what hack they use to get themselves out of the trouble, they always choose the same interpretation—the else is bound to the nearest if that precedes it.

相反，大多數語言和解析器都以一種特殊的方式避免了這個問題。不管他們用什麼方法來解決這個問題，他們總是選擇同樣的解釋——else與前面最近的if綁定在一起。

Our parser conveniently does that already. Since ifStatement() eagerly looks for an else before returning, the innermost call to a nested series will claim the else clause for itself before returning to the outer if statements.

我們的解析器已經很方便地做到了這一點。因為 ifStatement()在返回之前會繼續尋找一個else子句，連續嵌套的最內層調用在返回外部的if語句之前，會先為自己聲明else語句。

Syntax in hand, we are ready to interpret.

語法就緒了，我們可以開始解釋了。

lox/Interpreter.java，在 visitExpressionStmt()後添加：

  @Override
  public Void visitIfStmt(Stmt.If stmt) {
    if (isTruthy(evaluate(stmt.condition))) {
      execute(stmt.thenBranch);
    } else if (stmt.elseBranch != null) {
      execute(stmt.elseBranch);
    }
    return null;
  }

The interpreter implementation is a thin wrapper around the self-same Java code. It evaluates the condition. If truthy, it executes the then branch. Otherwise, if there is an else branch, it executes that.

解釋器實現就是對相同的Java代碼的簡單包裝。它首先對條件表達式進行求值。如果為真，則執行then分支。否則，如果有存在else分支，就執行該分支。

If you compare this code to how the interpreter handles other syntax we’ve implemented, the part that makes control flow special is that Java if statement. Most other syntax trees always evaluate their subtrees. Here, we may not evaluate the then or else statement. If either of those has a side effect, the choice not to evaluate it becomes user visible.

如果你把這段代碼與解釋器中我們已實現的處理其它語法的代碼進行比較，會發現控制流中特殊的地方就在於Java的if語句。其它大多數語法樹總是會對子樹求值，但是這裡，我們可能會不執行then語句或else語句。如果其中任何一個語句有副作用，那麼選擇不執行某條語句就是用戶可見的。

9 . 3Logical Operators

9.3 邏輯操作符

Since we don’t have the conditional operator, you might think we’re done with branching, but no. Even without the ternary operator, there are two other operators that are technically control flow constructs—the logical operators and and or.

由於我們沒有條件運算符，你可能認為我們已經完成分支開發了，但其實還沒有。雖然沒有三元運算符，但是還有兩個其它操作符在技術上是控制流結構——邏輯運算符and和or。

These aren’t like other binary operators because they short-circuit. If, after evaluating the left operand, we know what the result of the logical expression must be, we don’t evaluate the right operand. For example:

它們與其它二進制運算符不同，是因為它們會短路。如果在計算左操作數之後，我們已經確切知道邏輯表達式的結果，那麼就不再計算右操作數。例如：

false and sideEffect();

For an and expression to evaluate to something truthy, both operands must be truthy. We can see as soon as we evaluate the left false operand that that isn’t going to be the case, so there’s no need to evaluate sideEffect() and it gets skipped.

對於一個and表達式來說，兩個操作數都必須是真，才能得到結果為真。我們只要看到左側的false操作數，就知道結果不會是真，也就不需要對sideEffect()求值，會直接跳過它。

This is why we didn’t implement the logical operators with the other binary operators. Now we’re ready. The two new operators are low in the precedence table. Similar to || and && in C, they each have their own precedence with or lower than and. We slot them right between assignment and equality.

這就是為什麼我們沒有在實現其它二元運算符的時候一起實現邏輯運算符。現在我們已經準備好了。這兩個新的運算符在優先級表中的位置很低，類似於C語言中的||和&&，它們都有各自的優先級，or低於and。我們把這兩個運算符插入assignment 和 equality之間。

expression     → assignment ;
assignment     → IDENTIFIER "=" assignment
               | logic_or ;
logic_or       → logic_and ( "or" logic_and )* ;
logic_and      → equality ( "and" equality )* ;

Instead of falling back to equality, assignment now cascades to logic_or. The two new rules, logic_or and logic_and, are similar to other binary operators. Then logic_and calls out to equality for its operands, and we chain back to the rest of the expression rules.

assignment 現在不是落到 equality，而是繼續進入logic_or。兩個新規則，logic_or 和 logic_and，與其它二元運算符類似。然後logic_and會調用equality計算其操作數，然後我們就鏈入了表達式規則的其它部分。

We could reuse the existing Expr.Binary class for these two new expressions since they have the same fields. But then visitBinaryExpr() would have to check to see if the operator is one of the logical operators and use a different code path to handle the short circuiting. I think it’s cleaner to define a new class for these operators so that they get their own visit method.

對於這兩個新表達式，我們可以重用Expr.Binary類，因為他們具有相同的字段。但是這樣的話，visitBinaryExpr() 方法中必須檢查運算符是否是邏輯運算符，並且要使用不同的代碼處理短路邏輯。我認為更整潔的方法是為這些運算符定義一個新類，這樣它們就有了自己的visit方法。

tool/GenerateAst.java，在main()方法中添加：

      "Literal  : Object value",
      // 新增部分開始
      "Logical  : Expr left, Token operator, Expr right",
      // 新增部分結束
      "Unary    : Token operator, Expr right",

To weave the new expressions into the parser, we first change the parsing code for assignment to call or().

為了將新的表達式加入到解析器中，我們首先將賦值操作的解析代碼改為調用or()方法。

lox/Parser.java,在 assignment()方法中替換一行：

  private Expr assignment() {
    // 新增部分開始
    Expr expr = or();
    // 新增部分結束
    if (match(EQUAL)) {

The code to parse a series of or expressions mirrors other binary operators.

解析一系列or語句的代碼與其它二元運算符相似。

lox/Parser.java，在 assignment()方法後添加：

  private Expr or() {
    Expr expr = and();

    while (match(OR)) {
      Token operator = previous();
      Expr right = and();
      expr = new Expr.Logical(expr, operator, right);
    }

    return expr;
  }

Its operands are the next higher level of precedence, the new and expression.

它的操作數是位於下一優先級的新的and表達式。

lox/Parser.java，在 or()方法後添加：

  private Expr and() {
    Expr expr = equality();

    while (match(AND)) {
      Token operator = previous();
      Expr right = equality();
      expr = new Expr.Logical(expr, operator, right);
    }

    return expr;
  }

That calls equality() for its operands, and with that, the expression parser is all tied back together again. We’re ready to interpret.

這裡會調用 equality() 計算操作數，這樣一來，表達式解析器又重新綁定到了一起。我們已經準備好進行解釋了。

lox/Interpreter.java，在 visitLiteralExpr()方法後添加：

  @Override
  public Object visitLogicalExpr(Expr.Logical expr) {
    Object left = evaluate(expr.left);

    if (expr.operator.type == TokenType.OR) {
      if (isTruthy(left)) return left;
    } else {
      if (!isTruthy(left)) return left;
    }

    return evaluate(expr.right);
  }

If you compare this to the earlier chapter’s visitBinaryExpr() method, you can see the difference. Here, we evaluate the left operand first. We look at its value to see if we can short-circuit. If not, and only then, do we evaluate the right operand.

如果你把這個方法與前面章節的visitBinaryExpr()方法相比較，就可以看出其中的區別。這裡，我們先計算左操作數。然後我們查看結果值，判斷是否可以短路。當且僅當不能短路時，我們才計算右側的操作數。

The other interesting piece here is deciding what actual value to return. Since Lox is dynamically typed, we allow operands of any type and use truthiness to determine what each operand represents. We apply similar reasoning to the result. Instead of promising to literally return true or false, a logic operator merely guarantees it will return a value with appropriate truthiness.

另一個有趣的部分是決定返回什麼實際值。由於Lox是動態類型的，我們允許任何類型的操作數，並使用真實性來確定每個操作數代表什麼。我們對結果採用類似的推理。邏輯運算符並不承諾會真正返回true或false，而只是保證它將返回一個具有適當真實性的值。

Fortunately, we have values with proper truthiness right at hand—the results of the operands themselves. So we use those. For example:

幸運的是，我們手邊就有具有適當真實性的值——即操作數本身的結果，所以我們可以直接使用它們。如：

print "hi" or 2; // "hi".
print nil or "yes"; // "yes".

On the first line, "hi" is truthy, so the or short-circuits and returns that. On the second line, nil is falsey, so it evaluates and returns the second operand, "yes".

在第一行，“hi”是真的，所以or短路並返回它。在第二行，nil是假的，因此它計算並返回第二個操作數“yes”。

That covers all of the branching primitives in Lox. We’re ready to jump ahead to loops. You see what I did there? Jump. Ahead. Get it? See, it’s like a reference to . . . oh, forget it.

這樣就完成了Lox中的所有分支原語，我們準備實現循環吧。

9 . 4While Loops

9.4 While循環

Lox features two looping control flow statements, while and for. The while loop is the simpler one, so we’ll start there. Its grammar is the same as in C.

Lox有兩種類型的循環控制流語句，分別是while和for。while循環更簡單一點，我們先從它開始.

statement      → exprStmt
               | ifStmt
               | printStmt
               | whileStmt
               | block ;

whileStmt      → "while" "(" expression ")" statement ;

We add another clause to the statement rule that points to the new rule for while. It takes a while keyword, followed by a parenthesized condition expression, then a statement for the body. That new grammar rule gets a syntax tree node.

我們在statement規則中添加一個子句，指向while對應的新規則whileStmt。該規則接收一個while關鍵字，後跟一個帶括號的條件表達式，然後是循環體對應的語句。新語法規則需要定義新的語法樹節點。

tool/GenerateAst.java,在 main()方法中新增，前一行後添加“,”

      "Print      : Expr expression",
      "Var        : Token name, Expr initializer",
      // 新增部分開始
      "While      : Expr condition, Stmt body"
      // 新增部分結束
    ));

The node stores the condition and body. Here you can see why it’s nice to have separate base classes for expressions and statements. The field declarations make it clear that the condition is an expression and the body is a statement.

該節點中保存了條件式和循環體。這裡就可以看出來為什麼表達式和語句最好要有單獨的基類。字段聲明清楚地表明瞭，條件是一個表達式，循環主體是一個語句。

Over in the parser, we follow the same process we used for if statements. First, we add another case in statement() to detect and match the leading keyword.

在解析器中，我們遵循與if語句相同的處理步驟。首先，在 statement() 添加一個case分支檢查並匹配開頭的關鍵字。

lox/Parser.java，在statement()方法中添加：

    if (match(PRINT)) return printStatement();
    // 新增部分開始
    if (match(WHILE)) return whileStatement();
    // 新增部分結束
    if (match(LEFT_BRACE)) return new Stmt.Block(block());

That delegates the real work to this method:

實際的工作委託給下面的方法：

lox/Parser.java，在 varDeclaration()方法後添加：

  private Stmt whileStatement() {
    consume(LEFT_PAREN, "Expect '(' after 'while'.");
    Expr condition = expression();
    consume(RIGHT_PAREN, "Expect ')' after condition.");
    Stmt body = statement();

    return new Stmt.While(condition, body);
  }

The grammar is dead simple and this is a straight translation of it to Java. Speaking of translating straight to Java, here’s how we execute the new syntax:

語法非常簡單，這裡將其直接翻譯為Java。說到直接翻譯成Java，下面是我們執行新語法的方式：

lox/Interpreter.java，在 visitVarStmt()方法後添加：

  @Override
  public Void visitWhileStmt(Stmt.While stmt) {
    while (isTruthy(evaluate(stmt.condition))) {
      execute(stmt.body);
    }
    return null;
  }

Like the visit method for if, this visitor uses the corresponding Java feature. This method isn’t complex, but it makes Lox much more powerful. We can finally write a program whose running time isn’t strictly bound by the length of the source code.

和if的訪問方法一樣，這裡的訪問方法使用了相應的Java特性。這個方法並不複雜，但它使Lox變得更加強大。我們終於可以編寫一個運行時間不受源代碼長度嚴格限制的程序了。

9 . 5For Loops

9.5 For循環

We’re down to the last control flow construct, Ye Olde C-style for loop. I probably don’t need to remind you, but it looks like this:

我們已經到了最後一個控制流結構，即老式的C語言風格for循環。我可能不需要提醒你，但還是要說它看起來是這樣的：

for (var i = 0; i < 10; i = i + 1) print i;

In grammarese, that’s:

在語法中，是這樣的：

statement      → exprStmt
               | forStmt
               | ifStmt
               | printStmt
               | whileStmt
               | block ;

forStmt        → "for" "(" ( varDecl | exprStmt | ";" )
                 expression? ";"
                 expression? ")" statement ;

Inside the parentheses, you have three clauses separated by semicolons:

在括號內，有三個由分號分隔的子語句：

1. The first clause is the initializer. It is executed exactly once, before anything else. It’s usually an expression, but for convenience, we also allow a variable declaration. In that case, the variable is scoped to the rest of the for loop—the other two clauses and the body.

   第一個子句是初始化式。它只會在任何其它操作之前執行一次。它通常是一個表達式，但是為了便利，我們也允許一個變量聲明。在這種情況下，變量的作用域就是for循環的其它部分——其餘兩個子式和循環體。

2. Next is the condition. As in a while loop, this expression controls when to exit the loop. It’s evaluated once at the beginning of each iteration, including the first. If the result is truthy, it executes the loop body. Otherwise, it bails.

   接下來是條件表達式。與while循環一樣，這個表達式控制了何時退出循環。它會在每次循環開始之前執行一次（包括第一次）。如果結果是真，就執行循環體；否則，就結束循環。

3. The last clause is the increment. It’s an arbitrary expression that does some work at the end of each loop iteration. The result of the expression is discarded, so it must have a side effect to be useful. In practice, it usually increments a variable.

   最後一個子句是增量式。它是一個任意的表達式，會在每次循環結束的時候做一些工作。因為表達式的結果會被丟棄，所以它必須有副作用才能有用。在實踐中，它通常會對變量進行遞增。

Any of these clauses can be omitted. Following the closing parenthesis is a statement for the body, which is typically a block.

這些子語句都可以忽略。在右括號之後是一個語句作為循環體，通常是一個代碼塊。

9 . 5 . 1Desugaring

9.5.1 語法脫糖

That’s a lot of machinery, but note that none of it does anything you couldn’t do with the statements we already have. If for loops didn’t support initializer clauses, you could just put the initializer expression before the for statement. Without an increment clause, you could simply put the increment expression at the end of the body yourself.

這裡包含了很多配件，但是請注意，它所做的任何事情中，沒有一件是無法用已有的語句實現的。如果for循環不支持初始化子句，你可以在for語句之前加一條初始化表達式。如果沒有增量子語句，你可以直接把增量表達式放在循環體的最後。

In other words, Lox doesn’t need for loops, they just make some common code patterns more pleasant to write. These kinds of features are called syntactic sugar. For example, the previous for loop could be rewritten like so:

換句話說，Lox不需要for循環，它們只是讓一些常見的代碼模式更容易編寫。這類功能被稱為語法糖⁶。例如，前面的for循環可以改寫成這樣：

{
  var i = 0;
  while (i < 10) {
    print i;
    i = i + 1;
  }
}

This script has the exact same semantics as the previous one, though it’s not as easy on the eyes. Syntactic sugar features like Lox’s for loop make a language more pleasant and productive to work in. But, especially in sophisticated language implementations, every language feature that requires back-end support and optimization is expensive.

雖然這個腳本不太容易看懂，但這個腳本與之前那個語義完全相同。像Lox中的for循環這樣的語法糖特性可以使語言編寫起來更加愉快和高效。但是，特別是在複雜的語言實現中，每一個需要後端支持和優化的語言特性都是代價昂貴的。

We can have our cake and eat it too by desugaring. That funny word describes a process where the front end takes code using syntax sugar and translates it to a more primitive form that the back end already knows how to execute.

我們可以通過脫糖來吃這個蛋糕。這個有趣的詞描述了這樣一個過程：前端接收使用了語法糖的代碼，並將其轉換成後端知道如何執行的更原始的形式。

We’re going to desugar for loops to the while loops and other statements the interpreter already handles. In our simple interpreter, desugaring really doesn’t save us much work, but it does give me an excuse to introduce you to the technique. So, unlike the previous statements, we won’t add a new syntax tree node. Instead, we go straight to parsing. First, add an import we’ll need soon.

我們將把for循環脫糖為while循環和其它解釋器可處理的其它語句。在我們的簡單解釋器中，脫糖真的不能為我們節省很多工作，但它確實給了我一個契機來向你介紹這一技術。因此，與之前的語句不同，我們不會為for循環添加一個新的語法樹節點。相反，我們會直接進行解析。首先，先引入一個我們要用到的依賴：

lox/Parser.java，添加代碼：

import java.util.ArrayList;
// 新增部分開始
import java.util.Arrays;
// 新增部分結束
import java.util.List;

Like every statement, we start parsing a for loop by matching its keyword.

像每個語句一樣，我們通過匹配for關鍵字來解析循環。

lox/Parser.java,在 statement()方法中新增：

  private Stmt statement() {
    // 新增部分開始
    if (match(FOR)) return forStatement();
    // 新增部分結束
    if (match(IF)) return ifStatement();

Here is where it gets interesting. The desugaring is going to happen here, so we’ll build this method a piece at a time, starting with the opening parenthesis before the clauses.

接下來是有趣的部分，脫糖也是在這裡發生的，所以我們會一點點構建這個方法，首先從子句之前的左括號開始。

lox/Parser.java，在 statement()方法後添加：

  private Stmt forStatement() {
    consume(LEFT_PAREN, "Expect '(' after 'for'.");

    // More here...
  }

The first clause following that is the initializer.

接下來的第一個子句是初始化式。

lox/Parser.java，在 forStatement()方法中替換一行：

    consume(LEFT_PAREN, "Expect '(' after 'for'.");
    // 替換部分開始
    Stmt initializer;
    if (match(SEMICOLON)) {
      initializer = null;
    } else if (match(VAR)) {
      initializer = varDeclaration();
    } else {
      initializer = expressionStatement();
    }
    // 替換部分結束
  }

If the token following the ( is a semicolon then the initializer has been omitted. Otherwise, we check for a var keyword to see if it’s a variable declaration. If neither of those matched, it must be an expression. We parse that and wrap it in an expression statement so that the initializer is always of type Stmt.

如果(後面的標記是分號，那麼初始化式就被省略了。否則，我們就檢查var關鍵字，看它是否是一個變量聲明。如果這兩者都不符合，那麼它一定是一個表達式。我們對其進行解析，並將其封裝在一個表達式語句中，這樣初始化器就必定屬於Stmt類型。

Next up is the condition.

接下來是條件表達式。

lox/Parser.java，在 forStatement()方法中添加代碼：

      initializer = expressionStatement();
    }
    // 新增部分開始
    Expr condition = null;
    if (!check(SEMICOLON)) {
      condition = expression();
    }
    consume(SEMICOLON, "Expect ';' after loop condition.");
    // 新增部分結束
  }

Again, we look for a semicolon to see if the clause has been omitted. The last clause is the increment.

同樣，我們查找分號檢查子句是否被忽略。最後一個子句是增量語句。

lox/Parser.java，在 forStatement()方法中添加：

    consume(SEMICOLON, "Expect ';' after loop condition.");
    // 新增部分開始
    Expr increment = null;
    if (!check(RIGHT_PAREN)) {
      increment = expression();
    }
    consume(RIGHT_PAREN, "Expect ')' after for clauses.");
    // 新增部分結束
  }

It’s similar to the condition clause except this one is terminated by the closing parenthesis. All that remains is the body.

它類似於條件式子句，只是這個子句是由右括號終止的。剩下的就是循環主體了。

lox/Parser.java，在 forStatement()方法中添加代碼：

    consume(RIGHT_PAREN, "Expect ')' after for clauses.");
    // 新增部分開始
    Stmt body = statement();

    return body;
    // 新增部分結束
  }

We’ve parsed all of the various pieces of the for loop and the resulting AST nodes are sitting in a handful of Java local variables. This is where the desugaring comes in. We take those and use them to synthesize syntax tree nodes that express the semantics of the for loop, like the hand-desugared example I showed you earlier.

我們已經解析了for循環的所有部分，得到的AST節點也存儲在一些Java本地變量中。這裡也是脫糖開始的地方。我們利用這些變量來合成表示for循環語義的語法樹節點，就像前面展示的手工脫糖的例子一樣。

The code is a little simpler if we work backward, so we start with the increment clause.

如果我們從後向前處理，代碼會更簡單一些，所以我們從增量子句開始。

lox/Parser.java，在 forStatement()方法中新增：

    Stmt body = statement();
    // 新增部分開始
    if (increment != null) {
      body = new Stmt.Block(
          Arrays.asList(
              body,
              new Stmt.Expression(increment)));
    }
    // 新增部分結束
    return body;

The increment, if there is one, executes after the body in each iteration of the loop. We do that by replacing the body with a little block that contains the original body followed by an expression statement that evaluates the increment.

如果存在增量子句的話，會在循環的每個迭代中在循環體結束之後執行。我們用一個代碼塊來代替循環體，這個代碼塊中包含原始的循環體，後面跟一個執行增量子語句的表達式語句。

lox/Parser.java，在 forStatement()方法中新增代碼：

    }
    // 新增部分開始
    if (condition == null) condition = new Expr.Literal(true);
    body = new Stmt.While(condition, body);
    // 新增部分結束
    return body;

Next, we take the condition and the body and build the loop using a primitive while loop. If the condition is omitted, we jam in true to make an infinite loop.

接下來，我們獲取條件式和循環體，並通過基本的while語句構建對應的循環。如果條件式被省略了，我們就使用true來創建一個無限循環。

lox/Parser.java，在 forStatement()方法中新增：

    body = new Stmt.While(condition, body);
    // 新增部分開始
    if (initializer != null) {
      body = new Stmt.Block(Arrays.asList(initializer, body));
    }
    // 新增部分結束
    return body;

Finally, if there is an initializer, it runs once before the entire loop. We do that by, again, replacing the whole statement with a block that runs the initializer and then executes the loop.

最後，如果有初始化式，它會在整個循環之前運行一次。我們的做法是，再次用代碼塊來替換整個語句，該代碼塊中首先運行一個初始化式，然後執行循環。

That’s it. Our interpreter now supports C-style for loops and we didn’t have to touch the Interpreter class at all. Since we desugared to nodes the interpreter already knows how to visit, there is no more work to do.

就是這樣。我們的解釋器現在已經支持了C語言風格的for循環，而且我們根本不需要修改解釋器類。因為我們通過脫糖將其轉換為瞭解釋器已經知道如何訪問的節點，所以無需做其它的工作。

Finally, Lox is powerful enough to entertain us, at least for a few minutes. Here’s a tiny program to print the first 21 elements in the Fibonacci sequence:

最後，Lox已強大到足以娛樂我們，至少幾分鐘。下面是一個打印斐波那契數列前21個元素的小程序：

var a = 0;
var temp;

for (var b = 1; a < 10000; b = temp + b) {
  print a;
  temp = a;
  a = b;
}

CHALLENGES

習題

1、A few chapters from now, when Lox supports first-class functions and dynamic dispatch, we technically won’t need branching statements built into the language. Show how conditional execution can be implemented in terms of those. Name a language that uses this technique for its control flow.

1、在接下來的幾章中，當Lox支持一級函數和動態調度時，從技術上講，我們就不需要在語言中內置分支語句。說明如何用這些特性來實現條件執行。說出一種在控制流中使用這種技術的語言。

2、Likewise, looping can be implemented using those same tools, provided our interpreter supports an important optimization. What is it, and why is it necessary? Name a language that uses this technique for iteration.

2、同樣地，只要我們的解釋器支持一個重要的優化，循環也可以用這些工具來實現。它是什麼？為什麼它是必要的？請說出一種使用這種技術進行迭代的語言。

3、Unlike Lox, most other C-style languages also support break and continue statements inside loops. Add support for break statements.

The syntax is a break keyword followed by a semicolon. It should be a syntax error to have a break statement appear outside of any enclosing loop. At runtime, a break statement causes execution to jump to the end of the nearest enclosing loop and proceeds from there. Note that the break may be nested inside other blocks and if statements that also need to be exited.

3、與Lox不同，大多數其他C風格語言也支持循環內部的break和continue語句。添加對break語句的支持。

語法是一個break關鍵字，後面跟一個分號。如果break語句出現在任何封閉的循環之後，那就應該是一個語法錯誤。在運行時，break語句會跳轉到最內層的封閉循環的末尾，並從那裡開始繼續執行。注意，break語句可以嵌套在其它需要退出的代碼塊和if語句中。

DESIGN NOTE: SPOONFULS OF SYNTACTIC SUGAR

設計筆記：一些語法糖

When you design your own language, you choose how much syntactic sugar to pour into the grammar. Do you make an unsweetened health food where each semantic operation maps to a single syntactic unit, or some decadent dessert where every bit of behavior can be expressed ten different ways? Successful languages inhabit all points along this continuum.

On the extreme acrid end are those with ruthlessly minimal syntax like Lisp, Forth, and Smalltalk. Lispers famously claim their language “has no syntax”, while Smalltalkers proudly show that you can fit the entire grammar on an index card. This tribe has the philosophy that the language doesn’t need syntactic sugar. Instead, the minimal syntax and semantics it provides are powerful enough to let library code be as expressive as if it were part of the language itself.

Near these are languages like C, Lua, and Go. They aim for simplicity and clarity over minimalism. Some, like Go, deliberately eschew both syntactic sugar and the kind of syntactic extensibility of the previous category. They want the syntax to get out of the way of the semantics, so they focus on keeping both the grammar and libraries simple. Code should be obvious more than beautiful.

Somewhere in the middle you have languages like Java, C#, and Python. Eventually you reach Ruby, C++, Perl, and D—languages which have stuffed so much syntax into their grammar, they are running out of punctuation characters on the keyboard.

To some degree, location on the spectrum correlates with age. It’s relatively easy to add bits of syntactic sugar in later releases. New syntax is a crowd pleaser, and it’s less likely to break existing programs than mucking with the semantics. Once added, you can never take it away, so languages tend to sweeten with time. One of the main benefits of creating a new language from scratch is it gives you an opportunity to scrape off those accumulated layers of frosting and start over.

Syntactic sugar has a bad rap among the PL intelligentsia. There’s a real fetish for minimalism in that crowd. There is some justification for that. Poorly designed, unneeded syntax raises the cognitive load without adding enough expressiveness to carry its weight. Since there is always pressure to cram new features into the language, it takes discipline and a focus on simplicity to avoid bloat. Once you add some syntax, you’re stuck with it, so it’s smart to be parsimonious.

At the same time, most successful languages do have fairly complex grammars, at least by the time they are widely used. Programmers spend a ton of time in their language of choice, and a few niceties here and there really can improve the comfort and efficiency of their work.

Striking the right balance—choosing the right level of sweetness for your language—relies on your own sense of taste.

當你設計自己的語言時，你可以選擇在語法中注入多少語法糖。你是要做一種不加糖、每個語法操作都對應單一的語法單元的健康食品？還是每一點行為都可以用10種不同方式實現的墮落的甜點？把這兩種情況看作是兩端的話，成功的語言分佈在這個連續體的每個中間點。

極端尖刻的一側是那些語法極少的語言，如Lisp、Forth和SmallTalk。Lisp的擁躉廣泛聲稱他們的語言 "沒有語法"，而Smalltalk的人則自豪地表示，你可以把整個語法放在一張索引卡上。這個部落的理念是，語言不需要句法糖。相反，它所提供的最小的語法和語義足夠強大，足以讓庫中的代碼像語言本身的一部分一樣具有表現力。

接近這些的是像C、Lua和Go這樣的語言。他們的目標是簡單和清晰，而不是極簡主義。有些語言，如Go，故意避開了語法糖和前一類語言的語法擴展性。他們希望語法不受語義的影響，所以他們專注於保持語法和庫的簡單性。代碼應該是明顯的，而不是漂亮的。

介於之間的是Java、C#和Python等語言。最終，你會看到Ruby、C++、Perl和D-語言，它們在語法中塞入了太多的句法規則，以至於鍵盤上的標點符號都快用完了。

在某種程度上，頻譜上的位置與年齡相關。在後續的版本中增加一些語法糖是比較容易的。新的語法很容易讓人喜歡，而且與修改語義相比，它更不可能破壞現有的程序。一旦加進去，你就再也不能把它去掉了，所以隨著時間的推移，語言會變得越來越甜。從頭開始創建一門新語言的主要好處之一是，它給了你一個機會去刮掉那些累積的糖霜並重新開始。

語法糖在PL知識分子中名聲不佳。那群人對極簡主義有一種真正的迷戀。這是有一定道理的。設計不良的、不必要的語法增加了認知負荷，卻沒有增加相匹配的表達能力。因為一直會有向語言中添加新特性的壓力，所以需要自律並專注於簡單，以避免臃腫。一旦你添加了一些語法，你就會被它困住，所以明智的做法是要精簡。

同時，大多數成功的語言都有相當複雜的語法，至少在它們被廣泛使用的時候是這樣。程序員在他們所選擇的語言上花費了大量的時間，一些隨處可見的細節確實可以提高他們工作時的舒適度和效率。

找到正確的平衡——為你的語言選擇適當的甜度——取決於你自己的品味。

1. 其中最著名的就是羅素悖論。最初，集合理論允許你定義任何類型的集合。只要你能用英語描述它，它就是有效的。自然，鑑於數學家對自引用的偏愛，集合可以包含其他的集合。於是，羅素，這個無賴，提出了：
   R是所有不包含自身的集合的集合。
   R是否包含自己？如果不包含，那麼根據定義的後半部分，它應該包含；如果包含，那麼它就不滿足定義。腦袋要炸了。 ↩

2. 圖靈把他的發明稱為 “a-machines”，表示“automatic(自動)”。他並沒有自吹自擂到把自己的名字放入其中。後來的數學家們為他做了這些。這就是你如何在成名的同時還能保持謙虛。 ↩

3. 我們也基本上具備第三個條件了。你可以創建和拼接任意大小的字符串，因此也就可以存儲無界內存。但我們還無法訪問字符串的各個部分。 ↩

4. 條件操作符也稱為三元操作符，因為它是C語言中唯一接受三個操作數的操作符。 ↩

5. 條件周圍的圓括號只有一半是有用的。您需要在條件和then語句之間設置某種分隔符，否則解析器無法判斷是否到達條件表達式的末尾。但是 if 後面的小括號並沒有什麼用處。Dennis Ritchie 把它放在那裡是為了讓他可以使用 )作為結尾的分隔符，而且不會出現不對稱的小括號。其他語言，比如Lua和一些BASICs，使用then這樣的關鍵字作為結束分隔符，在條件表達式之前沒有任何內容。而Go和Swift則要求語句必須是一個帶括號的塊，這樣就可以使用語句開頭的{來判斷條件表達式是否結束。 ↩

6. 這個令人愉快的短語是由Peter J. Landin在1964年創造的，用來描述ALGOL等語言支持的一些很好的表達式形式是如何在更基本但可能不太令人滿意的lambda演算的基礎上增添一些小甜頭的。 ↩

10.函式Functions

And that is also the way the human mind works—by the compounding of old ideas into new structures that become new ideas that can themselves be used in compounds, and round and round endlessly, growing ever more remote from the basic earthbound imagery that is each language’s soil.

​ —— Douglas R. Hofstadter, I Am a Strange Loop

這也是人類思維的運作方式——將舊的想法複合成為新結構，成為新的想法，而這些想法本身又可以被用於複合，迴圈往復，無休無止，越來越遠離每一種語言賴以生存的基本的土壤。

This chapter marks the culmination of a lot of hard work. The previous chapters add useful functionality in their own right, but each also supplies a piece of a puzzle. We’ll take those pieces—expressions, statements, variables, control flow, and lexical scope—add a couple more, and assemble them all into support for real user-defined functions and function calls.

這一章標誌著很多艱苦工作的一個高潮。在前面的章節中，各自添加了一些有用的功能，但是每一章也都提供了一個拼圖的碎片。我們整理這些碎片——表示式、語句、變數、控制流和詞法作用域，再加上其它功能，並把他們組合起來，以支援真正的使用者定義函式和函式呼叫。

10 . 1 Function Calls

10.1 函式呼叫

You’re certainly familiar with C-style function call syntax, but the grammar is more subtle than you may realize. Calls are typically to named functions like:

你肯定熟悉C語言風格的函式呼叫語法，但其語法可能比你意識到的更微妙。呼叫通常是指向命名的函式，例如：

average(1, 2);

But the name of the function being called isn’t actually part of the call syntax. The thing being called—the callee—can be any expression that evaluates to a function. (Well, it does have to be a pretty high precedence expression, but parentheses take care of that.) For example:

但是被呼叫函式的名稱實際上並不是呼叫語法的一部分。被呼叫者（ callee）可以是計算結果為一個函式的任何表示式。(好吧，它必須是一個非常高優先順序的表示式，但是圓括號可以解決這個問題。)例如：

getCallback()();

There are two call expressions here. The first pair of parentheses has getCallback as its callee. But the second call has the entire getCallback() expression as its callee. It is the parentheses following an expression that indicate a function call. You can think of a call as sort of like a postfix operator that starts with (.

這裡有兩個函式呼叫。第一對括號將getCallback作為其被呼叫者。但是第二對括號將整個getCallback() 表示式作為其被呼叫者。表示式後面的小括號表示函式呼叫，你可以把呼叫看作是一種以(開頭的字尾運算子。

This “operator” has higher precedence than any other operator, even the unary ones. So we slot it into the grammar by having the unary rule bubble up to a new call rule.

這個“運算子”比其它運算子（包括一元運算子）有更高的優先順序。所以我們透過讓unary規則跳轉到新的call規則，將其新增到語法中¹。

unary          → ( "!" | "-" ) unary | call ;
call           → primary ( "(" arguments? ")" )* ;

This rule matches a primary expression followed by zero or more function calls. If there are no parentheses, this parses a bare primary expression. Otherwise, each call is recognized by a pair of parentheses with an optional list of arguments inside. The argument list grammar is:

該規則匹配一個基本表示式，後面跟著0個或多個函式呼叫。如果沒有括號，則解析一個簡單的基本表示式。否則，每一對圓括號都表示一個函式呼叫，圓括號內有一個可選的引數列表。引數列表語法是：

arguments      → expression ( "," expression )* ;

This rule requires at least one argument expression, followed by zero or more other expressions, each preceded by a comma. To handle zero-argument calls, the call rule itself considers the entire arguments production to be optional.

這個規則要求至少有一個參數列達式，後面可以跟0個或多個其它表示式，每兩個表示式之間用,分隔。為了處理無參呼叫，call規則本身認為整個arguments生成式是可選的。

I admit, this seems more grammatically awkward than you’d expect for the incredibly common “zero or more comma-separated things” pattern. There are some sophisticated metasyntaxes that handle this better, but in our BNF and in many language specs I’ve seen, it is this cumbersome.

我承認，對於極其常見的 "零或多個逗號分隔的事物 "模式來說，這在語法上似乎比你想象的更難處理。有一些複雜的元語法可以更好地處理這個問題，但在我們的BNF和我見過的許多語言規範中，它就是如此的麻煩。

Over in our syntax tree generator, we add a new node.

在我們的語法樹生成器中，我們新增一個新節點。

tool/GenerateAst.java，在 main()方法中新增程式碼：

      "Binary   : Expr left, Token operator, Expr right",
      // 新增部分開始
      "Call     : Expr callee, Token paren, List<Expr> arguments",
      // 新增部分結束
      "Grouping : Expr expression",

It stores the callee expression and a list of expressions for the arguments. It also stores the token for the closing parenthesis. We’ll use that token’s location when we report a runtime error caused by a function call.

它儲存了被呼叫者表示式和參數列達式列表，同時也儲存了右括號標記。當我們報告由函式呼叫引起的執行時錯誤時，會使用該標記的位置。

Crack open the parser. Where unary() used to jump straight to primary(), change it to call, well, call().

開啟解析器，原來unary()直接跳轉到primary()方法，將其修改為呼叫call()。

lox/Parser.java，在 unary()方法中替換一行：

      return new Expr.Unary(operator, right);
    }
    // 替換部分開始
    return call();
    // 替換部分結束
  }

Its definition is:

該方法定義為：

lox/Parser.java，在 unary()方法後新增²：

  private Expr call() {
    Expr expr = primary();

    while (true) { 
      if (match(LEFT_PAREN)) {
        expr = finishCall(expr);
      } else {
        break;
      }
    }

    return expr;
  }

The code here doesn’t quite line up with the grammar rules. I moved a few things around to make the code cleaner—one of the luxuries we have with a handwritten parser. But it’s roughly similar to how we parse infix operators. First, we parse a primary expression, the “left operand” to the call. Then, each time we see a (, we call finishCall() to parse the call expression using the previously parsed expression as the callee. The returned expression becomes the new expr and we loop to see if the result is itself called.

這裡的程式碼與語法規則並非完全一致。為了保持程式碼簡潔，我調整了一些東西——這是我們手寫解析器的優點之一。但它與我們解析中綴運算子的方式類似。首先，我們解析一個基本表示式，即呼叫的左運算元。然後，每次看到(，我們就呼叫finishCall()解析呼叫表示式，並使用之前解析出的表示式作為被呼叫者。返回的表示式成為新的expr，我們迴圈檢查其結果是否被呼叫。

The code to parse the argument list is in this helper:

解析引數列表的程式碼在下面的工具方法中：

lox/Parser.java，在 unary()方法後新增：

  private Expr finishCall(Expr callee) {
    List<Expr> arguments = new ArrayList<>();
    if (!check(RIGHT_PAREN)) {
      do {
        arguments.add(expression());
      } while (match(COMMA));
    }

    Token paren = consume(RIGHT_PAREN,
                          "Expect ')' after arguments.");

    return new Expr.Call(callee, paren, arguments);
  }

This is more or less the arguments grammar rule translated to code, except that we also handle the zero-argument case. We check for that case first by seeing if the next token is ). If it is, we don’t try to parse any arguments.

這或多或少是arguments 語法規則翻譯成程式碼的結果，除了我們這裡還處理了無參情況。我們首先判斷下一個標記是否)來檢查這種情況。如果是，我們就不會嘗試解析任何引數。

Otherwise, we parse an expression, then look for a comma indicating that there is another argument after that. We keep doing that as long as we find commas after each expression. When we don’t find a comma, then the argument list must be done and we consume the expected closing parenthesis. Finally, we wrap the callee and those arguments up into a call AST node.

如果不是，我們就解析一個表示式，然後尋找逗號（表明後面還有一個引數）。只要我們在表示式後面發現逗號，就會繼續解析表示式。當我們找不到逗號時，說明引數列表已經結束，我們繼續消費預期的右括號。最終，我們將被呼叫者和這些引數封裝成一個函式呼叫的AST節點。

10 . 1 . 1 Maximum argument counts

10.1.1 最大引數數量

Right now, the loop where we parse arguments has no bound. If you want to call a function and pass a million arguments to it, the parser would have no problem with it. Do we want to limit that?

現在，我們解析引數的迴圈是沒有邊界的。如果你想呼叫一個函式並向其傳遞一百萬個引數，解析器不會有任何問題。我們要對此進行限制嗎？

Other languages have various approaches. The C standard says a conforming implementation has to support at least 127 arguments to a function, but doesn’t say there’s any upper limit. The Java specification says a method can accept no more than 255 arguments.

其它語言採用了不同的策略。C語言標準要求在符合標準的實現中，一個函式至少要支援127個引數，但是沒有指定任何上限。Java規範規定一個方法可以接受不超過255個引數³。

Our Java interpreter for Lox doesn’t really need a limit, but having a maximum number of arguments will simplify our bytecode interpreter in Part III. We want our two interpreters to be compatible with each other, even in weird corner cases like this, so we’ll add the same limit to jlox.

Lox的Java直譯器實際上並不需要限制，但是設定一個最大的引數數量限制可以簡化第三部分中的位元組碼直譯器。即使是在這樣奇怪的地方里，我們也希望兩個直譯器能夠相互相容，所以我們為jlox新增同樣的限制。

lox/Parser.java，在 finishCall()方法中新增：

      do {
        // 新增部分開始
        if (arguments.size() >= 255) {
          error(peek(), "Can't have more than 255 arguments.");
        }
        // 新增部分結束
        arguments.add(expression());

Note that the code here reports an error if it encounters too many arguments, but it doesn’t throw the error. Throwing is how we kick into panic mode which is what we want if the parser is in a confused state and doesn’t know where it is in the grammar anymore. But here, the parser is still in a perfectly valid state—it just found too many arguments. So it reports the error and keeps on keepin’ on.

請注意，如果發現引數過多，這裡的程式碼會報告一個錯誤，但是不會丟擲該錯誤。丟擲錯誤是進入恐慌模式的方法，如果解析器處於混亂狀態，不知道自己在語法中處於什麼位置，那這就是我們想要的。但是在這裡，解析器仍然處於完全有效的狀態，只是發現了太多的引數。所以它會報告這個錯誤，並繼續執行解析。

10 . 1 . 2 Interpreting function calls

10.1.2 解釋函式呼叫

We don’t have any functions we can call, so it seems weird to start implementing calls first, but we’ll worry about that when we get there. First, our interpreter needs a new import.

我們還沒有任何可以呼叫的函式，所以先實現函式呼叫似乎有點奇怪，但是這個問題我們後面再考慮。首先，我們的直譯器需要引入一個新依賴。

lox/Interpreter.java

// 新增部分開始
import java.util.ArrayList;
// 新增部分結束
import java.util.List;

As always, interpretation starts with a new visit method for our new call expression node.

跟之前一樣，解釋工作從新的呼叫表示式節點對應的新的visit方法開始⁴。

lox/Interpreter.java，在 visitBinaryExpr()方法後新增：

  @Override
  public Object visitCallExpr(Expr.Call expr) {
    Object callee = evaluate(expr.callee);

    List<Object> arguments = new ArrayList<>();
    for (Expr argument : expr.arguments) { 
      arguments.add(evaluate(argument));
    }

    LoxCallable function = (LoxCallable)callee;
    return function.call(this, arguments);
  }

First, we evaluate the expression for the callee. Typically, this expression is just an identifier that looks up the function by its name, but it could be anything. Then we evaluate each of the argument expressions in order and store the resulting values in a list.

首先，對被呼叫者的表示式求值。通常情況下，這個表示式只是一個識別符號，可以透過它的名字來查詢函式。但它可以是任何東西。然後，我們依次對每個參數列達式求值，並將結果值儲存在一個列表中。

Once we’ve got the callee and the arguments ready, all that remains is to perform the call. We do that by casting the callee to a LoxCallable and then invoking a call() method on it. The Java representation of any Lox object that can be called like a function will implement this interface. That includes user-defined functions, naturally, but also class objects since classes are “called” to construct new instances. We’ll also use it for one more purpose shortly.

一旦我們準備好被呼叫者和引數，剩下的就是執行函式呼叫。我們將被呼叫者轉換為LoxCallable，然後對其呼叫call()方法來實現。任何可以像函式一樣被呼叫的Lox物件的Java表示都要實現這個介面。這自然包括使用者定義的函式，但也包括類物件，因為類會被 "呼叫 "來建立新的例項。稍後我們還將把它用於另一個目的。

There isn’t too much to this new interface.

這個新介面中沒有太多內容。

lox/LoxCallable.java，建立新檔案：

package com.craftinginterpreters.lox;

import java.util.List;

interface LoxCallable {
  Object call(Interpreter interpreter, List<Object> arguments);
}

We pass in the interpreter in case the class implementing call() needs it. We also give it the list of evaluated argument values. The implementer’s job is then to return the value that the call expression produces.

我們會傳入直譯器，以防實現call()方法的類會需要它。我們也會提供已求值的引數值列表。介面實現者的任務就是返回呼叫表示式產生的值。

10 . 1 . 3 Call type errors

10.1.3 呼叫型別錯誤

Before we get to implementing LoxCallable, we need to make the visit method a little more robust. It currently ignores a couple of failure modes that we can’t pretend won’t occur. First, what happens if the callee isn’t actually something you can call? What if you try to do this:

在實現LoxCallable之前，必須先強化一下我們的visit方法。這個方法忽略了兩個可能出現的錯誤場景。第一個，如果被呼叫者無法被呼叫，會發生什麼？比如：

"totally not a function"();

Strings aren’t callable in Lox. The runtime representation of a Lox string is a Java string, so when we cast that to LoxCallable, the JVM will throw a ClassCastException. We don’t want our interpreter to vomit out some nasty Java stack trace and die. Instead, we need to check the type ourselves first.

在Lox中，字串不是可呼叫的資料型別。Lox字串在執行時中的本質其實是java字串，所以當我們把它當作LoxCallable 處理的時候，JVM就會丟擲ClassCastException。我們並不想讓我們的直譯器吐出一坨java堆疊資訊然後掛掉。所以，我們自己必須先做一次型別檢查。

lox/Interpreter.java，在visitCallExpr介面中新增：

    // 新增部分開始
    if (!(callee instanceof LoxCallable)) {
      throw new RuntimeError(expr.paren,
          "Can only call functions and classes.");
    }
    // 新增部分結束
    LoxCallable function = (LoxCallable)callee;

We still throw an exception, but now we’re throwing our own exception type, one that the interpreter knows to catch and report gracefully.

我們的實現同樣也是丟擲錯誤，但它們能夠被直譯器捕獲並優雅地展示出來。

10 . 1 . 4 Checking arity

10.1.4 檢查元數

The other problem relates to the function’s arity. Arity is the fancy term for the number of arguments a function or operation expects. Unary operators have arity one, binary operators two, etc. With functions, the arity is determined by the number of parameters it declares.

另一個問題與函式的元數有關。元數是一個花哨的術語，指一個函式或操作所期望的引數數量。一元運算子的元數是1，二元運算子是2，等等。對於函式來說，元數由函式宣告的引數數量決定。

fun add(a, b, c) {
  print a + b + c;
}

This function defines three parameters, a, b, and c, so its arity is three and it expects three arguments. So what if you try to call it like this:

這個函式定義了三個形參，a 、b 和c，所以它的元數是3，而且它期望有3個引數。那麼如果你用下面的方式呼叫該函式會怎樣：

add(1, 2, 3, 4); // Too many.
add(1, 2);       // Too few.

Different languages take different approaches to this problem. Of course, most statically typed languages check this at compile time and refuse to compile the code if the argument count doesn’t match the function’s arity. JavaScript discards any extra arguments you pass. If you don’t pass enough, it fills in the missing parameters with the magic sort-of-like-null-but-not-really value undefined. Python is stricter. It raises a runtime error if the argument list is too short or too long.

不同的語言對這個問題採用了不同的方法。當然，大多數靜態型別的語言在編譯時都會檢查這個問題，如果實參與函式元數不匹配，則拒絕編譯程式碼。JavaScript會丟棄你傳遞的所有多餘引數。如果你沒有傳入的引數數量不足，它就會用神奇的與null類似但並不相同的值undefined來填補缺少的引數。Python更嚴格。如果引數列表太短或太長，它會引發一個執行時錯誤。

I think the latter is a better approach. Passing the wrong number of arguments is almost always a bug, and it’s a mistake I do make in practice. Given that, the sooner the implementation draws my attention to it, the better. So for Lox, we’ll take Python’s approach. Before invoking the callable, we check to see if the argument list’s length matches the callable’s arity.

我認為後者是一種更好的方法。傳遞錯誤的引數數量幾乎總是一個錯誤，這也是我在實踐中確實犯的一個錯誤。有鑑於此，語言實現能越早引起使用者的注意就越好。所以對於Lox，我們將採取Python的方法。在執行可呼叫方法之前，我們檢查引數列表的長度是否與可呼叫方法的元數相符。

lox/Interpreter.java，在 visitCallExpr()方法中新增程式碼：