Writing A Compiler In Go.pdfWriting A Compiler In

文件名称: Writing A Compiler In Go.pdf

所属分类: 其它

开发工具:

文件大小: 3mb

下载次数: 0

上传时间: 2019-10-14

提供者: weixin_********

下载 (3mb)

不能下载？报告错误

详细说明：Writing A Compiler In Go is the sequel to Writing An Interpreter In Go. It starts right where the first one stopped, with a fully-working, fully-tested Monkey interpreter in hand, connecting both books seamlessly, ready to build a compiler and a virtual machine for Monkey. In this book, we use the codebase (included in the book!) from the first part and extend it. We take the lexer, the parser, the AST, the REPL and the object system and use them to build a new, faster implementation of Monkey, right next to the tree-walking evaluator we built in the first book. The approach is unchanged, too. Working, tested code is the focus, we build everything from scratch, do baby steps, write tests firsts, use no 3rd-party-libraries and see and understand how all the pieces fit together. It's a continuation in prose and in code.Writing A Compiler In go Acknowledgments Introduction Evolving monkey. se this book Compilers virtual machines compilers Virtual and real machines What Were Going to Do, or: the Duality of VM and Compiler Hello bytecode First Instructions adding on the stack Hooking up the rePL Compiling expressions leaning _up the Stack InfIx expressions Booleans Comparison Operators Prefix expressions Conditionals Jumps Compiling conditionals Executing Jumps Welcome Back, Null pepIn g Track of Names The plan Compiling bindings Adding globals to the vm String, Array and hash String Array Hash Adding the index operator Functions Dipping our Toes: a Simple function ocal Bindings Arguments Built-in functions Making the Change easy Making the change: the plan A New Scope for Built-in Functions Executing built-in functions Closures e problem e plan Everythings a closure Compiling and resolving free variables Creating real closures at run time Taking Time Resources Feedback Changelog Acknowledgments I started writing this book one month after my daughter was born and finished shortly after her first birthday. Or, in other words this book wouldnt exist without the help of my wife. While our baby grew into the wonderful girl she is now and rightfully demanded the attention she deserves, my wife always created time and room for me to write. I couldnt have written this book without her steady support and unwavering faith in me. Thank you! Thanks to Christian for supporting me from the start again with an open ear and encouragement. Thanks to Ricardo for providing invaluable, in-depth feedback and expertise. Thanks to Yoji for his diligence and attention to detail. Thanks to all the other beta- readers for helping to make this book better Introduction It might not be the most polite thing to do, but let's start with a lie: the prequel to this book, Writing An Interpreter In Go, was much more successful than I ever imagined it would be. Yes, thats a lie. Of course, I imagined its success. The name on the top of bestseller lists, me showered with praise and admiration, invited to fancy events, strangers walking up to me in the street, wanting to get their copy signed- who wouldnt imagine that when writing a book about a programming language called Monkey But, now, in all seriousness, the truth: I really didnt expect the book to be as successful as it was Sure, I had a feeling that some people might enjoy it. mainly because it's the book i myself wanted to read, but couldnt find. And on my fruitless search i saw other people looking for the exact same thing: a book about interpreters that is easy to understand, doesnt take shortcuts and puts runnable and tested code front and center ifi could write a book like that. i thought, there might just be a chance that others would enjoy it, too But enough about my imagination, here's what actually happened readers really enjoyed what I wrote. They not only bought and read the book, but sent me emails to thank me for writing it. They wrote blog posts about how much they enjoyed it. They shared it on social networks and upvoted it They played around with the code, tweaked it, extended it and shared it on Github. They even helped to fix errors in it. Imagine that! They sent me fixes for my mistakes, all the while saying sorry for finding them e. pparently, they couldn't imagine how thankful I was for every suggestion nd correction Then, after reading one email in which a reader asked for more, something in me clicked. What lived in the back of my mind as an idea turned into an obligation: I have to write the second part Note that i didn't just write"a second part,, but the second part". That's because the first book was born out of a compromise When I set out to write Writing An Interpreter In go the idea was not to follow it up with a sequel, but to only write a single book. That changed, though, when I realized that the final book would be too long. I never wanted to write something that scares people off with its size. And even if I did, completing the book would probably take so long that I would have most likely given up long before That led me to a compromise. Instead of writing about building a tree- walking interpreter and turning it into a virtual machine, I would only write about the tree-walking part. That turned into Writing An Interpreter In go and what you're reading now is the sequel i have al ways wanted to write But what exactly does sequel mean here? By now you know that this book doesn't start with " Decades after the events in the first book in another galaxy, where the name Monkey has no mcaning. No, this book is mcant to seamlessly connect to its predecessor. It's the same approach, the e same programming language, the same tools and the codebase that we left at the end of the first book The idea is simple: we pick up where we left off and continue our work on Monkey. This is not only a successor to the previous book, but also a sequel to Monkey, the next step in its evolution. Before we can see what that looks like, though, we need look back, to refresh our memory of Monkey Evolving Monkey The past and present In Writing An interpreter In Go we built an interpreter for the programming language MonkeyMonkey was invented with one purpose in mind: to be built from scratch in Writing an Interpreter In go and by its readers. Its only official implementation is contained in Writing An Interpreter In go, although many unofficial ones, built by readers in a variety of languages, are floating around the internet In case you forgot what Monkey looks like, here is a small snippet that tries to cram as much of monkey's features into as few lines as possible let name ev i 1e七 let inspirations =["Scheme","Lisp","Javascript",Clojure] let bock itil Writing A Compiler In Go author" :"Thorsten 3all "prequel":"Writing An Interpreter In Go let let title book["title] let autho puts(author +七it1e); (b○ok //=> prints: Thorsten Bal1 -Writing A Compiler In Go 1e七fib fn(x) if y else i if return 1 y else (x-1)+f1 let map= fn(arr, f)I let i te cumul ated)t if (len(arr)== 0) accumulated y else I ter(rest(ar=), push(accumulated, f(first(arr))))i iter(arr [ let nuke 4-1,2*2,2-3 map(numbers, fibonacci //=> returns:(77,23 Translated into a list of features, we can say that Monkey supports integers booleans strings ● arrays hashes prefix-, infix-and index operators conditionals global and local bindings first-class functions return statements e closures Quite a list, huh? And we built all of these into our Monkey interpreter ourselves and- most importantly! -we built them from scratch, without the use of any third-party tools or libraries We started out by building the lexer that turns strings entered into the rePl into tokens. The lexer is defined in the lexer package and the tokens it generates can be found in the token package After that, we built the parser, a top-down recursive-descent parser(often called a Pratt parser) that turns the tokens into an abstract syntax tree, which is abbreviated to AST. The nodes of the ast are defined in the ast package and the parser itself can be found in the parser package After it went through the parser, a Monkey program is then represented in memory as a tree and the next step is to evaluate it. In order to do that we built an evaluator. That's another name for a function called eval, defined In the evaluator package. Eval recursively walks down the Ast and evaluates it, using the object system we defined in the object package to produce values. It would, for example, turn an AST node representing 1+ 2 into an object Integer(value: 31. With that, the life cycle of Monkey code would be complete and the result printed to the repl This chain of transformations-from strings to tokens, from tokens to a tree and from a tree to object Object -is visible from start to end in the main loop of the monkey RePl we built // repl/repl. go package repl func Start(in io. Rcadcr, out io. Writer) scanner : bufio New Scanner(in env : =object NewE- vironment ( fmt Printf(PROMPT) scanned scanner Scan( if! scanned i eturn line : scanner Text O 1 lexer. New(line) p:- parser. New(1) program = p. arseProgram( if lcn(pErrors())!0 I printParserErrors(out, pErrors()) continue evaluated :=evaluator Eval(program, env) if evaluated ! nil i ioWritestring(out, evaluated. Inspect()) io. WriteScring(out, \n") That's where we left monkey at the end of the previous book And then, half a year later, the The Lost Chapter: A Macro System For Monkey resurfaced and told readers how to get monkey to program itself

(系统自动生成,下载前可以参看下载内容)