The Exercism Haskell track is a curriculum, and its test suites are the real contract
Exercism exercises in Haskell.
At a glance
- What is it?
- The exercism/haskell repository holds the practice and concept exercises for Exercism's Haskell track, with stub solutions, example solutions, shared unit tests and a fixed Stack resolver. It suits a maintainer who wants to contribute an exercise, and it is a teaching corpus rather than a library.
- Who is it for?
- Exercism's Haskell track is worth contributing to if you want your Haskell exercise to appear in the track's progression, because the infrastructure around it, the shared test suites, the config.json registry and the automated test runner, is already there and the specification problems are shared across tracks.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 22 days ago.
- What is it written in?
- Mainly Haskell, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 20, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Two kinds of exercise, and only a few concepts are built
The track's scope is stated plainly. Exercism contains two types of exercises, concept exercises and practice exercises. A concept exercise comes with a concept, which is described as a short tutorial explaining a single feature of the language, and its purpose is to test that the student understood the basic use of the concept and to open up the next concept or concepts. The track currently has some concept exercises, and a list of additional concepts yet to be created, with a reference file at `reference/concepts.md` naming the topics. A concept can be ported from another track, and the documentation names the F# and Elm tracks as examples. Practice exercises are the other half, and they are shared globally: you can get a full list of common Exercism practice exercises from the problem-specifications repository and cross-reference it with the Haskell practice exercises directory, then implement any of the missing ones. That cross-reference is the practical entry point for anyone who wants to add something.
Every practice exercise is a package, a stub, a test file and documentation
The directory structure is the specification of what a practice exercise must contain, and it is worth reading as a checklist. The `stack.yaml` has just one line specifying the current Stack snapshot, and the same resolver is used for all the exercises, which removes a whole class of per-exercise dependency drift. The `package.yaml` is in the hpack format and holds all dependencies and build instructions for the exercise, and one of the properties it tracks is the version of the exercise. The `src/ModuleName.hs` file is the stub solution, and the `test/Tests.hs` file is the test suite. The `.docs` directory holds `instructions.md`, and the `.meta` directory holds `config.json`, `hints.md` and an `examples` directory containing a success-standard example. The layout in the repository is:
└── practice
├── accumulate
│ ├── package.yaml
│ ├── stack.yaml
│ ├── src
│ │ └── Accumulate.hs
│ ├── test
│ │ └── Tests.hs
│ ├── .docs
│ │ └── instructions.md
│ └── .meta
│ ├── examples
│ │ └── success-standard
│ ├── config.json
│ └── hints.mdconfig.json is the registry, and the sequence order is the fetch order
One file governs the whole track, and the documentation says so without hedging. `config.json` at the repository root is where every exercise has to be registered, and it has a unique name and a difficulty. The sequence order in that file is also the default order in which the exercises are fetched, so the order a student sees is data, not code. That makes it a curated curriculum in a JSON document, and it is the first file to look at when you want to know where the track is heading. The repository root also holds a `config/` directory, a `reference/` directory containing the concept and exercise authoring guides, a `docs/` directory with `ABOUT.md`, `EXERCISE_README_INSERT.md`, `INSTALLATION.md`, `LEARNING.md`, `RESOURCES.md` and `TESTS.md`, a `bin/` directory with a `fetch-configlet` script, and `.github/workflows/tests.yml` for continuous integration. The track's public page is at exercism.org/tracks/haskell.
Test suites are shared across tracks, and they have to run fast
The tests are where the quality of a track lives, and the contribution rules around them are specific. Most unit tests are shared between language tracks, and you may update a test suite with new unit tests, following the documentation on pushing new unit tests to Exercism and the test suite principles. The track keeps a list of exercises from which new unit tests can be pulled into it. There is one constraint that shapes everything else: the whole test suite must run with the sample solution within a couple of seconds. That is why the example solutions exist in a `success-standard` variant inside `.meta`, because they are the reference implementations the tests are run against to prove the tests pass, and a suite that takes minutes would make continuous integration useless. The documentation also has a page for updating an exercise test suite and a link to the shared anatomy documentation, which is described as a general description of all the files and directories that are not explicitly described in the track's own documentation.
A bug report can be a typo, and a stub is not a solution
The contribution guide is unusually specific about the small cases, which is a good sign about how the track is run. Typical examples for a bug are a typo, a missing test case, or an unclear or ambiguous problem description. The documented routes are three: if you are unsure whether you have really found a bug, just ask; to report a bug you can create an issue; and if you already have a fix for it, you may submit a pull request. Review is also part of the job. If you have a dedicated opinion you are welcome to write a comment on an issue or a pull request, and the documentation asks you to be detailed and include reasons, links or arguments to support your opinion. The stub solution in `src/ModuleName.hs` is the starting point a student receives, and the example solution in `.meta` is the reference the tests must pass against. Keeping those two in step is a recurring maintenance task in a track with this many exercises.
Running the tests locally is a Stack and HLint workflow
The development tooling is named in the table of contents and in the repository contents rather than in long prose, and the pieces are standard for the Haskell ecosystem. There is a `bin/fetch-configlet` script, which is the Exercism utility for fetching configuration and exercise content, and a GitHub Actions workflow file at `.github/workflows/tests.yml` with a Tests badge on the main branch. The test suite lives in the `test` directory, and the documentation has a dedicated page for running tests and another for running HLint, the Haskell linter, so the linting step is treated as part of the loop rather than an optional extra. The install instructions for a student are kept in `docs/INSTALLATION.md`, and the track's own documentation set also covers `ABOUT.md`, `LEARNING.md` and `RESOURCES.md`, so the student-facing content and the contributor-facing content are separated. The project also carries a `TAGS.md` file at the root, which is where exercise tags for the track are recorded.
Where an exercise track is the wrong thing to learn from
Two limits are worth naming. The first is that the exercises are designed around a feedback loop that assumes the Exercism platform. The student writes a function, the test suite tells you what is wrong, and the exercise is small enough to finish in a sitting. That is a good way to learn a language's syntax and a poor way to learn how to structure a Haskell program, because every exercise is one file with one function and no module boundaries to design, no dependencies to reconcile and no interface to keep stable. The alternative to weigh against is a project of your own with a real domain, where the type errors you hit are the ones you would hit at work rather than the ones chosen to teach a single concept. The second limit is about the track's own growth. The repository's topic list contains the marker `community-contributions-paused` alongside `maintained` and `exercism-track`, which is an unusual and honest pair of labels: the track is looked after, but new community contributions are not currently being taken. That is the state to check before you invest time in authoring an exercise, and it is also the reason the concept list in `reference/concepts.md` is described as topics yet to be created rather than a backlog anyone is actively working through.
Editorial conclusion
Exercism's Haskell track is worth contributing to if you want your Haskell exercise to appear in the track's progression, because the infrastructure around it, the shared test suites, the config.json registry and the automated test runner, is already there and the specification problems are shared across tracks. It is a poor fit as a self-study corpus, because the exercises are written to be solved in a browser with the test suite as feedback, and a Haskell developer who wants practice will usually write their own project instead. It is also a poor fit if you need a maintained, continuously growing exercise set, because the repository's own topic list records community contributions as paused even though the track itself is marked maintained. Before contributing, read `reference/implementing-a-concept-exercise.md` and `reference/concepts.md` for what is already covered, and check `config.json` because every exercise has to be registered there with a unique name and a difficulty. The last push to the repository was on 2026-10-01.
Frequently asked questions
What is in the Exercism Haskell track repository?
It holds the Haskell practice exercises and concept exercises. Each practice exercise has a stack.yaml with a single Stack snapshot, a hpack package.yaml, a stub solution in src, a test suite in test/Tests.hs, a .docs directory with instructions and a .meta directory with config.json, hints and an example solution.
How do I add a new exercise to the Exercism Haskell track?
You cross-reference the common Exercism practice exercises in the problem-specifications repository with the Haskell practice exercises directory and implement any of the missing ones. For concepts, you can port one from another track such as F# or Elm, or develop one of the topics listed in reference/concepts.md. Every exercise must then be registered in config.json with a unique name and a difficulty.
What is the speed requirement for Exercism Haskell test suites?
The whole test suite must run with the sample solution within a couple of seconds. That is why each exercise ships an example solution under .meta, since that example is what the tests are run against to confirm they pass.
How are new unit tests added to an Exercism Haskell exercise?
Most unit tests are shared between language tracks, and the track keeps a list of exercises from which new unit tests can be pulled in. The contribution guide points to the documentation on pushing new unit tests to Exercism and to the shared test suite principles, and asks that new tests follow those principles.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/exercism-haskell)Was this useful?