I'm pretty familiar with various approaches to implementing Lisp / Scheme, and seeing projects like this is almost heartbreaking. What's been done here (which I might call the "mechanical" approach to implementing Scheme) seems to attempt to emulate an underlying LISP machine instead of emulating the language itself, and that's fundamentally problematic because, for the most part, that's the wrong abstract machine. If the author took the time to work through the first four or five chapters of SICP, they'd have the knowledge to construct a much cleaner machine (based on CEK) that would, ultimately, end up far more performant and faithful to the end-goal semantics. All of this mucking about with allocation and free-cells for expressions and the like is orthogonal to building a LISP interpreter in C. (And, if the author is really interested in that sort of thing, the LISP machine is well-documented.)

If anyone else is interested in starting a project like this, getting down and dirty, I'd urge you to start with the first part of SICP and then move into Dybvig's dissertation (at http://agl.cs.unm.edu/~williams/cs491/three-imp.pdf), which directly and plainly describes multiple approaches to producing efficient, reliable Scheme implementations.

(Also, why doesn't this link to the Github page instead of the blog?)

I hear you on prior art. But for who does your heart break? What is here that you'd like to discourage?

Those interested in getting down and dirty are highly unlikely to suspend that impulse for MIT's old intro text and a dissertation from 1987. The author apparently rewrote this three times; so says README. Nothing lofty or pristine, precious as it may be, slots in for that experience.

A state of the art impl it isn't, but we all know where to find those. But I suspect the state of the author's art has improved markedly by the exercise. Maybe if we encourage him, he'll rewrite a few more times, and come up with something wonderful and strange. Maybe it will be a Scheme. Maybe it won't.

Code is _like_ clay, although with varying degrees of grit. One should throw it around, play, discover. No harm in exploration.

Author here. Thanks for this comment, as I said in the post this is exactly the kind of feedback I want.

I had read the first half or so of SICP before I started this project, but can't say that I really "got" it. Certainly a lot of lightbulbs had gone off, but I still had the feeling I was missing something. This project (and the two attempts that preceded it) was started with the knowledge that I didn't really know what the hell I was doing, at all. Each iteration got a little bit better and filled in more and more gaps. This is the first one that I can say is "done" in any meaningful sense, though there is a lot still to do if I ever wanted to make it useful or even reasonably performant (GC, TCO, etc...) . I fully intend to explore the concepts involved whether by implementing them into this language or by starting from scratch again, which I am definitely not above!

I agree that a lot of the mucking in this program isn't directly related to building a good scheme/lisp, but it was definitely relevant to my other main goal of becoming more proficient in C. I can report that that was a real success; I learned more about C from this than almost anything else I had done prior.

I will read that paper with interest, thank you for the link!

Great comment! I didn't know about Dybvig's dissertation. Did the string-based model ever get used?

(The blog was what got submitted, tells the story of the project, and links to the Github page, so I think it's fine.)

CEK: https://en.wikipedia.org/wiki/CEK (disambiguation)

I'm going to go with: Eastern Khumi language (ISO 639-3: cek), Kukish language of Burma

https://en.wikipedia.org/wiki/Eastern_Khumi_language

Kent Dybvig thesis is really fun to read. I tried before but my lisp-fu was too weak.

I love projects like this. I'm a chip designer, and I feel very comfortable at that level, and low level programming like assembly. I used to be comfortable in C back in the day.

These days I feel like I don't have time for the nitty gritty details of programming anymore and only work in Clojure (with occasional forays into other languages to see "how goes the world").

I have a large intellectual gap between logic gates, assembly and a high level language like a lisp. I'd really like to attempt a project like this some day, but I mostly feel like those days are behind me.

If you did not read this already, you may find it quite entertaining:

http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-...

Now that's interesting. I believe I did come across this years ago, possibly before I started with clojure... I'll have to go through it again and see if I get more out of it now that I've been working with a lisp for a while.

Out of curiosity, do you use Clojure in your position as chip designer or are these aspects unrelated (i.e. is your usage of Clojure recreational)?

It's mostly recreational. I use it for my day job when I can though. I've got one internal project that makes heavy use of Clojure, but I'm sure I'll have to port it to python before releasing to the department just to make it less "scary" to the other hardware people.

I did a test port of part of the program early on. That was pretty eye opening. I hadn't realized how used to Clojure's immutable data structures I had become. That and working in a mostly side-effect free fashion.

I was transliterating to python, so I ended up doing some goofy things to keep my functions from having side effects on all the data structures passed in. Writing from scratch would have been fine, but I don't want to take the time. Plus someone else can take the transliterated version and re-write in a pythonic way.

Recommendation: please go read Simon Peyton-Jones' "The Implementation of Functional Programming Languages". It's highly accessible, assumes little prior knowledge, and reads pretty quickly. Its focus is on non-strictly evaluated systems like Miranda and Haskell, but go read it anyway.

(EDIT: Link to free copy from the author: http://research.microsoft.com/en-us/um/people/simonpj/papers...)

I was about to write that sild is herring in Norwegian, but then I saw you had it in the github repo (but Danish) :)

Cool project, I'll have a look at it!

I want to learn some Lisp and clojure later after I finish up with some JS (which I'm relearning) Would this be good in your opinion ?

Common Lisp is an ancestor of LISP and is more active every year. It puts its eggs in a "pragmatism" basket. Very good introductory book "Practical Common Lisp" by Peter Seibel[1].

Scheme is a lisp made from scratch. It bets on clarity, functional programming, minimalism and elegance. There is a perfect introductory book "Structure and Interpretation of Computer Programs"[2] which is a worth read even if you don't want to program in Scheme in the future.

I haven't used Clojure, but from what I've heard it's a modern functional lisp which bets on parallelism and interop between environments.

There are more lisp dialects like PicoLisp, but I know about them even less than about the Clojure, so you'll have to investigate options by yourself. I'm a Common Lisp programmer, so I can recommend that – "the profound enlightenment experience", as Eric Raymond put it.

[1] http://www.gigamonkeys.com/book/

[2] https://www.mitpress.mit.edu/sicp/full-text/book/book.html

I would also advocate for Racket as a great option and is very active. https://racket-lang.org/

I know that Racket is so much more right now, but I've put it in the "Scheme box" in my mind. Is it technically incorrect to treat Racket as Scheme on batteries?

Absolutely. It really is "A Programing Language for Programing Languages" It is an excellent environment for defining well contained scheme subsets and other languages and using them seamlessly. But Racket has become its own beast and is very different from Scheme now and the reason for the name change from Scheme PTL.

In a lot of ways, Clojure feels like the python of lisps. It pretends (very well I must say) to be dead simple but lets you get into "the nitty gritty details of programming" as another commenter put it, if you need to/know how.

> Common Lisp is an ancestor of LISP

You probably mean a descendant

yeah, my mistake. Thanks :)

> sild is herring in Norwegian

And in English!

For handling function call frames you may consider compiling your Lisp code a bit before interpretation - do an explicit lambda lifting with an explicit closure allocation. This way you'd be free to kill each frame after a call.

Thanks for this suggestion! I had come across this concept and it's one of the strategies I'm considering trying out to solve that problem.

You can even implement this part of a compilation in your Lisp itself, with a little bit of a bootstrap.