Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Rust but Lisp

github.com

Post reply on HN
Print view View original

61–70 of 79 posts

Re: Show HN: Rust but Lisp

#61

Post by helenite »

ecto wrote: post #55
akch wrote: post #50

Earlier quoted context omitted.

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

Thanks :) Check out the code - it's Loon! https://github.com/ecto/loon/blob/main/web/src/pages/guide/o...

The website seems to have some bugs on mobile, seen on Chrome 147.0.7727.137

- Cannot horizontally scroll the code snippets on homepage when it overflows. The scroll bars appear but swiping the snippet does nothing. - Footer links are unresponsive (loon, GitHub, MIT Licence links) - In the changelog page, scrolling makes the hamburger menu hide release dates behind it - Hamburger close chevron looks misaligned (not sure if this was a deliberate choice)

Re: Show HN: Rust but Lisp

#62

Post by gwerbin »

quotemstr wrote: post #59
ecto wrote: post #23

Readers may enjoy my lisp, Loon, which takes heavy inspiration from Rust https://loonlang.com/guide/ownership

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 p…

I always saw algebraic effects as a more-ergonomic alternative to functor/applicative/monad for managing I/O and otherwise impure code. If you aren't particularly concerned with that level of purity then yeah it's "just" an indirect way to write an interface.

Re: Show HN: Rust but Lisp

#64

Post by moefh »

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 { 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:

    (struct X)
    (enum A () (P X) Q)
produces:

    struct X;
    enum A {
        _ /* List([], Some(Span { start: 54, end: 56 })) */,
        P(X),
        Q
    }
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...

Re: Show HN: Rust but Lisp

#67

Post by quotemstr »

gwerbin wrote: post #62
quotemstr wrote: post #59

Earlier quoted context omitted.

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 p…

I always saw algebraic effects as a more-ergonomic alternative to functor/applicative/monad for managing I/O and otherwise impure code. If you aren't particularly concerned with that level of purity then yeah it's "just" an indirect way to write an interface.

I've found that in practice, people use effects systems as dynamic-extent globals, like DEFVAR-ed variables in Lisp.

"Oh, it's not a global. Globals are bad. Effects are typed and blend into the function signature. Totally different and non-bad."

No. Typing the effects doesn't help: oh, sure, in Koka I can say that my function's type signature includes the "database connection" effect. Okay, that's a type. Where does the value backing that type come from? Thin air? No, the value backing an effect comes from the innermost handler, the identity of which, in a large program, is going to be hard to figure out.

Like all global variables, the sorts of "effects" currently in vogue will lead to sadness at scale. Globals don't stop being bad when we call them something else: they're still bits of ambient authority that frustrate local reasoning. It's as if everyone started smoking again but called cigarettes "mist popsicles" and claimed that they didn't cause cancer.

There's no way around writing down names for the capabilities we give a program and propagating these names from one part of the program to another. Every scheme to somehow free us from this chore is just smuggling in ambient authority by another name. Ambient authority is seductive. At small scales, it's fine. Better than fine! Beautiful. Then, one day, as your program scales and its maintainership churns, you find you have no idea who implements what.

Software engineering develops antibodies against these seductions. The problem is that the antibodies are name-based, so when we dress up old, bad ideas with new names, we have to re-learn why they're bad.

P.S. You might object, "You're talking about dynamic-extent effects. What about lexically-scoped effects systems?", you might ask. "These fix the problems with dynamic-extent effects."

Sure. Lexical effects are better. That's why every decent language already has a "lexically-scoped effect system". It's called let-over-lambda, or if you squint, an "object". We've come full circle.

Re: Show HN: Rust but Lisp

#70

Post by lycopodiopsida »

jaggederest wrote: post #18

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.

It is absolutely not true, I've vibecoded an app for myself in CL and opus/sonnet had 0 problems with parens and types. Add to it an MCP to work with REPL and it is much more smooth than Go in my experience.
Post reply on HN