Crafting Interpreters
papers-we-love
Our great sponsors
Crafting Interpreters | papers-we-love | |
---|---|---|
45 | 69 | |
7,995 | 82,686 | |
- | 1.9% | |
0.0 | 5.4 | |
6 days ago | 6 months ago | |
HTML | Shell | |
GNU General Public License v3.0 or later | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Crafting Interpreters
- Crafting Interpreters
-
The Top 10 GitHub Repositories Making Waves 🌊📊
Build an Interpreter (Chapter 14 on is written in C)
-
Writing a Debugger from Scratch: Breakpoints
I’m guessing you’ll have to work with the scopes in the resolver:
https://github.com/munificent/craftinginterpreters/blob/mast...
I was asking this myself this while reading the book "Crafting Interpreters". I posted a few resources I found on an issue about implementing debuggers [] although honestly I still haven't gotten down to read all of them (or to implement a debugger! :-/).
--
: https://github.com/munificent/craftinginterpreters/issues/92...
-
loxcraft: a compiler, language server, and online playground for the Lox programming language
Better open an issue/request wiki edit at https://github.com/munificent/craftinginterpreters/wiki/Lox-implementations
- Gigachad Ken Thomson.
-
Show HN: Yaksha Programming Language
I'm late to the party, but I want to say thank you for sharing this. It's inspiring to look at how much you've built and (hopefully) enjoyed the process of building! I'm loving everything -- your site, your language design, your docs, your builtin libraries, your dev tools. Beyond impressive. People like you are the ones who make HN one of my best places on the internet.
For context on where I'm coming from, about two weeks ago I picked up Crafting Interpreters [1] for fun. I'm finding your clear-yet-concise Compiler internals [2] to be particularly compelling reading, and jumping back and forth between those "how this all works" docs and the live example of this language you actually built do a WASM-compiled tree-blowing-in-the-wind animation is just... just wow. So freaking cool!
I also enjoyed reading the comment thread that inspired you to start on Yaksha and seeing how this project has a wholesome start as inspiration-by-programming-hero. I hope you recognize that a few years later you've now ascended from inspiree to inspirer. I also hope you're still having tons of fun building out Yaksha!
[1] https://www.craftinginterpreters.com/
[2] https://yakshalang.github.io/documentation.html#compiler-int...
- Keeping track of returned and break-ed values between code blocks
-
How do you start your own programming language?
There are books which will talk you through the process. Crafting Interpreters is highly spoken of; I used Writing an Interpreter in Go, because I like Go. Then there's Compilers: Principles, Techniques, and Tools (the "Dragon Book"). This is considered heavy, but a classic, it's been around since '86.
-
Designing a new language
I cannot recommend Crafting Interpreters by Robert Nystrom enough, it covers a lot of the stuff you need to know, completely for free.
papers-we-love
-
The Top 10 GitHub Repositories Making Waves 🌊📊
Github | Website
Papers We Love (PWL) is a community built around reading, discussing and learning more about academic computer science papers. This repository serves as a directory of some of the best papers the community can find, bringing together documents scattered across the web. You can also visit the Papers We Love site for more info.
- What led you to use Linux as your daily driver?
-
We have used too many levels of abstractions and now the future looks bleak
You might find the paper Out of the Tar Pit interesting if you haven't already read it: https://github.com/papers-we-love/papers-we-love/blob/main/d...
The ideas and approaches you talk about evoked some of the concepts from that paper for me. It talks a lot about separating accidental complexity and infrastructure so you can focus only on what is essential to define your solutions.
-
John McCarthy’s collection of numerical facts for use in elisp programs
Sure he was expecting a practical language and was designing one. Lisp was from day zero a project to implement a real programming language for a computer.
Earlier he experimented with IPL and also list processing programming on Fortran. The plan was to implement a Lisp compiler. At first the Lisp code McCarthy was experimenting with, was manually translated to machine code.
Then came up the idea to use EVAL as a base for an interpreter, which was implemented by manually translating the Lisp code to machine language. Around 1962 then a compiler followed.
https://github.com/papers-we-love/papers-we-love/blob/main/c...
-
Python: Just Write SQL
I'm in a 4th camp: we should be writing our applications against a relational data model and _not_ marshaling query results into and out of Objects at all.
Elaborations on this approach:
- https://github.com/papers-we-love/papers-we-love/blob/main/d...
-
Ask HN: Incremental View Maintenance for SQLite?
The short ask: Anyone know of any projects that bring incremental view maintenance to SQLite?
The why:
Applications are usually read heavy. It is a sad state of affairs that, for these kinds of apps, we don't put more work on the write path to allow reads to benefit.
Would the whole No-SQL movement ever even have been a thing if relational databases had great support for materialized views that updated incrementally? I'd like to think not.
And more context:
I'm working to push the state of "functional relational programming" [1], [2] further forward. Materialized views with incremental updates are key to this. Bringing them to SQLite so they can be leveraged one the frontend would solve this whole quagmire of "state management libraries." I've been solving the data-sync problem in SQLite (https://vlcn.io/) and this piece is one of the next logical steps.
If nobody knows of an existing solution, would love to collaborate with someone on creating it.
[1] - https://github.com/papers-we-love/papers-we-love/blob/main/design/out-of-the-tar-pit.pdf
-
I think Zig is hard but worth it
However, f and g are interchangeable anywhere else (this is not actually true because their addresses can be obtained and compared; showing that a C-like language retains its referential transparency despite the existence of so-called l-values was the point of what I think is the first paper to introduce the notion referential transparency to the study of programming languages: https://github.com/papers-we-love/papers-we-love/blob/main/l...)
-
Functional relational programming model in Clojure(Script)
This idea was raised years before Martin Fowler blogged about it: https://github.com/papers-we-love/papers-we-love/blob/main/d...
-
Which is the most interesting Computer Science research paper that you have read?
FTR Papers We Love is a curated list of papers the community loves. Also contains a bunch of other sources for papers worth reading.
What are some alternatives?
git-internals-pdf - PDF on Git Internals
You-Dont-Know-JS - A book series on JavaScript. @YDKJS on twitter.
tinyrenderer - A brief computer graphics / rendering course
paip-lisp - Lisp code for the textbook "Paradigms of Artificial Intelligence Programming"
CppCoreGuidelines - The C++ Core Guidelines are a set of tried-and-true guidelines, rules, and best practices about coding in C++
30-days-of-elixir - A walk through the Elixir language in 30 exercises.
clojure-style-guide - A community coding style guide for the Clojure programming language
project-based-learning - Curated list of project-based tutorials
web-dev-golang-anti-textbook - Learn how to write webapps without a framework in Go.
pyright-python - Python command line wrapper for pyright, a static type checker
lisp - Toy Lisp 1.5 interpreter
Flowgorithm-macOS - Flowgorithm for Mac OS