5 ms·

Sild is a Lisp dialect

64 points by luu 10y ago

kaosjester 10y ago
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 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?)
- dang 10y ago
  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.)
- kemitchell 10y ago
  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.
  - sitkack 10y ago
    Code is _like_ clay, although with varying degrees of grit. One should throw it around, play, discover. No harm in exploration.
- igravious 10y ago
  CEK: https://en.wikipedia.org/wiki/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 https://en.wikipedia.org/wiki/Eastern_Khumi_language
- jfo 10y ago
  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!
- agumonkey 10y ago
  Kent Dybvig thesis is really fun to read. I tried before but my lisp-fu was too weak.
DigitalJack 10y ago
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.
- sklogic 10y ago
  If you did not read this already, you may find it quite entertaining: http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-514.pdf http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-...
  - DigitalJack 10y ago
    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.
- _pmf_ 10y ago
  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)?
  - DigitalJack 10y ago
    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.
tyfon 10y ago
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!
- xufi 10y ago
  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 ?
  - jackdaniel 10y ago
    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/ http://www.gigamonkeys.com/book/ [2] https://www.mitpress.mit.edu/sicp/full-text/book/book.html https://www.mitpress.mit.edu/sicp/full-text/book/book.html
    - baldfat 10y ago
      I would also advocate for Racket as a great option and is very active. https://racket-lang.org/ https://racket-lang.org/
      - jackdaniel 10y ago
        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?
sklogic 10y ago
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.
- jfo 10y ago
  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.
  - sklogic 10y ago
    You can even implement this part of a compilation in your Lisp itself, with a little bit of a bootstrap.
pklausler 10y ago
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/slpj-book-1987/ http://research.microsoft.com/en-us/um/people/simonpj/papers...)

64 points by luu 10y ago

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 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?)

dang 10y ago
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.)
kemitchell 10y ago
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.
- sitkack 10y ago
  Code is _like_ clay, although with varying degrees of grit. One should throw it around, play, discover. No harm in exploration.
igravious 10y ago
CEK: https://en.wikipedia.org/wiki/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 https://en.wikipedia.org/wiki/Eastern_Khumi_language
jfo 10y ago
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!
agumonkey 10y ago
Kent Dybvig thesis is really fun to read. I tried before but my lisp-fu was too weak.

DigitalJack 10y ago

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.

sklogic 10y ago
If you did not read this already, you may find it quite entertaining: http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-514.pdf http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-...
- DigitalJack 10y ago
  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.
_pmf_ 10y ago
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)?
- DigitalJack 10y ago
  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.

tyfon 10y ago

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!

xufi 10y ago
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 ?
- jackdaniel 10y ago
  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/ http://www.gigamonkeys.com/book/ [2] https://www.mitpress.mit.edu/sicp/full-text/book/book.html https://www.mitpress.mit.edu/sicp/full-text/book/book.html
  - baldfat 10y ago
    I would also advocate for Racket as a great option and is very active. https://racket-lang.org/ https://racket-lang.org/
    - jackdaniel 10y ago
      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?

sklogic 10y ago

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.

jfo 10y ago
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.
- sklogic 10y ago
  You can even implement this part of a compilation in your Lisp itself, with a little bit of a bootstrap.

pklausler 10y ago

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/slpj-book-1987/ http://research.microsoft.com/en-us/um/people/simonpj/papers...)