VS Code extension for "go to definition" (including non-locals, i.e. dependencies)

Show and Tell
#1

Hello Haskell community,

I’d like to introduce a new VS Code extension I’ve been working on that implements the go-to (non-local) definition command for Haskell code.

It is not related to HLS in any way (a separate extension, a separate Haskell backend). It aims to fill the gap in HLS until the feature is implemented there.

This extension’s memory usage should be low (~150 MiB of RAM) during most workloads. When you save a Haskell file in your editor, the extension re-evaluates its cache and the memory usage will spike, but this should happen for a few seconds.
I hope this allows the use of the extension along the HLS on low-memory machines.

Also, the extension works in environments where HLS does not work for me, such as base package or repos where there’s no *.cabal project in the root (where there’s only a cabal.project in the root).

This is a pet project. I chose it to improve my Haskell skills. I’m looking for feedback, code reviews, and suggestions that could improve the extension (and my Haskell skills).

Link to the repo: github.com/kr3v/haskell-gtd-nl.
Installation instructions are in the README.md. I hope it works out of box for you :slight_smile:

20 Likes
#2

Very interesting! Thank you for building and sharing this :slight_smile:

2 Likes
#3

Hey,

Have you seen ghc-tags? You can use it with VS Code with the ctagsx extension, so you could piggy back on it and just point it to the source code of external deps.

There’s a feature request issue for indexing deps here, but providing this as a separate package wrapper is IMO reasonable.

3 Likes
#4

No, I haven’t, thanks for the link/repo.
Looks interesting, I would have loved seeing this when I started working on this stuff.

Something I don’t (yet?) understand is how it deals with imports plus module re-exports.

getGhcTags ::
  Located (HsModule GhcPs) ->
  [GhcTag]

so the project only emits locally exported identifiers (restricted by the export list, if any)?

I will definitely check the code/approach further, something that concerns me atm is module re-exporting (mtl re-exports packages from transformers, so importing something from mtl may actually mean importing from transformers).
If the project allows going to any word (unrestricted by a list of imports in a file), I wonder how qualified imports get dealt with or what happens with name conflicts (too many gets and similar words everywhere).

1 Like