Proposal: Daml Language Server Modernization

Development Fund Proposal Submission

Proposal file: proposals/lsp_proposal.md

---

Summary

In PR #7, @0xfourzerofour proposed rewriting the Daml language server from scratch. The author went inactive and the proposal was rejected. We'd like to revive that effort, with a different approach.

Rather than a rewrite, we propose forking Haskell Language Server (HLS), the de facto production-grade language server for Haskell, and adapting it to Daml on top of Damlc (itself a fork of GHC), adding the Daml-specific changes needed to bridge the gap with stock HLS. Daml Studio's language server today is Digital Asset's own 2019 fork of Ghcide, predating HLS, and it has not kept pace with the LSP feature set HLS has since built (rename, formatting, call hierarchy, and more). It also has no officially supported path beyond VS Code, despite some unofficial community integrations for other editors. Building on HLS' plugin architecture addresses both gaps directly, while reusing the same Ghcide extension points that Daml's own fork has relied on successfully since 2019.

Our team includes certified Daml developers, GHC maintainers, designers of the first version of the Cardano node and wallet, general Haskell tooling engineers, and contributors to the LIGO, Michelson, and Motoko tooling ecosystems.

---

Checklist

• [X] Proposal file added under /proposals/
• [X] Milestones and funding amounts defined
• [X] Acceptance criteria included
• [X] Alignment with Canton priorities described

---

Notes for Reviewers

Notes for Reviewers

• Milestone 1 is scoped as a short investigation phase to close open technical questions before committing to the heavier Milestone 2/3 build.
• HLS 1.8.0.0 is proposed as the specific fork point: the last HLS release to support GHC 8.8.4 (close to Damlc's current compiler version: GHC 8.8.1), and already a mature codebase by the time it shipped in September 2022. Subject to review in Milestone 1.
• Acceptance criteria are adoption-based (developer migration count, multi-editor uptake, community PRs/issues, adoption enablement) rather than artifact-delivery-based, per CIP-0100's guidance to weight proposals toward ecosystem utility.
• Vim/Neovim support is scoped as its own milestone within this proposal, rather than a separate grant, to keep it accountable to this proposal's own acceptance criteria.

---

In https://github.com/canton-foundation/canton-dev-fund/pull/7#issuecomment-4303306132, some questions were asked regarding the old LSP proposal. Here we'd like to answer them:

1. AST Parser: As we plan to fork HLS, we would always be up-to-date with whatever revisions of Damlc are pinned to it, provided the fork links against DA’s own patched GHC/ghc-lib.
2. Type-checking: The same. HLS uses the GHC API for syntax and types, so we’d use the compiler as the source of truth.
3. Daml Versions: The plan is to decouple damlc ide from damlc and use HLS’ strategy to build the new language server using specific Damlc versions and use its API. Since the language server will be tied to Damlc internally, making changes to it should be low-risk, but it also doesn’t come for free if the API changes. Historically, Damlc's vendored ghc-lib frontend has been pinned to GHC 8.8.1 unchanged since the project's inception in 2019, which justifies this reasoning.
4. Acceptance Criteria: As we would use the same parser Damlc already uses, we can rest assured that all syntactical constructs can be parsed with no extra effort. However, the syntax highlighting files (TextMate grammars, and the proposed (Neo)Vim grammars) would still require manual intervention. Unfortunately, that is difficult to test and will require synchronization from the core .y grammar maintainers and the language server maintainers.

1. A lower-effort solution to keep the editor grammars in sync is to use a tool such as https://gitlab.com/ligolang/ligo/-/tree/dev/lib/ligo_syntax_highlighting (a tool we helped to maintain which we may fork and rewrite in Haskell), minus Emacs grammars, but it wouldn’t help with keeping them in sync with the core grammar. 2. Alternatively, we may investigate about reading Happy source files, or possibly its generated debug output, and write a tool for it, but it’s a high-effort project.