Well, if there's anything that might lure me back to Go, it's an escape hatch into another language. :b
Writing an Interpreter in Go: The Paperback Edition
41–50 of 78 posts
Re: Writing an Interpreter in Go: The Paperback Edition
#42Earlier quoted context omitted.
It's a AST walking interpreter, completely built from scratch, including the lexer, the parser, the AST and, of course, the walking/evaluation step.
Cool, asking because the level _past_ the AST walking is where I'm at personally in my learnings. I feel most treatments stop at the AST interpreter step, which is what most people see in school already. I wish there was equally good treatment for everything that comes after that. Type systems, bytecode generation, JIT, optimization phases, etc.
Lisp in Small Pieces is pretty good for that.
Re: Writing an Interpreter in Go: The Paperback Edition
#43Monkey is such a nice language, clean and syntactically lovable. I wonder if the same theory can be applied to make a space indented language like python or nim, I'd like to make one.
Yes, it can. Space indenting is just a small change to the lexer (or overall parser).
Whether those see "\t" or "{" or "begin" it's not really different, it will be the same "BLOCK_STARTS" kind of token.
Re: Writing an Interpreter in Go: The Paperback Edition
#44Monkey is such a nice language, clean and syntactically lovable. I wonder if the same theory can be applied to make a space indented language like python or nim, I'd like to make one.
Yes, it can. Space indenting is just a small change to the lexer (or overall parser). Whether those see "\t" or "{" or "begin" it's not really different, it will be the same "BLOCK_STARTS" kind of token.
I don't think that's true - \t happens at the beginning of every line in a block, often more than once, whereas BLOCK_STARTS and BLOCK_ENDS tokens are pretty easy to track with a stack or whathaveyou.
Re: Writing an Interpreter in Go: The Paperback Edition
#45I've been recently writing a web app in Go - I like the libraries and the tools - but when pausing to write a test script in python I immediately realized Go can't be the right tool for regular CRUD websites. Python is a joy, I love dynamic patterns when writing code. Dicts and strings! It flows...
So, yay escape hatches!
At some point it was going to be a pattern (Java + jruby/ola bini's language)...
Re: Writing an Interpreter in Go: The Paperback Edition
#46I bought this book and I've been using it - but I'm writing the interpreter in Rust instead of Go. I really like it, and I think Go is actually a cool language for this due to its simplicity. I had very little Go experience but the language is drop dead boring, incredibly easy to pick up.
I'd recommend it.
Re: Writing an Interpreter in Go: The Paperback Edition
#47Are createspace books still of a noticeably lesser quality printing than non-print-on-demand books? I saw a few a while (a few years?) ago, and the quality offended me, so I wrote off createspace. I'd be interested to learn that's not the case anymore.
(Just to preemptively clarify: The bad quality I mentioned was most noticeable when compared to a non-POD book. On its own, it looks OK-ish and you might not think anything of it, but when you look at it next to another book you can tell.)
The book itself seems pretty neat though! I'm a PDFs for tech books kind of guy, personally.
Re: Writing an Interpreter in Go: The Paperback Edition
#48Earlier quoted context omitted.
Cool, asking because the level _past_ the AST walking is where I'm at personally in my learnings. I feel most treatments stop at the AST interpreter step, which is what most people see in school already. I wish there was equally good treatment for everything that comes after that. Type systems, bytecode generation, JIT, optimization phases, etc.
Lisp in Small Pieces is pretty good for that.
Cool I'll check it out!
Re: Writing an Interpreter in Go: The Paperback Edition
#49Earlier quoted context omitted.
I recently read a comment (I think it might have been on HN, but I can't find it) that said something like this: if you recently learned/mastered a topic, you're in a far better position to teach that topic than an expert, who's so deep into it, that they can't understand the beginners. I wish I could find the source for this, because it was much better put, but that comment contains the gist of my motivation behind…
The great benefit of experts over I-just-learned-this authors is that experts know how design x or feature y relates to other designs and features not implemented in the given project. In other words, they know a lot more context and can tell whether something that appears totally normal in the project is actually done in an unusual way that has limitations, etc.
That is what is well-done in the Haskell book imho, the combination of someone just learning everything and an experienced programmer
Re: Writing an Interpreter in Go: The Paperback Edition
#50Earlier quoted context omitted.
Yes, it can. Space indenting is just a small change to the lexer (or overall parser). Whether those see "\t" or "{" or "begin" it's not really different, it will be the same "BLOCK_STARTS" kind of token.
I don't think that's true - \t happens at the beginning of every line in a block, often more than once, whereas BLOCK_STARTS and BLOCK_ENDS tokens are pretty easy to track with a stack or whathaveyou.
Of course you'll check the context too. But the same is also true for "{" occurs in many places with different meaning -- in struts, inside text strings, in interfaces (in Go), etc.
Besides it's not the \t that you need to find as a marker for e.g. scope start. Python has "def xxx():" for example, so you see that and you know you're in a function declaration scope, same way function (xxx) { in C works.
After you see that you only need to keep track of \t or " " in the beginning of lines (before any other character) to know whether you're still in the same scope or not. That's why you can't just have arbitrary whitespace count in Python lines, but you need to maintain the same "indent" in the same scope.