31–40 of 79 posts
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.
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.
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.
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.
Claims to have all the syntax covered, but not a single example of specifying lifetimes or the turbofish, some of the trickiest rust syntax
Claims to have all the syntax covered, but not a single example of specifying lifetimes or the turbofish, some of the trickiest rust syntax
The HRTB is probably the trickiest syntax for specifying lifetimes. It looks like `for F: Fn(&'a (u8, u16)) -> &'a u8`.
Earlier quoted context omitted.
The HRTB is probably the trickiest syntax for specifying lifetimes. It looks like `for F: Fn(&'a (u8, u16)) -> &'a u8`.
Can you translate this for those of us who don't speak rust?
The full code is usually something like:
fn foo(callback: F) where for F: ...
Which is a generic function foo that takes the argument of type F, where F must be...
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.
Can we please write our own READMEs before posting to HN?