Pretty nifty. As of now, the code doesn't compile: there's some stray "span" stuff in codegen.rs[1], and it's trying to format `Warning` which doesn't implement `Display` in main.rs[2].
Fixing these, it runs mostly as advertised, but it seems to assume that one-letter types are always generic parameters, so it's impossible to (for example) generate this:
struct X;
enum A {
P(X),
Q
}
Trying this:
(struct X)
(enum A (P X) Q)
produces this:
struct X;
enum A<P, X> { Q }
while using a multi-letter type like `String`:
(enum A (P String) Q)
produces the expected:
enum A { P(String), Q }
One way to solve this would be to always require the generic annotation, and let it be empty when there are no generics, but when I tried that it did something weird:
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!
Claims to have all the syntax covered, but not a single example of specifying lifetimes or the turbofish, some of the trickiest rust syntax
show comments
GalaxyNova
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.
show comments
skulk
So if I wanted to actually use this and I write some rust-but-lisp code and there's a compile error, will it show me a nice error message with an arrow pointing to where the error happened in my lisp code?
Can I use the amazing `rust-analyzer` LSP to get cool IDE features?
I suspect the answer is no, but these might be good further prompts to use.
show comments
jaggederest
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.
show comments
lefra
> ((. dx powf 2.0) + (. dy powf 2.0)) sqrt))
I don't know what this is, but clearly not Lisp...
stevefan1999
Greenspun's tenth rule of programming is an aphorism in computer programming and especially programming language circles that states:[1][2]
Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
Maybe we should one day include Golang or Rust to it
This is probably what Rust's internal ASTs look like. But why would you want to input programs as ASTs?
show comments
OhMeadhbh
How do you change the syntax to eliminate reverse compatibility? I guess you could change the names of most key functions between releases. But to be compatible with rust you would need to make breaking changes every release.
chrisweekly
Should be named "Rutht"
zareith
Anyone working on something similar that compiles to go?
stuaxo
"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.
show comments
NooneAtAll3
does there exist something that can do the opposite?
some pre-processor that "compiles into rust" from less awful syntax?
nxobject
"Lust", or "Risp"?
show comments
moron4hire
I don't understand why this had to be LLM generated. S-expression syntax parsers are not hard to write. That's rather much the point of S-expressions.
show comments
thatxliner
For everyone who is shaming on the project for "not implementing enough," then you can definitely help me with it.
For everyone who is shaming on the project for being "LLM slop," sure but that's the reason why something like this can exist in the first place. The point isn't to be a finished, production-ready product. The point is to be an interesting work, and just a sly bit silly
eiiot
> compiles directly to Rust — no runtime, no GC, just (s-expr → .rs → binary).
Can we please write our own READMEs before posting to HN?
slopinthebag
How is pure unbridled AI slop like this making the front page? Voting rings?
I don't even feel bad saying this because clearly OP is just the front for Claude here.
Readers may enjoy my lisp, Loon, which takes heavy inspiration from Rust https://loonlang.com/guide/ownership
Pretty nifty. As of now, the code doesn't compile: there's some stray "span" stuff in codegen.rs[1], and it's trying to format `Warning` which doesn't implement `Display` in main.rs[2].
Fixing these, it runs mostly as advertised, but it seems to assume that one-letter types are always generic parameters, so it's impossible to (for example) generate this:
Trying this: produces this: while using a multi-letter type like `String`: produces the expected: One way to solve this would be to always require the generic annotation, and let it be empty when there are no generics, but when I tried that it did something weird: produces: I have no idea where the `_` and the comment came from.[1] https://github.com/ThatXliner/rust-but-lisp/blob/70c51a107b2...
[2] https://github.com/ThatXliner/rust-but-lisp/blob/70c51a107b2...
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!
I’ve seen this done with C as well.
https://www.eriksvedang.com/carp
https://github.com/tomhrr/dale
Claims to have all the syntax covered, but not a single example of specifying lifetimes or the turbofish, some of the trickiest rust syntax
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.
So if I wanted to actually use this and I write some rust-but-lisp code and there's a compile error, will it show me a nice error message with an arrow pointing to where the error happened in my lisp code?
Can I use the amazing `rust-analyzer` LSP to get cool IDE features?
I suspect the answer is no, but these might be good further prompts to use.
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.
> ((. dx powf 2.0) + (. dy powf 2.0)) sqrt))
I don't know what this is, but clearly not Lisp...
Greenspun's tenth rule of programming is an aphorism in computer programming and especially programming language circles that states:[1][2]
Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
Maybe we should one day include Golang or Rust to it
https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule
This is probably what Rust's internal ASTs look like. But why would you want to input programs as ASTs?
How do you change the syntax to eliminate reverse compatibility? I guess you could change the names of most key functions between releases. But to be compatible with rust you would need to make breaking changes every release.
Should be named "Rutht"
Anyone working on something similar that compiles to go?
"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.
does there exist something that can do the opposite?
some pre-processor that "compiles into rust" from less awful syntax?
"Lust", or "Risp"?
I don't understand why this had to be LLM generated. S-expression syntax parsers are not hard to write. That's rather much the point of S-expressions.
For everyone who is shaming on the project for "not implementing enough," then you can definitely help me with it.
For everyone who is shaming on the project for being "LLM slop," sure but that's the reason why something like this can exist in the first place. The point isn't to be a finished, production-ready product. The point is to be an interesting work, and just a sly bit silly
> compiles directly to Rust — no runtime, no GC, just (s-expr → .rs → binary).
Can we please write our own READMEs before posting to HN?
How is pure unbridled AI slop like this making the front page? Voting rings?
I don't even feel bad saying this because clearly OP is just the front for Claude here.
And for why?