Hacker News: atgreen

New comment by atgreen in "Vera: a programming language designed for machines to write"

atgreen — Thu, 30 Apr 2026 02:38:14 +0000

This is not my experience. I've been experimenting with something very similar to vera. However my language transpiles into multiple languages (Java, Typescript, Common Lisp, Rust, C++, Python, C# and Swift). The transpiler is written in the language itself (there's a separate bootstrap transpiler written in Common Lisp). But where I'm going is that Claude, at least, is extremely capable at writing decent code in my new language with barely any prompting; just minimal guidance on the language itself and no examples.

New comment by atgreen in "Writing Lisp is AI resistant and I'm sad"

atgreen — Sun, 05 Apr 2026 04:24:10 +0000

I enjoyed reading this. Thank you for sharing.

I learned Common Lisp years ago while working in the AI lab at the University of Toronto, and parts of this article resonated strongly with me.

However, if you abandon the idea of REPL-driven development, then the frontier models from Anthropic and OpenAI are actually very capable of writing Lisp code. They struggle sometimes editing it (messing up parens)), but usually the first pass is pretty good.

I've been on an LLM kick the past few months, and two of my favorite AI-coded (mostly) projects are, interestingly, REPL-focused. icl (https://github.com/atgreen/icl) is a TUI and browser-based front end for your CL REPL designed to make REPL programming for humans more fun, whether you use it stand-alone, or as an Emacs companion. Even more fun is whistler (https://github.com/atgreen/whistler), which allows you to write/compile/load eBPF code in lisp right from your REPL. In this case, the AI wrote the highly optimizing SSA-based compiler from scratch, and it is competitive against (and sometimes beating) clang -O2. I mean... I say the AI wrote it... but I had to tell it what I wanted in some detail. I start every project by generating a PRD, and then having multiple AIs review that until we all agree that it makes sense, is complete enough, and is the right approach to whatever I'm doing.

New comment by atgreen in "Whistler: Live eBPF Programming from the Common Lisp REPL"

atgreen — Fri, 27 Mar 2026 18:30:57 +0000

Thank you!

New comment by atgreen in "Whistler: Live eBPF Programming from the Common Lisp REPL"

atgreen — Fri, 27 Mar 2026 16:59:18 +0000

The whistler code you inline with your common lisp is an s-expression based DSL. So you can use common lisp macros, but those macros are generating something that will look familiar to CL devs but is restricted based on the eBPF archictecture and validator requirements. eg. it only supports bounded `dotimes`, some basic progn/let/when/if/cond/eq/setf/incf/decf and math, and a simple array iterator. No lists, loops, tagbody/go, conditions, etc, etc. There's a manual in the docs directory.

Show HN: Whistler – a Lisp that compiles to eBPF

atgreen — Mon, 23 Mar 2026 16:48:07 +0000

Whistler compiles s-expressions to eBPF bytecode and emits ELF object files (no clang/LLVM). It includes an SSA-based optimizer that matches optimized clang code. You can even use it inline in your Common Lisp code, or from your REPL, and have the eBPF code loaded/unloaded without anything touching disk at all.

Blog post with more background: https://atgreen.github.io/repl-yell/posts/whistler/

Comments URL: https://news.ycombinator.com/item?id=47491964

Points: 3

# Comments: 0

New comment by atgreen in "SBCL Fibers – Lightweight Cooperative Threads"

atgreen — Sun, 15 Mar 2026 06:41:42 +0000

They are much better these days.

New comment by atgreen in "SBCL Fibers – Lightweight Cooperative Threads"

atgreen — Sun, 15 Mar 2026 06:41:12 +0000

256k is just's just a placeholder for now. The default will get reduced as we get more experience with the draft implementation. The proposal isn't complete yet.

New comment by atgreen in "SBCL: A Sanely-Bootstrappable Common Lisp (2008) [pdf]"

atgreen — Thu, 12 Mar 2026 22:23:41 +0000

I haven't really looked into it, but I'm hopeful it can be made to work.

New comment by atgreen in "SBCL: A Sanely-Bootstrappable Common Lisp (2008) [pdf]"

atgreen — Thu, 12 Mar 2026 15:24:00 +0000

No. I have yet to propose the patches formally. The SBCL maintainers are reviewing the high-level proposal (on my blog) first. You can try the implementation, however. There's a pointer to the repo/branch on my blog. I need to build a proper benchmarking framework and publish some real numbers that people can reproduce before I am confident enough to submit the patches for review.

Let me know if you try it out. I would love some feedback (via github)

New comment by atgreen in "SBCL: A Sanely-Bootstrappable Common Lisp (2008) [pdf]"

atgreen — Thu, 12 Mar 2026 09:51:30 +0000

This very website that you are using right now, Hacker News, runs on sbcl.

New comment by atgreen in "SBCL: A Sanely-Bootstrappable Common Lisp (2008) [pdf]"

atgreen — Thu, 12 Mar 2026 09:45:58 +0000

I'm the author. https://atgreen.github.io/repl-yell/posts/sbcl-fibers/

New comment by atgreen in "Smalltalk's Browser: Unbeatable, yet Not Enough"

atgreen — Thu, 05 Mar 2026 17:03:50 +0000

I set out to create a better text repl experience for Common Lisp couple of months ago, but was inspired by the pharo interface and built something much larger: https://atgreen.github.io/icl/ I use it all the time.

New comment by atgreen in "Cl-kawa: Scheme on Java on Common Lisp"

atgreen — Thu, 26 Feb 2026 11:50:03 +0000

It's like Dr Ian Malcolm says.. "Your developers were so preoccupied with whether or not they could, they didn't stop to think if they should" - Jurrasic Park (almost)

New comment by atgreen in "Cl-kawa: Scheme on Java on Common Lisp"

atgreen — Wed, 25 Feb 2026 11:20:15 +0000

Here's something I wrote about this work: https://atgreen.github.io/repl-yell/posts/cl-kawa/

New comment by atgreen in "Cl-kawa: Scheme on Java on Common Lisp"

atgreen — Wed, 25 Feb 2026 11:12:45 +0000

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/

New comment by atgreen in "Bending the CLOS Mop for Java-Style Single Dispatch"

atgreen — Sun, 22 Feb 2026 20:04:31 +0000

I managed to get a clojure REPL running on Common Lisp (SBCL) via OpenLDK, my Java JIT compiler and runtime on Common Lisp. This blog post gives an overview on how I manipulated CLOS's method dispatch to improve performance for single-dispatch methods calls.

Bending the CLOS Mop for Java-Style Single Dispatch

atgreen — Sun, 22 Feb 2026 20:04:31 +0000

Article URL: https://atgreen.github.io/repl-yell/posts/clos-mop-dispatch/

Comments URL: https://news.ycombinator.com/item?id=47114131

Points: 8

# Comments: 2

New comment by atgreen in "Show HN: Interactive Common Lisp: An Enhanced REPL"

atgreen — Thu, 25 Dec 2025 12:14:09 +0000

Hey pjmlp -- your comment inspired me to do some additional work. From the text console, you can run the ,brower command and it will open up your browser with a REPL on the same lisp image. The browser-based REPL has many interesting features .. too many to mention here. Please check it out again at https://github.com/atgreen/icl Thank you!

New comment by atgreen in "Show HN: Interactive Common Lisp: An Enhanced REPL"

atgreen — Fri, 19 Dec 2025 13:06:05 +0000

No, but now that I've looked, I'm hacking down another rabbit hole...

New comment by atgreen in "Show HN: Interactive Common Lisp: An Enhanced REPL"

atgreen — Tue, 16 Dec 2025 21:46:34 +0000

Thanks, vinderal. Since you wrote this the other day, I've improved the auto-completion so it is more context-aware. For instance, it will auto-complete using your filesystem when it is reasonably sure that you are trying to reference a filename. There's also a new interactive object inspector TUI, and a super-experimental `,explain` command. `,explain` will fire up gemini/claude cli to have it explain the last command/result/error. It provides temporary access to an icl mcp service so the AI can use tools for read-only access to your running lisp image.