FilterHN

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.

▲

vermilingua

2 hours 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

▲

kccqzy

31 minutes ago

[-]

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

▲

stdatomic

27 minutes ago

[-]

Can you translate this for those of us who don't speak rust?

▲

Xirdus

17 minutes ago

[-]

Type F must be a function that's generic over any possible lifetime 'a, with a single argument that's a reference with lifetime 'a to a tuple of two numbers, and returns a reference with the same lifetime 'a to an 8-bit number.

The full code is usually something like:

fn foo<F>(callback: F) where for<'a> F: ...

Which is a generic function foo that takes the argument of type F, where F must be...

▲

kibwen

2 hours 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

1 hour ago

[-]

Could!

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

▲

andrepd

2 hours ago

[-]

It's a vibecoded parser...

▲

gleenn

4 minutes ago

[-]

Technically it's a transpiler.

▲

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

2 hours ago

[-]

Thanks LLM.

▲

hawkice

1 hour ago

[-]

Incorrect, and mean-spirited. Come on.

▲

IncreasePosts

36 minutes ago

[-]

For what it's worth I thought it was a nice comment and I saw no sign of AI in it

▲

jaggederest

1 hour ago

[-]

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.

▲

gleenn

1 hour ago

[-]

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.

▲

dleslie

1 hour ago

[-]

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

▲

2ndorderthought

1 hour ago

[-]

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

▲

GalaxyNova

3 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

2 hours 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

2 hours 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

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

▲

OhMeadhbh

1 hour ago

[-]

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.

▲

eiiot

9 minutes ago

[-]

> compiles directly to Rust — no runtime, no GC, just (s-expr → .rs → binary).

Can we please write our own READMEs before posting to HN?

▲

amelius

1 hour ago

[-]

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

▲

physPop

1 hour ago

[-]

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

▲

amelius

1 hour 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

2 hours ago

[-]

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

▲

moron4hire

1 hour ago

[-]

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.

▲

Maxatar

47 minutes ago

[-]

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

▲

FrankWilhoit

4 hours ago

[-]

And for why?

▲

macmac

4 hours ago

[-]

To get proper macros.

▲

fao_

3 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

3 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

▲

nxobject