soegaard2
2018-8-5 14:04:58

If anyone needs a project: Write a langserver for Racket: https://langserver.org/


greg
2018-8-5 14:28:12

@soegaard2 It looks like there are already at least two: https://pkgd.racket-lang.org/pkgn/search?tags=lsp


soegaard2
2018-8-5 14:28:28

Ooh! Great.


greg
2018-8-5 14:46:42

Going to make remacs an LSP client?


greg
2018-8-5 14:48:16

That first pkg, an LSP server for the Racket lang, has some generic LSP implementation stuff that either a client or server could use. Maybe they’d be willing to split it out into a sep pkg.


soegaard2
2018-8-5 14:50:08

Nice tip. Yes, long term I think implementing LSP would be a good thing. Lots of work in getting a racket-mode working. So not having to repeat the process for C, JavaScript, etc would be great.


greg
2018-8-5 14:55:25

Speaking of LSP-like stuff, the past few weeks I overhauled how racket-mode’s Emacs Lisp front end talks to the Racket back end over a TCP connection. The protocol is simply writing and reading s-expressions. :slightly_smiling_face: It used to be one write/read (request/response) at a time. I recently changed it to use a nonce/id and the responses can come at any time. So now multiple commands can be “in flight”, and a long one won’t block a shorter one. On the Emacs front-end there’s simply a hash-table of nonce -> callback function. So the basic command request/response approach now is “async”.


greg
2018-8-5 14:56:36

When it’s Emacs and Racket, simply writing/reading s-expressions is of course nice and something like JSON-RPC for LSP seems “heavy”. But in the general case of editors and langs, LSP seems fine and not that “heavy” compared to some specs I’ve seen.


soegaard2
2018-8-5 14:59:38

Did you make the communication async to make the repl more robust? Or just to prevent blocking?


greg
2018-8-5 15:02:30

Two steps. 1. Few weeks ago, made the commands async to prevent blocking the Emacs UI. Worked well. 2. Then realized, something like racket-expand-file on a 1000 line file, the macro-debugger/stepper-text can take many seconds before you can even do the first step. Although it’s not blocking the Emacs UI generally, if you try another racket-mode command, of course that will be blocked. So then decoupled the requests and responses.


greg
2018-8-5 15:03:55

I’d thought of doing this for literally years, but the idea of command responses showing up async made me queasy. So I just needed time to think it through. Plus for long stretches wasn’t able to focus on anything complicated with racket-mode, due to other work.


soegaard2
2018-8-5 15:05:13

I like your approach. Writing a repl is definitely more complicated than I expected.


greg
2018-8-5 15:06:10

It’s been an interesting journey, to do step by step. The first version of racket-mode just did a little syntax-highlighting fixes to scheme-mode, and dumped xrepl ,commands into a shell buffer, basically. :slightly_smiling_face:


soegaard2
2018-8-5 15:09:40

Remacs (still need a better name) is progressing. I have basic highlighting, ] inserts matching parenthesis, indentation almost works (I think it works, but I need to fix a bug in the partial-parser). Now I am improving the actual repl.


soegaard2
2018-8-5 15:10:44

It’s very helpful to look at racket-mode for Emacs.


greg
2018-8-5 15:13:43

Cool. Now that my “Summer of Emacs” commit-storm is winding down, I want to take a look at Remacs.


soegaard2
2018-8-5 15:14:59

It’s still alpha-quality. The pieces are beginning to fell into plave though.


greg
2018-8-5 15:15:14

Are you able to use Remacs to edit Remacs yet? :slightly_smiling_face:


soegaard2
2018-8-5 15:15:33

Nope!


greg
2018-8-5 15:16:08

That will be a nice :tada: milestone


soegaard2
2018-8-5 15:19:53

I am impressed by the quality of the Emacs documentation.


soegaard2
2018-8-5 15:20:55

I decided to keep the names used in the Emacs reference and mimic their operation closely.


greg
2018-8-5 15:30:04

Hmm, actually I’m a little confused how LSP is supposed to work with langs where you’d have both an edit buffer and a REPL. The LSP model seems to be, “Tell me, the LSP server, when you open a file and as you make changes to it in an edit buffer. I will keep a copy synchronized, so I know what to do when you give me commands.” In that model, what is a REPL? Is it like a second edit buffer? How are changes in it (like new definitions) supposed to be made known to the server if at all?


greg
2018-8-5 15:32:33

Anyway just an idle question. Some googling would probably answer.


soegaard2
2018-8-5 15:33:56

Can’t find anything. It would be a natural thing to include repls in the tables on http://langserver.org\|langserver.org.


markx
2018-8-5 16:12:54

Have you checked out the two listed above?


markx
2018-8-5 16:13:26

One seems to be just having indentation and color. The other one, I couldn’t get it running on my machine.


markx
2018-8-5 16:13:48

I have been longing a lsp server for racket for a long time.


markx
2018-8-5 16:23:14

Would be nice too get them work on my machine.


markx
2018-8-5 17:40:59

Is there any good tutorial about functional programming patterns, especially for Racket?


samth
2018-8-5 17:51:34

@philip.mcgrath rather than rerunning raco setup, you can just run raco make blah.rkt


samth
2018-8-5 17:51:44

that will compile that file and all its dependencies


samth
2018-8-5 17:52:21

if the particular file you’re running has an out-of-date zo file, then raco setup will only fix that if your file is part of a collection somewhere


samth
2018-8-5 17:52:27

if not, raco setup won’t help


markx
2018-8-5 18:10:00

@greg That’s actually a very good question. It’s like we are keeping two set of states. I think it could at least work if we just keep the lsp server and repl separate. It’s actually interesting to think the repl as a edit buffer, but maybe it’s a buffer that you can only add stuff, and not update or delete anything, I think. In that case it might not be very useful for the lsp server.


markx
2018-8-5 18:11:26

There are already lsp server for CL and clojure though. I’m interested in how they tackle this.