
Sild is a Lisp dialect - luu
http://blog.jfo.click/sild-is-a-lisp-dialect/
======
kaosjester
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?)

~~~
kemitchell
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
Code is _like_ clay, although with varying degrees of grit. One should throw
it around, play, discover. No harm in exploration.

------
DigitalJack
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
If you did not read this already, you may find it quite entertaining:

[http://repository.readscheme.org/ftp/papers/ai-lab-
pubs/AIM-...](http://repository.readscheme.org/ftp/papers/ai-lab-
pubs/AIM-514.pdf)

~~~
DigitalJack
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.

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

------
tyfon
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
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
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
I would also advocate for Racket as a great option and is very active.
[https://racket-lang.org/](https://racket-lang.org/)

~~~
jackdaniel
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?

~~~
baldfat
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.

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

