For a few years now I have been working on the Haskell Language Server (HLS), and the lsp library for the LSP protocol and writing LSP servers. Unsurprisingly, I have developed some opinions about the design of the LSP!

Recently I gave a talk about HLS and LSP at the Haskell Ecosystem Workshop at Zurihac 2024. One slide featured a hastily-written table of “LSP: the good, the bad, and the ugly”. As I gave the talk I realised that there was plenty to say on that topic, hence this post.

Most of what I have to say is about the architecture or design of the protocol. I won’t have much to say about the features that the protocol supports. Other people probably have a lot to say about that (e.g the folks working on languages that use heavy editor integration, like interactive theorem provers). My perspective here is from my time implementing LSP servers, rather than my time using them.

I will repeat this a few times, but I want to be very clear that LSP is great and I am very happy that it exists. While this is going to be a mostly critical post, it is criticism that exists in the context of me being happy to be working on editor tooling that is going to Just Work for a wide spectrum of users!

Finally, I want to also mention the excellent post LSP could have been better, which is the best critical writing that I’ve read on LSP, and which inspired several of the points I’m going to make.

Note: this post assumes you know quite a bit about defunctionalization. If you don’t read this post first.

Note: this is from my drafts. I think I had more to say, but it is sufficiently long since I read the book that I don’t remember what it was. Re-reading it I think it holds up okay so I’m publishing it.

This book changed how I think about women, and about feminism.

De Beavoir’s analysis of the position of women is a clear, historical meterialist one. Women are faced with a cascading series of disadvantages, each of which builds on the previous one, both historically/causally and in the current state.

If you spend enough time in risk-tolerant places (e.g. startups, blockchain) you start to notice a particular pattern. A charismatic founder, call them Alice, starts a new project. The project seems to be transparently stupid or bullshit, but somehow they manage to secure a lot of funding and/or users. After a while, the project fails, probably after providing no value to anyone… but Alice comes out of it well, having cashed out through high salary or selling lots of stock/tokens/whatever.

The Haskell Language Server (HLS) codebase has a lot of CPP conditionals. A lot of them look like this:

#if MIN_VERSION_ghc(9,2,0)

which says that the version of the ghc library has to be at least 9.2; or this

#if MIN_VERSION_ghc(9,2,0) && !MIN_VERSION_ghc(9,3,0)

which says that the version of the ghc library has to be between 9.2 and 9.3; or this

#if __GLASGOW_HASKELL__ < 902

which says that the version of GHC itself has to be less than 9.2.

When we stop supporting a version of GHC, many of these conditonals become obsolete. If we have code like this:

x = 
#if MIN_VERSION_GHC(9,2,0)
  1
#else
  2
#endif

then once we only support GHC 9.2 and above, the conditional will always evaluate to true, and so we can simplify it away. Until now, we’ve mostly done this by hand. But surely there should be a way to do this automatically!