the Racket LSP is pretty bad so I thought I’d try editing my Racket code in Emacs instead of Neovim, since Emacs has racket-mode

but unfortunately it seems like racket-mode is every bit as bad as the Racket LSP at figuring out wtf is going on in this language lol. it can’t even tell if I’m calling a function with the wrong number of arguments (which the LSP can’t either) and has a lot of the same quirks and missing features

so that’s a shame. it seems like you can’t really have a good editing experience when writing Lisp code. I wonder if the highly-dynamic nature of Lisp languages (macros, dynamic typing, etc.) makes most kinds of static analysis impossible. it’s pretty annoying though, I’m ngl

the main feature that I’m really missing is being able to press K on any function and pull up a bunch of helpful info on that function (contracts, arguments, and its docstring (which Racket doesn’t even have :/)). instead I have to search through my files manually to find the definition of that function, every time. super annoying

if the problem with Lisp static analysis is that macros can expand at runtime, I wonder if this could be fixed by having a Lisp where macros expand at compile-time instead (which is what Fennel does)

although this means that macros would have to be more limited, and that’s a bit of a shame (though I’m not sure exactly what the use case of runtime macro-expansion is anyway)

I’m starting to think that maybe the trick to making a statically-analyzable Lisp is to do what Rust does and figure out as much stuff at compile-time as possible. or in this case, transpile-time because it would be transpiling to a simpler subset of the language’s own forms (which are then analyzed by the LSP)

Rust actually does a ton of smart things in terms of language design so it’s a shame that it’s *gestures vaguely*

someone should make a Rust-inspired Lisp, and by that I do not mean “pedantic about the tiniest implementation detail”