mark-sweep VS git-from-the-bottom-up

Seconding the Make-A-Lisp and Crafting Interpreters recommendations. This post is also really great, it contains a hard written parser that you may learn from.

You mentioned you want to write your lisp in javascript so you'll be getting quite a lot of functionality for free: memory allocation and garbage collection. Just in case anyone reading is going to write in C, here's an excellent introduction to the topic:

https://journal.stuffwithstuff.com/2013/12/08/babys-first-ga...

Don't forget to spill the registers.

Never forget:

https://journal.stuffwithstuff.com/2013/12/08/babys-first-ga...

> Let me stress here that while this collector is simple, it isn’t a toy.

> There are a ton of optimizations you can build on top of this—in GCs and programming languages, optimization is 90% of the effort—but the core code here is a legitimate real GC.

> It’s very similar to the collectors that were in Ruby and Lua until recently.

> You can ship production code that uses something exactly like this.

> Now go build something awesome!

Bob Nystrom also has a blog, and his articles are really well written (see his post on Pratt parsers / garbage collectors). I'd also recommend going through the source code for Wren, it shares a lot of code with Lox. Despite the deceptive simplicity of the implementation, it (like Lox) is incredibly fast - it's a great way to learn how to build production grade compilers in general.

Bob Nystrom (of Game Programming Patterns, Crafting Interpreters, and dartfmt fame) also wrote a tutorial[1], of a precise as opposed to a conservative garbage collector.

Regarding register scanning, Andreas Kling has made (or at least quoted) an amusing observation[2] that your C runtime already has a primitive to dump all callee-save registers onto the stack: setjmp(). So all you have to do to scan registers is to put a jmp_buf onto the stack, setjmp() to it, then scan the stack normally starting from its address.

[1] https://journal.stuffwithstuff.com/2013/12/08/babys-first-ga...

[2] https://youtu.be/IzB6iTeo8kk

- http://journal.stuffwithstuff.com/2013/12/08/babys-first-gar...

Might not be that hard: https://journal.stuffwithstuff.com/2013/12/08/babys-first-garbage-collector/

Here's a great walk through for how Git works from the bottom up: https://jwiegley.github.io/git-from-the-bottom-up/

It's short, easy to understand and you'll understand HEAD.

Very tangential:

Gerrit also stores some of its configs in a git repo. I was setting up a new instance, but couldn't get Admin permissions because the way my auth front-end didn't play well with the docker image's assumptions.

Gerrit already does a lot of its work via non-standard references. For example, you don't push to a branch, `refs/branches/foo`, you push to a separate `refs/for/foo` namespace that creates the review.

Similarly, Group config is stored in the All-Users git repo [1], but in references created after a UUID, in `refs/groups/UU/UUID`.

I ended up having a to exercise the plumbiest of plumbing commands [2] to create a new commit from scratch (from a tree, from the index, from blobs), to update the group ref to add myself to the Administrators group (this, of course, requires a local shell and permissions on the Gerrit host). It was a great way to exercise what I had learned in Git from the Bottom Up [3]

[1] https://gerrit-review.googlesource.com/Documentation/config-...

[2] https://git-scm.com/book/en/v2/Git-Internals-Git-Objects

[3] https://jwiegley.github.io/git-from-the-bottom-up/

I found Git from the Bottom Up helpful. It is very short as well. Then refer to the official book when you want more detail.

I recently came across "Git from the Bottom Up by John Wiegley" (thanks to Coding Blocks podcast), he has a chapter about rebasing: https://jwiegley.github.io/git-from-the-bottom-up/1-Repository/7-branching-and-the-power-of-rebase.html

You won't have to put your entire life on break in order to understand the fundamentals of git and why it works the way it works. Going through https://jwiegley.github.io/git-from-the-bottom-up/ and really understanding the material will take you a couple of hours at max, but will save you a lot of time in the future.

Wanting to understand things before using them is hardly elitism, not sure why you would think that.

Just like you probably don't want to fix bugs without understand the cause, it's hard to use a tool correctly unless you know how the tool works.