fwcd / curry-language-server

IDE support for the functional logic language Curry

An experimental language server providing IDE support for the functional logic programming language Curry.

Building

To build the language server, you will need the build tool Haskell Stack. Once installed, you can run stack build to build the language server.

The final executable will be located in $(stack path --dist-dir)/build/curry-language-server.

If you wish to use the language server in an editor, you can also use stack install to install the binary into ~/.local/bin. By adding this directory to your PATH, invoking curry-language-server will work from any directory.

Editor Integration

To use the language server, you will need an editor that supports LSP. This usually involves pointing the LSP client towards the built executable and setting the transport method to stdio.

For Visual Studio Code, this extension can be used.

Known Issues

If the language server has trouble locating an interface for the Prelude, you may need to add your Curry compiler's lib directory to your import paths, e.g. in your config under curry.languageServer.importPaths or in <your project path>/.curry/language-server/paths.json (which is a string array of import paths). Alternatively, you may also place a compiled version (Prelude.icurry) in the folder <your workspace path>/.curry/language-server.

curry-language-server's Issues

Migrate to `OverloadedRecordDot`

This extension has been merged in GHC 9.2 and would allow us to drop the field prefixes.

Update haskell-lsp to 0.20

Update the haskell-lsp library to 0.20 and remove Curry.LanguageServer.Utils.Uri (since URI/file path canonicalization issues on Windows have been fixed in 0.19)

Version the `.curry/language-server` folder

We'd want to make sure that different versions of the language server can coexist, even if we make breaking changes to the ICurry format (e.g. as proposed in #26 (comment)).

Therefore we should include the language server version in the output directory path (e.g. .curry/language-server-x.y.z) and make sure this version number is bumped (at least) every time there is a breaking change in one of the serialized formats.

Debounce recompilation/linting

In large files, quick edits cause the the language server to lag behind due to potentially slow recompilation.

Investigate vendoring libs and cpm

Similar to the existing Curry compilers (PAKCS and KiCS2) we could vendor our own versions of the libraries and the CPM as Git submodules to remove the runtime dependency on an existing Curry compiler (which is currently configured to use pakcs by default and configurable as curry.languageServer.curryPath).

Add suggestion quick fixes

E.g.

• Pointfree conversions
  • Eta-reductions (\x -> f x to f)
  • Const (\_ -> x to const x)
  • Void (x >> return () to void x)
  • ...
• Common library functions (maybe x id m to fromMaybe x m, fst . runState to evalState, snd . runState to execState, ...)
• Redundant dos (do { x } to x)
• Merging adjacent lets
• Warn (or at least 'info') about Debug.Trace imports
• ...

These suggestions could be similar to what hlint suggests.

Provide language extension completions

Complete known language extensions (inside {#- LANGUAGE ... #-} pragmas)

Implement Quick Fixes

The language server protocol provides a way for "quick fixes"/refactorings to be displayed in the editor:

Ideally, we could implement this for Curry to provide fixes for errors (ideally from the frontend) and suggestions (see #34).

Implement signature help

The language server protocol provides a way to dynamically display the currently edited parameter of a function:

Implementing this for Curry would involve figuring out which argument the user currently edits and determine when to "close" the window (e.g. since Curry support partial application/currying, the user does not have to specify all arguments).

Add arm64 macOS build

Now that GitHub has free M1 runners for open-source, we should investigate providing arm64 macOS binaries in our releases.

Support definition lookup on module identifiers

Currently, we only support it on qualified identifiers. We could extend this by

• ...adding a HasModuleIdentifiers class to Curry.LanguageServer.Utils.Syntax
• ...generalizing resolveQualIdentAtPos to resolve module identifiers too
  • We'd probably also want to rename the function then

Tag unused warnings

Add the unused tag to the corresponding diagnostics (e.g. so that an LSP client can render them in a special way).

Implement Find References

Implement the LSP feature for finding references to a symbol, e.g. looking up all occurrences of a variable.

Automated deployments with GitHub Actions and GitHub Releases

Automatically build and upload binaries for Windows (x64), macOS (x64, ARM?) and Linux (x64) to GitHub Releases whenever a tag is pushed.

Update LSP library and rearchitect reactor

haskell-lsp has been renamed to just lsp and updated to make writing a language server a lot less verbose, see here, for example.

Investigate why code lenses are always 1 edit "too late"

Screen.Recording.2023-07-26.at.18.21.25.mov

Investigate integration with CASS

The Curry Analysis Server System provides a language-agnostic way of retrieving symbol information and more about a Curry program. Since this overlaps with the language server in functionality, it might be nice to integrate it e.g. as another backend.

Detect data import wildcards (X (..)) as imported

Consider the following Curry modules:

-- A.curry
module A where

data X = X { unX :: Int }

-- B.curry
module B where

import A (X (..))

test :: Int
test = _

Entering unX at _ currently suggests an auto-import, even though it is not required.

Shadowing function parameters are not handled correctly

E.g. in

f failed = failed

both faileds should refer to (e.g. through definition lookup aka. ctrl+click) the local parameter and not the failed imported from the Prelude.

Provide import completions

Complete imported modules.

Diagnostics are not cleared properly

Error/warnings are not cleared if no diagnostics are left.

Add an evaluation code lens

Similar to the Haskell language server, add an evaluation code lens. This could use the configured Curry executable (curry.languageServer.curryPath, which is pakcs by default) and then invoke it e.g. like this:

pakcs :load [current module] :eval [expression] :quit

Abstract out paths such as `.curry`, `package.json` etc.

We currently hardcode .curry, .curry/language-server, paths.json and package.json in quite a few places. We should probably move that to a function, at least, and ideally make it configurable too.

Add deprecation tag to completion item for `OPTIONS_CYMAKE`

OPTIONS_FRONTEND should be recommended instead.

Load configuration instead of ignoring it

Currently, the language server ignores the configuration from the client. Since the configuration flow seems to undergo some changes currently (see haskell/lsp#285), we might want to wait for the next release of lsp with this.

Always prefer source locations over interface files during definition lookup

Find symbols in the project's source file, even if the compiler refers to a definition from an ICurry file.

Implement semantic highlighting

Caching

Store compiled ASTs in memory and only recompile on changes.

Add support for preprocessed source code using `currypp`

At the very least, we shouldn't emit errors there and handle it like the compilers.

Code completions

Provide code completions

Add code completions for `OPTIONS_FRONTEND` flags

It would be cool if the language server could provide code completions for the frontend's flags, e.g. -Wno-missing-signatures in OPTIONS_FRONTEND pragmas. Ideally, the language server would query the available flags directly from the frontend.

Support CPM-structured Curry packages

The Curry Package Manager provides a standard facility for managing packages and dependencies in Curry.

Use a standard formatter

Use a virtualized file system

Currently, linting and updates to the symbol database are first performed once a user saves the file. Using a virtual file system we could provide linting in real-time as the user types.

This would involve figuring out how to compile in-memory files using the Curry frontend or, alternatively, regularly saving the text buffer to a temporary file.

Respect `OPTIONS_FRONTEND` settings

For example, setting {-# OPTIONS_FRONTEND -Wno-missing-signatures #-} should cause warnings about missing top-level signatures to disappear.

Provide type hint code lenses for instance methods

Similar to the Haskell language server:

We might want to disable the 'apply' command, since explicit method type signatures are not valid Curry syntax.

Remove submodule dependency on curry-libs

Since the language server finds a Curry installation (like PAKCS) itself, there is no need for a submodule dependency on curry-libs anymore.

Hoogle-like API search

Integrate Hoogle-like API search, in a similar fashion as Currygle.

Implementation notes:

• This could e.g. be implemented as part of a WorkspaceSymbols query

Fetch dependency paths using `cypm deps --language-server`

Instead of trying to resolve CPM packages against PACKAGE_INSTALL_PATH from cypm config we should just use cypm deps --language-server, which exports a list of dependency paths to .curry/language-server/paths.json.

Use log levels from LSP config

Also use the specified log level from the config when it changes (extracted from #21).

Context-aware code completions

Provide context-aware code completions based on whether the user is currently in a type, value or qualifier context (imports/qualified identifiers).

Fetch list of known tools from Curry frontend instead of hardcoding them

Similar to e3eb284, we could fetch a list of known tools for code completion once the upstream PR 56 is merged, instead of hardcoding them like we currently do.

Ignore gitignored files/subfolders

To avoid indexing too much, we could limit it to the non-gitignored files for now.

Interface for module Prelude not found

It also says this

Im getting this error on a fresh cypm new template. Not entirely sure what the problem is, any ideas?

Extra details:
M1 MacOS 14.1.2
Using PAKCS 3.6.1-b1 of 2023-11-16 (swi 9.0)

Cannot find infix operators

In source code like [1,2] ++ [3,4], hovering ++ shows the type, but when trying to go the definition, it shows No definition found. However, in code like (++) [1,2] [3,4], it works.