This is a list of ideas for students who are considering to apply to the Summer of Haskell. You can contribute ideas by sending a pull request to our github repository.
Please be aware that:
- This is not an all-inclusive list, so you can apply for projects not in this list and we will try our best to match you with a mentor.
- You can apply for as many ideas as you want (but only one can be accepted).
- Some general tips on writing a proposal are discussed here.
Table of Contents
- CodeWorld projects
- Djinn with in-scope terms for Intero
- Last Mile for `cabal new-build`
- GHC Performance
- Improve GHC Performance test suite
- Improve the Hackage matrix builder
- Improve the Shake-Based Hadrian Build System for GHC
- Haskell IDE Engine with LSP Support
- Build a transactional embedded key-value store
- Safe streaming with linear types
- Verify base using Liquid Haskell to ensure totality of functions
Chris Smith has kindly provided funding for two students to work on the CodeWorld project.
CodeWorld is an educational environment using a variant of Haskell. It provides a simple mathematical model for geometric figures, animations, and interactive and multi-player games. The web-based programming environment supports this educational mission with a zero-setup editor and compiler, easy sharing and cloud storage of projects, and the ability to run programs right in the web browser using GHCJS.
The list of ideas for CodeWorld can be found here.
Mentors: Chris Smith
Djinn with in-scope terms for Intero🔗
The basic idea is that Intero would feed type information of the current set of modules into Djinn’s API and then you can write
:djinn and get a program for it. Djinn would need to be extended with support for list literals like
[a], but otherwise it could be a very fancy way to have code completion. Then Emacs and Intero could provide code completion based on this e.g.
map _ [1,2,3] in a
String-typed position would yield a suggestion like
Some work on this has already happened on the
Mentors: Chris Done
Last Mile for `cabal new-build`🔗
new-build system has help solved many of the problems that plagued Haskell development for years. You can read an introduction to
cabal new-build on Edward Yang’s blog While the work is exciting it is not quite ready for prime-time.
The project is looking for an intrepid Haskeller that is willing to help get
cabal new-build out the door. More specifically the project aims to help port some of the commands from standard
cabal that have not been ported yet, many of which are kept track of with this
Ideally, a candidate hoping to work on this project will have some experience with
cabal, but we understand that the Summer of Haskell is for learning too :)
Mentor: Someone at Galois, Inc.
ghc? Think you can make it faster?
This project has the aim of improving the performance of
ghc. As the language that
ghc accepts has become more intricate the compiler has seen a slowdown in compile times. This is a known problem with several paths forward: GHC-Wiki page on performance
The ideal candidate will have some experience with developing on
ghc. That being said, we understand that the Summer of Haskell is also about learning.
Mentors: (José Manuel Calderón Trilla | Iavor Diatchki | Trevor Elliott) @ Galois, Inc.
Improve GHC Performance test suite🔗
The GHC testsuite’s performance tests tends to be a constant source of busy-work as it requires that contributors manually bump performance numbers and propagate these changes across platforms. Moreover, the testsuite is poor at noticing performance regressions due to false positive failures (due to spurious environmental differences) and false negatives (due to the rather generous acceptance windows that many tests have).
We would like to replace the mechanisms for tracking performance metrics in the GHC testsuite and nofib with a scheme more amenable to automation. This project will involve working with GHC developers to develop such a scheme and implementing tooling for the automation generation, tracking, and visualization of the resulting data.
For more info see https://ghc.haskell.org/trac/ghc/ticket/12758.
Mentor:: Ben Gamari
Improve the Hackage matrix builder🔗
This project is to help with the development and exploitation of the Hackage matrix builder. This is an existing project. For an idea of what this does, see a page for an example package.
The Hackage matrix builder provides a build compatibility test service to the Haskell community for all the packages published on Hackage. Currently it answers the question “which versions of GHC does this package build with”, which includes checking the Cabal solver can find a solution and have that solution build successfully. It works by building all versions of all packages with several GHC versions. It relies on clever nix-style caching to make this reasonably efficient. So this is a kind of QA or CI service for everyone. There is also a lot of potential to use this kind of infrastructure for additional purposes.
The matrix builder project is run by Herbert Valerio Riedel hvr who is happy to act as a project mentor and help direct a student to useful tasks that fit with the student’s interests and skills. This might involve making improvements to the build toolchain, web programming or better integration with the main Hackage website to better exploit the information gathered. The student would also have the opportunity to work with volunteers who work on the Hackage and Cabal projects.
Mentors: Herbert Valerio Riedel
Improve the Shake-Based Hadrian Build System for GHC🔗
Advance the Hadrian build system to the point that it can replace the existing GHC build system in practice, including specifically adding support for cross compilation, source and binary distribution generation, dynamic way, and test suite support. Most of these issues are detailed in the “Current Limitations” section of the README.md
This project may well entail working further on the Shake tool itself to increase its featureset as a prerequisite for use of these features in hadrian.
Mentors: Hadrian team
Haskell IDE Engine with LSP Support🔗
Haskell IDE Engine aims to be the universal interface to a growing number of Haskell tools, providing a full-featured and easy to query backend for editors and IDEs that require Haskell-specific functionality.
- Currently the focus is on full LSP(Language Server Protocol) support, which will allow HIE to interface with a wide variety of editors, including Visual Studio Code, Emacs and NeoVim.
- Integration with existing Haskell tooling such as Intero, ghc-mod, HaRe, hindent etc. will also be required to implement features such as autocompletion, go-to definition, type insertion, linting and so on.
There has already been some work done on LSP support here.
Mentors: Alan Zimmerman
Build a transactional embedded key-value store🔗
The zoo of NoSQL systems is large, confusing and ever changing. The majority of systems is geared towards big deployments and are thus often networked/distributed. This of course requires an additional deployment and configuration step. Furthermore, only very few provide fully ACID-compliant transactions which puts additional burden on an application developer who wants strong guarantees.
In this project a new embedded, transactional and fully ACID-compliant key value store is developed in Haskell that can be used by applications directly or serve as a backend for a bigger system.
The proposed (but not strictly fixed) general approach is to copy the core design of the Lightning Memory-Mapped Database (LMDB) and/or RavenDB’s Voron engine which both follow the same design based on copy-on-write B+-trees. This is a comparably simple reader performance oriented design which should allow a student to implement several functioning (yet unoptimized) deliverables during a summer. For more information see: LMDB’s homepage, LMDB design paper, RavenDB’s homepage, Voron source code.
Mentors: Steven Keuchel
Safe streaming with linear types🔗
Proposed solution to the problem of writing safe and efficient have abounded since Kiselyov argued against lazy IO.
Streaming libraries are typically of one of two kind:
- Safe at their core at the cost of expressiveness: such library model stream transformers rather than stream. They often also provide unsafe escape hatches for the cases where the model is too restrictive. The
conduitlibrary is of that form.
- Expressive, by modelling streams as first-class objects, but unsafe. Such library embraces the fact that the escape hatches are the key to expressiveness and place them at the core of their model. The
streaminglibrary is of that form.
This project consists in adapting the
streaming library, so that it leverages the features of a prototype version of GHC that includes support for linear types in order to make it safe.
The key observation is that the unsafety of
streaming is precisely one of linearity (or, rather, lack thereof), a linear version of
streaming would have essentially the same feel as the existing, unsafe, library. Nonetheless, the modifications and additions to the
streaming API to cope with linearity will require significant implementation and design effort.
Reference: Retrofitting linear types
Mentors: Arnaud Spiwack (Tweag I/O)
Verify base using Liquid Haskell to ensure totality of functions🔗
The base contains many partial functions that are poorly documented. Liquid Haskell can be used to verify that all functions are total (by restricting the domain of the functions input with refinement types).
Though Liquid Haksell comes with some speficiations for base, these specifications:
- are not checked against the base implementations and
- are not part of the base libraries.
Inspired by https://github.com/aelve/haskell-issues/issues/52
Mentors: Niki Vazou