Comment by kaosjester | Hacker News Reader

Comment by kaosjester | Hacker News Reader

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.

Reply on news.ycombinator.com