If you are interested in this, you might also be interested to learn that I also got clojure running on SBCL via OpenLDK. See https://github.com/atgreen/cl-clojure.
Regarding LLM-usage, the bulk of OpenLDK was written without the use of LLMs. But recently I let Claude loose on the code to fix a few remaining problems blocking kawa. Claude also upleveled the Java support from Java 8 to Java 21.
The OpenLDK is very interesting - it looks like it “compiles” to the vintage procedural dialect within CL (eg TAGBODY etc.) I wonder if someone’s ever bypassed the “procedural Lisp” level and just used a CL implementation’s internal assembler interactively, though. (IIRC both SBCL and CCL expose theirs.)
TAGBODY/GO are broadly used in advanced Lisp macros. If you expand a non-trivial extended LOOP invocation you'd likely see some.
If you compile to an implemenation's assembler (even where that possible) you don't really compile into Lisp anymore. And really the Lisp compiler is going to do a better job at generating machine code.
RMS itself being a diehard Scheme and Elisp user said that he found Java elegant over C. This was OFC long before Go and when C++ was king in the 90's.
On Java itself, when CLOS, a dog-ancient system for Common Lisp it's enough to support the Java class/method/object system by itself tells a lot on how great CL can be, even with SBCL which is the top tier free (as in freedom) interpreter/compiler out there.
On performance, well, who knows; remember that PyPy itself back in the day was written in Python itself and it ran things much faster than the vanilla Python interpreter.
The Computer Abstractions book/course for Scheme had some kind of VM written in Java where you had to write an assembler in Scheme as the final 'biggie' project.
I had to check if the creator is Polish, as "ciekawa" means "interesting". But apparently, just a coincidence.
Coincidentally, Chiikawa is a very popular anime character in Japan.
https://en.wikipedia.org/wiki/Chiikawa
It's a portmanteau of "Chiisai" (small) and "Kawaii" (cute).
If you are interested in this, you might also be interested to learn that I also got clojure running on SBCL via OpenLDK. See https://github.com/atgreen/cl-clojure.
Regarding LLM-usage, the bulk of OpenLDK was written without the use of LLMs. But recently I let Claude loose on the code to fix a few remaining problems blocking kawa. Claude also upleveled the Java support from Java 8 to Java 21.
I wrote a couple of blog entries related to this work that might be of interest. One was around how I had to use the MOP to optimize method dispatch in CLOS for clojure: https://atgreen.github.io/repl-yell/posts/clos-mop-dispatch/
Perhaps someone could port Arc to Kawa! Then the whole contraption could run HN on SBCL in a roundabout way.
The OpenLDK is very interesting - it looks like it “compiles” to the vintage procedural dialect within CL (eg TAGBODY etc.) I wonder if someone’s ever bypassed the “procedural Lisp” level and just used a CL implementation’s internal assembler interactively, though. (IIRC both SBCL and CCL expose theirs.)
TAGBODY/GO are broadly used in advanced Lisp macros. If you expand a non-trivial extended LOOP invocation you'd likely see some.
If you compile to an implemenation's assembler (even where that possible) you don't really compile into Lisp anymore. And really the Lisp compiler is going to do a better job at generating machine code.
I haven't tried it, but the description sounds delightfully perverse. And an LLM (Claude) cannot be embarrassed by perverting Lisp/Scheme with Java.
JVM, not Java. And there's Clojure already in that space.
Why should it?
"We were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp." -- Guy Steele
RMS itself being a diehard Scheme and Elisp user said that he found Java elegant over C. This was OFC long before Go and when C++ was king in the 90's.
On Java itself, when CLOS, a dog-ancient system for Common Lisp it's enough to support the Java class/method/object system by itself tells a lot on how great CL can be, even with SBCL which is the top tier free (as in freedom) interpreter/compiler out there.
On performance, well, who knows; remember that PyPy itself back in the day was written in Python itself and it ran things much faster than the vanilla Python interpreter.
The Computer Abstractions book/course for Scheme had some kind of VM written in Java where you had to write an assembler in Scheme as the final 'biggie' project.
Here's something I wrote about this work: https://atgreen.github.io/repl-yell/posts/cl-kawa/
On OpenLDK, if it's able to run something like SweetHome3D at usable speeds I would consider it a success and an interesting exercise.
And? Do you want a medal for plagiarizing other people's work?