Here's how I did it, I would say it's solid, approachable, and enjoyable:
Go through the first half of Crafting Interpreters [0]. And then try to complete mal - Make a Lisp [1]. That's it. You'll only need these two.
P.S. People also say good things about Build Your Own Lisp [2], but I didn't finish it because I find spending quite some time writing C doesn't make me feel I'm enjoying something elegant.
I can't recommend Build Your Own Lisp - if there's anything particularly "profound" about Lisp, the book misses it by miles. For example, the book claims that adding a new feature requires "syntax, representation, parsing and semantics" [0], whereas one of the nice things about Lisp is that adding most sorts of features doesn't require new syntax or new representations (and "syntax" and "parsing" are fairly redundant).
The example also indicates how the book conflates language and implementation. It's perhaps not the most important thing to know if one is learning how to design and implement programming languages, but unfortunate as CL and Scheme have independent standards; and separating semantics and implementation makes it possible to discuss how differing implementation techniques can be used for the same language. The language implemented also uses dynamic scoping, which is plain weird nowadays.
The C code is of questionable quality, and the author doesn't cover how to improve your chances of writing working C (e.g. using a debugger, testing with sanitizers, etc). This is more of an issue, because the interpreter copies and mutates in a weird way which appears quite easy to mess up, rather than using a garbage collector. The book uses a parser library by the author, so using e.g. the Boehm GC library doesn't seem too bad, but arguably doing your own memory management is more representative of C code that isn't a language implementation. The approach also makes mutation hard to reason about; it's hard to say what a particular update is actually going to affect.
Norvig's Scheme interpreter is a good starting place as well. Using Python as he did someone can do it in a couple of hours. It might take a bit longer if translating to another language at the same time. Someone can get a taste of what's involved and then move on to those more elaborate implementations.
Comments
Here's how I did it, I would say it's solid, approachable, and enjoyable:
Go through the first half of Crafting Interpreters [0]. And then try to complete mal - Make a Lisp [1]. That's it. You'll only need these two.
P.S. People also say good things about Build Your Own Lisp [2], but I didn't finish it because I find spending quite some time writing C doesn't make me feel I'm enjoying something elegant.
[0]: https://craftinginterpreters.com/ [1]: https://github.com/kanaka/mal [2]: https://buildyourownlisp.com/
I can't recommend Build Your Own Lisp - if there's anything particularly "profound" about Lisp, the book misses it by miles. For example, the book claims that adding a new feature requires "syntax, representation, parsing and semantics" [0], whereas one of the nice things about Lisp is that adding most sorts of features doesn't require new syntax or new representations (and "syntax" and "parsing" are fairly redundant).
The example also indicates how the book conflates language and implementation. It's perhaps not the most important thing to know if one is learning how to design and implement programming languages, but unfortunate as CL and Scheme have independent standards; and separating semantics and implementation makes it possible to discuss how differing implementation techniques can be used for the same language. The language implemented also uses dynamic scoping, which is plain weird nowadays.
The C code is of questionable quality, and the author doesn't cover how to improve your chances of writing working C (e.g. using a debugger, testing with sanitizers, etc). This is more of an issue, because the interpreter copies and mutates in a weird way which appears quite easy to mess up, rather than using a garbage collector. The book uses a parser library by the author, so using e.g. the Boehm GC library doesn't seem too bad, but arguably doing your own memory management is more representative of C code that isn't a language implementation. The approach also makes mutation hard to reason about; it's hard to say what a particular update is actually going to affect.
[0] https://buildyourownlisp.com/chapter10_q_expressions
Norvig's Scheme interpreter is a good starting place as well. Using Python as he did someone can do it in a couple of hours. It might take a bit longer if translating to another language at the same time. Someone can get a taste of what's involved and then move on to those more elaborate implementations.
https://norvig.com/lispy.html