Hacker News

47 points by thatxliner 3 hours ago | 21 comments

Unfortunately, given the clear LLM basis of this project, s-expressions aren't a great choice. I've found coding agents struggle really hard with s-expression parentheses matching.

Much better to give them something more M-expr styled, I think a grammar that is LL(1) is probably helpful in that regard.

Basically the more you can piggyback on the training data depth for algol-style and pythonic languages the better.

vermilingua 49 minutes ago

Claims to have all the syntax covered, but not a single example of specifying lifetimes or the turbofish, some of the trickiest rust syntax

kibwen 25 minutes ago

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.

vermilingua 18 minutes ago

Could!

> Everything Rust has … expressed as s-expressions. No semantic gap.

andrepd 38 minutes ago

It's a vibecoded parser...

hawkice 2 hours ago

I think some comments are missing the upside of it being precisely Rust, without any new semantics. If you want lisp that compiles to machine code, Common Lisp can get reasonably efficient. The purpose of bringing Rust into it is to surface Rust-specific semantics -- which many people quite like!

j16sdiz 42 minutes ago

Thanks LLM.

GalaxyNova 2 hours ago

It seems like this is more like writing Rust in an s-expression syntax instead of having a proper lisp dialect that compiles to Rust, which is cool I guess but not very interesting.

It's quite weird-looking for someone who's done any amount of lisp programming.

noosphr 49 minutes ago

>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.

monocasa 41 minutes ago

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.

shawn_w 52 minutes ago

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.

amelius 14 minutes ago

This is probably what Rust's internal ASTs look like. But why would you want to input programs as ASTs?

physPop 12 minutes ago

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

amelius 7 minutes ago

Yes, but you could do the same by transforming Rust's ASTs. The only downside is that your input format is different from the format you are transforming. But the upside is that readability is much improved, which matters because code is typically read far more often than it is written.

stuaxo 2 hours ago

"no runtime, no GC, just" I am BEGGING every project to not have this LLMism in their docs.

It reads as No X no Y just slop to me every time.

andrepd 37 minutes ago

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

FrankWilhoit 3 hours ago

And for why?

macmac 3 hours ago

To get proper macros.

fao_ 2 hours ago

Scheme already has hygenic macros, I don't get why you'd vibecode a worse (less battle tested, llm-generated) replacement. I'm not sure why this hit the front-page, to be honest, because it doesn't seem noteworthy or interesting (Anyone and their mother can vibecode something like this in eight hours)

wk_end 2 hours ago

Scheme doesn't have Rust semantics, though?

zem 2 hours ago

this is not a replacement for scheme, it's simply an alternative syntax for rust