Writing a Lisp interpreter an Lisp is cheating. You get the reader and garbage collector for free.
Don't get me wrong, it's fun. But if you want to learn about things, writing a Lisp interpreter in some (relatively speaking) low-level language like C/C++ is a much more satisfying experience. And then write a Lisp interpreter to run on your Lisp.
Bonus points if you get to optimize tail recursion. (I didn't, but I didn't try to, so I don't consider it a failure.)
Writing a Lisp interpreter in C/C++ is cheating. You get readable code and a standard library for free. Don't get me wrong, it's surely fun, but if you really wanna learn about things, you need to write a Lisp interpreter in Assembly. It's a much more satisfying experience.
Jokes aside, I'm hoping the author continues to feel free to spend their time implementing whatever idea they come across that is interesting. Sure, it's not as advanced as implementing something in C/C++, but maybe the authors goal was just to understand their preferred lisp (Clojure) better, rather than trying to understand C/C++ better?
> Bonus points if you get to optimize tail recursion. (I didn't, but I didn't try to, so I don't consider it a failure.)
Is this as complicated as people put it? I've never implemented my own lisp, but MAL (https://github.com/kanaka/mal) makes it seem like a relatively easy step in the process.
Note that the BLC self-interpreter mentioned in another comment does not get the reader for free, having to parse lambda terms (including numbers written in unary) from a stream of bits. It does get a garbage collector for free.
It is accompanied by a BLC interpreter written in 25 lines of obfuscated C that does include a reference counting garbage collector.
Is there anything I can read in order to discover the general principle in creating a tail-recursion optimizer? I know how to ensure it's triggered, but not necessarily how to write one...
Also see Make a Lisp - a build a lisp project that has a specific section on tail recursion [0]. When I went through the MAL process, TCO was actually one of the more straight forward sections (compared with say macros). The basic idea is quite simple - take your eval function and wrap it's body in a loop. For several of the special forms, instead of recursing into eval, rebind eval's arguments and go back round the loop. Forms where something is done after the call to eval still have to recurse, but they are actually in the minority.
