Why are Lisp / Scheme interpreters so complicated?

[JonathanWilbur]

This isn't particular to Steel, and I am not saying Steel is bad or anything. I have never used it, in fact. I have often heard that Lisp is a sort of "Maxwell's Equations" of code, yet I have looked at the codebases of Lisp interpreters, such as the famous Steel Bank Common Lisp, and their source is absolutely huge. When I understand the syntax and behavior of Lisp, it seems like it should be a one-file-of-c type program to implement an interpreter. What makes it require so much code?

[mattwparas]

Depends how big your one file of C is 😄

In general you're more or less right, you can make a relatively simple interpreter with a small amount of code. There are many examples of small lisp interpreters. But like all things, the devil is in the details, and if you want to get something with lots of features that is also fast, you tend to end up having a lot of code.

In this regard, I'd wager lisp/scheme/whatever isn't much different from any other language - once you end up with bytecode instead of a tree walker, you then need a VM, and making VMs fast requires some effort. You then probably want to have a lot of built in functions that are fast - those are often what take up a lot of code as well.

The scheme/lisp particular difficulties usually revolve around macros (in particular, hygienic macros can end up requiring more work) and tail calls. Most of the rest of the stuff is fairly standard across languages - you end up just having a lot of code around to do lots of things, while also making those things fast

[kskarthik]

I feel amazed how a programming language is programmed in general 😄

[JonathanWilbur]

I see, thank you!