Rochus 2 days ago | next |

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 2 days ago | root | parent |

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 2 days ago | root | parent |

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 2 days ago | root | parent |

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 a day ago | root | parent |

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.