Clasp: A Common Lisp implementation using LLVM for compilation to native code | Hacker News Reader

Clasp: A Common Lisp implementation using LLVM for compilation to native code

github.com

123 pointsducktective18 comments

I find the story behind it, from molecules to GPUs, fascinating: https://www.youtube.com/watch?v=mbdXeRBbgDM

Wow, what a great story.

I'm just trying to visualize an early Knuth giving this talk about how wanting to write a book found him down the TeX rabbit hole.

I also liked this line: "My first Common Lisp program was a compiler for Common Lisp". Indeed, jumping in with both feet.

"Building takes a lot of resources. In parallel mode (:parallel-build t in config.sexp) you need more than 8 GB of RAM and it will be 1-2 hours build time. If you have 8 GB of RAM you can turn off the parallel build which will then run for a day or so."

Ouch....

I was wondering about that, too. Assuming that Clasp doesn't need a Lisp for bootstrapping [1], would bootstrapping without a Lisp take comparable build times for other Common Lisp systems?

[1] It would be nice if the readme explicitly listed build dependencies.

Could you compile to wasm, or is there extra work involved in making that possible? One reason I shied away from learning Common Lisp is that none of the popular implementations seem to run in the browser.

There are efforts, but it's slow going so far. You don't get tail recursion, which isn't required for CL but nice to have, and the condition system is a little too flexible to be easily instantiated with the primitives you're given.

And for reasons that aren’t clear to me, the WASM standards people appear outright hostile to changes that would make it easier.

As frustrating as it is, I can see how a project which occupies a bloody battleground of a common space would develop an allergy for changes which aren't universally desired. Seems like a simple proper subroutine jump would be a nice addition which no one would have to use unless they wanted to, but there are lots of things like that and eventually one of them would have something dumb go wrong.

Have heard of Clasp a few times, looks like they hit 1.0.0 back in spring which is cool. May be time to finally give it a try

Benchmarks here from 2020 https://github.com/clasp-developers/clasp/wiki/Benchmark-Res...

It’s remarkable how SBCL has basically surpassed its parent CMUCL. I recall when the project was first starting a number of performance optimizations were sacrificed because the code was hard to understand and would only compile with a sufficiently recent version of CMUCL. Last I knew you could compile SBCl from source using an interpreter like CLISP.

How is the performance story coming on this, anyone know?

They have benchmarks comparing different CL implementations

https://github.com/clasp-developers/clasp/wiki/Benchmark-Res...

https://github.com/clasp-developers/clasp/wiki/Relative-Comp...

2020 though

Change the name to have a Hamming distance of more than 1 from clisp. Like it's a cool language but I think it's very useable, call it something that can't be as easily confused. It's too sneaky to say Clasp instead of Clisp.

Clask, for instance. Two different letters.

Note that the name of the language is not generally abbreviated this way. But there's another implementation called CLISP.

Clask sounds like a Flask-inspired web framework for Common Lisp to me. [Googled it] Yep, "something like Flask", but in C++, not in Lisp.

IIUC Clasp is made from clang + lisp because it uses clang for the implementation.

Clasp is actually a word, and CLISP is part of GNU now so they should probably rename it something childish and cringe inducing like LURP, which is a recursive acronym for LERP: Universal REPL Programming or something.

Reply on news.ycombinator.com