Haskell · ferramentas · editor
Haskell Language Server (HLS) em 2026: instalação e correções comuns
Escrever Haskell sem um backend de IDE é apertar os olhos sobre erros de tipo depois de cada compilação. O Haskell Language Server (HLS) corrige isso: implementa o Language Server Protocol (LSP), dando-lhe tipos inline, autocompletar, ir-para-a-definição, documentação ao passar o rato e refatorações no VS Code, no Neovim e noutros editores. Este guia abrange o que é o HLS, como instalá-lo de forma limpa em 2026, ligá-lo ao seu editor e o punhado de erros que fazem as pessoas tropeçar.
O que o HLS faz de facto
O HLS é um único servidor com o qual os editores comunicam via LSP. Fornece:
- Informações de tipo ao passar o rato e inline.
- Autocompletar e sugestões de importações.
- Ir-para-a-definição, pesquisa de referências e símbolos do documento.
- Ações de código: adicionar uma importação em falta, preencher uma assinatura de tipo, aplicar uma sugestão.
- Linting através das sugestões hlint integradas.
Como fala LSP, o mesmo servidor alimenta todos os editores — instala o HLS uma vez e escolhe um plugin cliente.
Instalar o HLS com o GHCup
O caminho limpo é o mesmo gestor de toolchain que usa para o compilador. Se ainda não configurou a toolchain, comece pelo nosso guia de instalação do GHCup e depois adicione o HLS:
ghcup install hls recommended
ghcup set hls recommended A regra mais importante: o HLS tem de suportar a sua versão de GHC ativa. Instale a build do HLS correspondente ao GHC com que compila — a interface interativa ghcup tui mostra que versões do HLS cobrem que GHC.
Ligá-lo ao seu editor
- VS Code: instale a extensão oficial Haskell; pode gerir o HLS por si ou usar o instalado pelo GHCup. Aponte-a para o HLS do GHCup para evitar desalinhamentos de versão.
- Neovim: configure o
haskell-tools.nvimou o cliente LSP integrado com ohaskell-language-server-wrapperno seu PATH. - Outros editores: qualquer editor compatível com LSP (Emacs com lsp-mode, Helix, Zed) funciona — aponte-o para o binário
haskell-language-server-wrapper.
O binário -wrapper seleciona automaticamente o HLS certo para o GHC de cada projeto, e é por isso que apontar o seu editor para ele (em vez de para uma versão fixa) evita a maioria das incompatibilidades.
Erros comuns e correções
- «No HLS version for GHC X.Y». O seu GHC é mais recente do que qualquer HLS instalado. Atualize o HLS através de
ghcup tui, ou faça o projeto passar para um GHC que o HLS suporte. - O HLS reinicia constantemente / fica sem memória. Os projetos grandes podem esgotar a RAM durante a indexação; feche as outras ferramentas e garanta que a sua máquina tem memória suficiente para o tamanho do projeto.
- Erros de «cradle» / componentes errados. O HLS lê o seu build através dos ficheiros de projeto; garanta primeiro que o projeto compila com
cabal build, e adicione umhie.yamlapenas quando a deteção automática falhar. - Resultados desatualizados após uma mudança de dependência. Reinicie o language server a partir do seu editor; o HLS guarda em cache o plano de build.
Uma regra fiável: se o HLS se portar mal, confirme primeiro que o projeto compila na linha de comando — veja como funcionam os builds paralelos em como o Cabal aproveita os seus núcleos, e o contexto do modelo de build em Cabal 2.0.
FAQ
O HLS é gratuito e oficial? Sim — é o language server de código aberto e padrão da comunidade para Haskell, instalável através do GHCup.
Preciso de Cabal ou Stack para o HLS? O HLS lê o sistema de build que o seu projeto usa; funciona tanto com projetos Cabal como Stack.
Porque é que o HLS tem de corresponder ao meu GHC? O HLS é compilado contra uma API específica do GHC, por isso cada build do HLS suporta um conjunto de versões do GHC. Use o binário wrapper para selecionar automaticamente o certo por projeto.
O HLS funciona no Windows? Sim, através do instalador Windows do GHCup e das mesmas extensões de editor.