Wouldn’t it be wonderful if, in the world of LLMs, Lisp became the new lingua franca, because we don’t have to convince humans that parens are scary, and because it enables exactly this kind of magic.
Hey, I'm the author. Yes, I worked in the University of Toronto's AI lab as a student many years ago, back when Lisp in AI was a thing. It definitely would be full circle!
Well they could output plan.md files that are architecture independent first. Then we can commit those, and only generate the final machine code on demand.
I mean, is this an actual issue? There have to be plenty of developers using LLMs to write Lisp(s).
I have occasionally seen Claude models struggle to balance brackets/parens in nesting-heavy languages like Dart (Flutter), but it’s gotten much better.
Plus your agent (strictly speaking) doesn't need to generate parens as tokens. Instead they can generate imperative stack commands that manipulate the AST. Or something paredit-like.
I think OpenLDK allow you to use the Java world for sbcl when you don't want to use Clojure or ABCL. But using OpenLDK requires you to pay the interop cost and when speed of the java libraries is not a sharp constrain.
Wouldn’t it be wonderful if, in the world of LLMs, Lisp became the new lingua franca, because we don’t have to convince humans that parens are scary, and because it enables exactly this kind of magic.
Full circle for Lisp as an AI language.
Hey, I'm the author. Yes, I worked in the University of Toronto's AI lab as a student many years ago, back when Lisp in AI was a thing. It definitely would be full circle!
LLMs can’t count. Do you think they can balance parens?
Personally, I’ve wondered why they don’t just generate machine code.
I never thought of that. Humans avoid machine code for many reasons. If LLM's don't need to produce human-readable output, then why not?
It would be architecture dependent
Well they could output plan.md files that are architecture independent first. Then we can commit those, and only generate the final machine code on demand.
That's a very good way to ensure your software is not reproducible.
People don't trust other people making little changes to existing software, who will ever be ok with rebuilding it from scratch?
We could call the final phase a coLLMpiler for good measure.
they can call tools to count tho?
I mean, is this an actual issue? There have to be plenty of developers using LLMs to write Lisp(s).
I have occasionally seen Claude models struggle to balance brackets/parens in nesting-heavy languages like Dart (Flutter), but it’s gotten much better.
LLMs can write Common Lisp just fine. I have no idea where the myth that they can't because of the all the parentheses comes from.
Plus your agent (strictly speaking) doesn't need to generate parens as tokens. Instead they can generate imperative stack commands that manipulate the AST. Or something paredit-like.
I think OpenLDK allow you to use the Java world for sbcl when you don't want to use Clojure or ABCL. But using OpenLDK requires you to pay the interop cost and when speed of the java libraries is not a sharp constrain.
(or LispWork$ and its Java interface)
Your "light mode" button doesn't work.
That button makes the invisible scrollbar visible, though, which is great.
I love lisp. I have fond memories of reading/studying Land of Lisp many years ago. Glad to see stuff like this being created.
Incidentally, it looks like this idea also works with Jolt now. It's still in alpha stages, but works as a proof of concept. https://github.com/jlt-commons/jolt-openldk