Summer of Haskell

GSoC 2025 Ideas

This is a list of ideas for contributors who are considering to apply to Google Summer of Code 2025 for Haskell.org

For project maintainers

Are you working on a Haskell project and you could use the help of a contributor during the summer? Consider adding it as an idea here! You can contribute ideas by sending a pull request to our github repository (example from 2024). If you just want to discuss a possible idea, please contact us.

What is a good idea? Anything that improves the Haskell ecosystem is valid. The GSoC rules state that it must involve writing code primarily (as opposed to docs).

Projects should be concrete and small enough in scope such that they can be finished by the contributor. Past experience has shown that keeping projects “small” is almost always a good idea.

Important changes since 2021/2022: In the past, GSoC projects were expected to take up the equivalent of full time employment for a student. In 2021, this was reduced to half time positions: students were expected to work around 175 hours in a 10 week period. Since 2022, contributors now have the choice between a larger (around 350 hours) or a smaller project. Ideas should indicate in which category they fall.

Projects should benefit as many people as possible – e.g. an improvement to GHC will benefit more people than an update to a specific library or tool, but both are acceptable. New libraries and applications written in Haskell, rather than improvements to existing ones, are also welcome.

For students/contributors

We have added some tips on writing a proposal here. Please be aware that:

Table of Contents

  1. CodeWorld GHC Update
  2. Language Server support for cabal.project files
  3. Qualified aliases in Liquid Haskell

CodeWorld GHC Update🔗

CodeWorld is a web-based educational environment for learning computer science using Haskell. It is based on GHCJS, an old project to compile Haskell to JavaScript with a modified GHC compiler.

GHCJS is no longer a good choice, as it is difficult to keep up to date with the latest GHC versions. However, modern versions of GHC have built-in backends for both JavaScript and WebAssembly, which are more reliable and easier to maintain, and kept up to date as part of the main line of GHC development. This project would involve updating CodeWorld to use one of the new GHC backends for JavaScript or WebAssembly.

This would involve updating the build system, and making any necessary changes to the CodeWorld runtime to work with the new backends.

The scope of the project can be adjusted based on the desired time frame and experience of the mentee. Some questions include:

Mentorship

Difficulty and size

The difficulty of this project is medium, as there are significant infrastructure and build system challenges to address. Depending on choices made, this may become hard.

The minimum size of this project is 175 hours, but there is likely more work depending on the mentee’s desired scope and ideas.

Language Server support for cabal.project files🔗

Goals

Introduce a new Haskell Language Server plugin, which provides IDE-features for cabal.project files.

Some possible features include:

The scope of the project can be adjusted based on the desired time frame and experience of the mentee. Some of these implementations can draw inspiration from the corresponding implementation in the hls-cabal-plugin.

Background

cabal.project files are often needed to configure how your project should be built. Haskell developers will often write and edit these files during their development process but as of yet, Haskell Language Server (HLS) provides no IDE support for them.

Since HLS already provides IDE features for .cabal files it seems a natural next step to add a similar cabal.project plugin to HLS which provides IDE support for cabal.project files.

Outcomes

The main outcomes are pull requests with the implementation, tests, and code documentation of the implemented features.

A secondary outcome is a blogpost describing the experience and the results of the project.

Difficulty and Size

The difficulty of this project is medium, as there are two rather big existing projects that developers need to understand in order to provide improvements.

The minimum size of this project is 90 hours, but this can easily be extended to 175 as there is likely more work depending on the mentee’s desired scope and ideas.

Required Skills

Project Mentor

Qualified aliases in Liquid Haskell🔗

Goals

Update the implementation of Liquid Haskell to allow referring to type and predicate aliases in qualified form.

Background

Liquid Haskell is a verification tool for Haskell programs. The programmer writes specifications for these programs, and Liquid Haskell checks if the programs actually meet the specifications.

Recently, the Liquid Haskell implementation went through a refactoring to improve name resolution. Much of the names in the specification language can be qualified now, in order to dissambiguate equal names that come from different modules. There is an exception though, when it comes to type and predicate aliases. For technical reasons, this constructs have been left behind in the refactoring.

As the reference documentation explains, type aliases can be used to shorten specifications. Instead of writing a spec like:

{-@ length :: [a] -> {v:Int | v >= 0} @-}

one can write

{-@ type INat = {v:Int | v >= 0} @-}
{-@ length :: [a] -> INat @-}

Unfortunately, if there are multiple INat aliases in scope, Liquid Haskell does not allow to qualify the name to disambiguate. For instance, the following specification is rejected with a message that says that SomeImport.INat is not in scope.

{-@ length :: [a] -> SomeImport.INat @-}

This project is to analyze the implementation and to design and implement a solution both for type and predicate aliases. There is a corresponding issue in the Liquid Haskell repo.

Outcomes

The main outcomes are a pull request with the implementation, tests, and code documentation, and a discussion of the analysis and the design in the corresponding issue.

A secondary outcome is a blogpost describing the experience and the results of the project.

Size

Project size should be near 175 hours. The project will require a fair amount of reading of existing Haskell code, and building an understanding of how it works. Familiarity with the verification mechanisms is not necessary a priori, though some user-level understanding of Liquid Haskell is going to be needed to write tests.

Required Skills

Project Mentor