{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiht4jnyydcdnokbmmt2smynfz57opedvmfprwiajyiw6jtim5rkc4",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mhiexo73yqc2"
  },
  "path": "/t/flexible-haskell-a-new-plugin-for-jetbrains-ides/13813?page=2#post_29",
  "publishedAt": "2026-03-20T09:40:47.000Z",
  "site": "https://discourse.haskell.org",
  "textContent": "Thinking about some of the questions I have a feeling I should probably describe one of the biggest differences between JetBrains IDEs and VSCode or other IDEs - the PSI structure.\n\nJetBrains has a grammar-kit support, which allows you to create BNF grammars and JFlex lexers for languages. They are then used to generate PSI elements, which represent the tokens on your files. You can (and should) do that for any language (although you can still use other methods for your parser/lexer), as it will generate an indexed tree in your IDE. Based on this tree, you can then create lookups (references) and create some logic for on-hover documentation, formatting, refactoring, validation etc etc. Once defined, you can extend, merge with other languages etc etc.\n\nVSCode for the longest time did not have that, as they started with TextMate implementation, which gave you a flat language representation. (they were essentially using regex to analyze a grammar). Nowadays they do have some TreeSitter support, but most languages for this reason started being based on LanguageServers and other external tools that make up for the shortcomings of the IDE.\n\nNow with LS and other tools like the Formatters or Linters being wildly available for languages such as Haskell, there is always the question as to why somebody like me would bother with a custom implementation at all. But there are some clear benefits:\n\n  1. language servers tend to be slow, require startup and can break during their runs (as I have learned painfully during other implementations). Psi indeces work offline without any dependencies.\n  2. Things like renaming, refactoring, even flipping if/else branches, is very easy for me to do, as I am looking up indexed elements, rather than relying on parsed string sections\n  3. PSI elements in general are fast, and can be even faster with cached stubs - I do not need to wait for other sources to operate\n  4. I have access to my other projects where I did pretty much most of the things you can come up with in an IDE, which is helpful (cause I can copy-paste my own implementations at times)\n\n\n\nAlso: I still need to have a PSI structure anyway, if i truly want to make use of Highlighting and other logical functions within JetBrains. I have built various grammars before, starting years ago on “Apache Freemarker”, as I wanted to add my own logic to the original grammar. But yeah, those are at least my reasons.\n\nAnyway, this is not me saying the other is bad, there are benefits from having LS based implementations (you can reuse them across all IDEs for example), but for JetBrains I’d argue one should put the work into doing the other.\n\nThat said: I plan on supporting both, always. So people will get to (and already can) choose the way they want to work with the IDE.",
  "title": "Flexible Haskell - a new plugin for JetBrains IDEs"
}