HN Explorer

Show HN: A Common Lisp implementation in development (savannah.nongnu.org)

17 points by andreamonaco ↗ HN
I've been working on this for a couple years.

Implementation of the standard is still not complete, but in my opinion breakpoints and stepping work quite well! Support for loading systems with ASDF is near.

Let me know if you like it! Support on Patreon or Liberapay is much appreciated

10 comments

[ 2.7 ms ] story [ 35.2 ms ] thread
basementcat
What are the pros and cons of this vs other Common Lisp implementations such as clisp and others?
andreamonaco
My implementation builds very easily, like 20 seconds on my laptop. More importantly, debugging and stepping work very well
Rochus
> like 20 seconds on my laptop

About the same time on my old EliteBook 2530p.

Rochus
The implementation looks easier to handle than e.g. ECL or CLISP, cool.

Do you have an estimate how complete your implementation is?

How does the performance compare with e.g. ECL or CLISP?

Did you run conformity tests, e.g. with https://gitlab.common-lisp.net/ansi-test/ansi-test?

andreamonaco
Based on the number of symbols implemented, I'd say that more than three quarters of the standard are done, almost enough to load a system with ASDF.

Performance seems on par with clisp, but important optimizations are yet to be done, for example my program is still single-threaded

Rochus
That's amazing, thanks.

Can you please share more background information about the project, in particular why you wanted to take on this huge challenge, and why you didn't just start from an existing implementation, and why you chose C as the implementation language? Do you assume that you can still use the same GC with the addition of multi-threading?

andreamonaco
Well, I like and use SBCL and ECL, but I was curious if I could make something as big on my own. I was also curious about implementing that GC algorithm that I found in literature; I'm pretty satisfied with the result, though I don't exclude providing an alternative more classic GC as an option in the future. I chose C because I love its clean design, and the portability of C89 can't really be matched.

About multi-threading: I still haven't thought about it much, but I'm optimistic; according to the paper, the algorithm is quite amenable to concurrency, since each object carries local information (the two refcounts), so some collection doesn't need global state. I agree, but we'll have to wait to see it in action

Rochus
The size is indeed impressive (31 kSLOC, compared to e.g. Lua 5.1 with 13 kSLOC). I will have a closer look at the code. Maybe I can transpile it to my Luon language and run it on LuaJIT.