How does ownership work within the Lisp tree structure?, What is the difference between ownership on this setting and ARC?

Agreed, a Lisp built around the concept of ownership is much more interesting than just a way to write Rust via S-expressions.

That page is beautiful! What ssg / theme are you using to build it?

I like the ubiquitous type inference. It reminds me a bit of ELSA for Emacs Lisp: https://github.com/emacs-elsa/Elsa. In particular, type aware macros have been on my wishlist forever: there's no good reason I shouldn't be able to write, e.g. an elisp or CL/SBCL compiler-macro that specializes an operation based on its inferred type. In normal lisps, it's hard to get even the declared types.

That said, I wish that part of Loon were less coupled to the allocation model though. What made you opt for mandatory manual memory management in an otherwise high-level language? And effects?

There are two things common in language design that, honestly, strike me as unnecessary:

1. manual allocation and lifetime stacking, and

2. algebraic effects.

On 1: I think we often conflate the benefits of Rust-style mutability-xor-aliased reference discipline with the benefits of using literal malloc and free. You can achieve the former without necessitating the latter, and I think it leads to a nicer language experience.

It's not just true that GC "comes with latency spikes, higher memory usage, and unpredictable pauses" in any meaningful way with modern implementations of the concept. If anything, it leads to more consistent latency (no synchronous Drop of huge trees at unpredictable times) and better memory use (because good GCs use compressed pointers and compaction).

On 2: I get non-algebraic effects for delimited continuations. But lately I've seen people using non-flow-magical effects for everything. If you need to talk to a database, pick a database interface and pass an object implementing the interface to the code that needs it. Effects do basically the same thing, but implicitly.

Honestly, that's very cool

That was basically my intent with this project, but I took the laziest way to get there lol

[flagged]

You can also drop into direct Rust with the (rust "...") macro if I forgot to implement anything

If you already have the ability to express the grammar productions in Rust that allow for optionally-specified types (e.g. variable declaration), then you have the ability to express lifetimes and the turbofish (which is just a curious way to call a generic function with a specific type parameter). The only weird thing would be that Lisp uses the apostrophe character for something very different than Rust, but you could just pick any other way to denote lifetimes.

The HRTB is probably the trickiest syntax for specifying lifetimes. It looks like `for<'a> F: Fn(&'a (u8, u16)) -> &'a u8`.

It's a vibecoded parser...

Good idea! I'm adding error messages + spans ala ariadne now

>Rust semantics with LISP syntax. A transparent s-expression frontend that compiles directly to Rust — no runtime, no GC

The first paragraph says literally that.

Yeah, it sort of reminds me of the microcode assembly of a few of the lisp machines, that, while in s-expressions were also clearly not lisp themselves. But could be an interesting target for some lisp macros.

A let that defines variables that have a lifetime beyond the scope of the expression? Yeah, that's really unusual. And it's not even the oddest looking thing from the first example block of code.

undefined

If anyone is curious, I've been making this using DeepSeek v4 Flash with Claude Code as the harness

That has definitely not been my experience as of late. I have produced multiple, largeish Clojure projects with AI that have been perfectly formatted and functional. Perhaps you were using an older or possibly smaller model? I am admittedly using Claude with higher end models and mid to high effort but it has been working great for months for me at this point.

Opus 4.6 handles elisp just fine. But I suppose YMMV.

Why are we even spending time on this. It's vibe coded slop. The creator probably never even ran it before it got to HN

Greenspun's tenth rule was formulated in a time before things like first-class functions were commonplace in industrial languages. Rust supports not just functional programming idioms but outright Scheme-style macros, it's out of scope for Greenspun's.

It's completely nonsensical too. Why would a parser for an alternative syntax introduce a GC?!

so you can do the transformations (see the rlisp macro section)

Nah.

It's sort of, but not quite, like "El jefe"

"L rut piss"

>S-expression syntax parsers are not hard to write.

I'm not sure I quite understand the point of your comment.

Are you implying that LLMs should be used for very hard to write code? I feel like the best use of LLMs is to automate the easy stuff so that I can focus on the hard to write stuff.

you ain't seen nothin' yet.

To get proper macros.