Haskell Foundation May Update

Haskell Foundation May Update

Technical Agenda

Text-Utf8 Proposal

The proposal was accepted! Bodigrim and Emily Pillmore did a fantastic job specifying the work and responding to enthusiastic feedback. Thank you to all the reviewers and commenters for helping, and we look forward to progress updates.

Unified Installer

We are excited to announce that Chris Dornan has volunteered to take the project lead role in conjunction with Julian Ospald (the author of ghcup), and will be working with members of the community to create a proposal.

GHC Support

We have officially signed a contract with Well-Typed to continue support of GHC development. HF has taken over this relationship from Microsoft Research, and GitHub stepped up with a sizable earmarked donation. Thank you to GitHub, and thank you to Well-Typed.

Affiliations and Alliances

Haskell Love

We <3 Haskell Love, and are so happy to affiliate with them! Their next conference is on September 10th, so show them some Love. Maybe you’d like to submit a talk?


Do you love hacking in Haskell? ZuriHac 2021 will be a virtual event June 18th - June 20th, and our own CTO Emily Pillmore will be speaking, along with John Hughes, Veronika Romashkina, Sandy Maguire, and Ollie Charles. We’re excited, and so happy to affiliate with such a great event.


The Integrated Haskell Platform open source project has affiliated! We are excited to have this Haskell web framework aboard, and the new Haskellers it is bringing into the community.


Website Refresh

The new Haskell Foundation website is up and running. We are accepting issues and PRs, don’t be shy!



Project Matchmaker

A platform for open-source contributors to discover Haskell projects to get involved with! From each according to their ability, to each according to their needs.

Shout-out to Jonathan Lorimer for his work on the project!


The HF website is Hakyll-based, although not currently using much of that functionality. We would love for it to be more data-driven, and of course stylish. Additionally, members of community file issues that may need to be addressed. Better workflow and staging? Yes, please!


We are in the early days for our Community Task Force, and are looking for people interested in being community managers and moderators. Our goal is to focus on communication, mediation, and conflict resolution, to make our community open, welcoming, and respectful.


Cabal is under new maintainership, and things are moving forward! This foundational piece of Haskell tech needs love, modernization, and some deep problem solving skills.

Matrix Builder

Help keep Haskage packages working!


Thank you to our sponsors, you make the HF possible.





So much good news, it’s really nice after all these years to see what feels like a cohesive direction for the community.

Is the UTF8 text work based on their text-utf8 package’s work? I’m also curious if backpack could be used to let people choose their internal encoding? For several years I’ve been wondering if using succinct data structures over utf8 encoded text would give us the best of all worlds - IIRC the overhead of using something like CsPoppy is only about 1.25% overhead (or it was something drastically smaller than that again), and doing so would give us constant time indexing and compact storage.

1 Like

There’s some discussion about the details of using backpack in HF Tech Proposal #1: UTF-8 Encoded Text.

That discussion a bit different though, it is about replacing string by text (and others) in base. I think just having a different internal representation (utf8 vs utf16) can be done just fine without backpack, with something like a phantom type parameter.

Good news, thanks :slight_smile:

There is a reference to the matrix builder at the end, what about it? Would be great to get it running GHC 9.

The situation with matrix builder is it needs a volunteer or two to help put in some elbow grease. We’re working on understanding and coordinating the current state and how people can help at this time.

Is the UTF8 text work based on their text-utf8 package’s work?

Not really, see Prior Art section at https://github.com/haskellfoundation/tech-proposals/blob/main/proposals/002-text-utf-default.md#timeline
While previous stabs on UTF8 are important to get a clearer understanding of transition challenges, we decided to start from the scratch.

I’m also curious if backpack could be used to let people choose their internal encoding?

Please see Compatibility Issues section ibidem. Supporting both encodings at once (via Backpack, or via a cabal flag, or via a phantom parameter) puts an undue double burden on text maintainers and on downstream packages. UTF8 is a complex beast and implies a whole set of different constraints on internal design, it’s not like we can just s/16/8/g.


I’ve been wondering if using succinct data structures over utf8 encoded text would give us the best of all worlds

I was thinking about succinct data structures too, but decided against it.


Thanks, all of that sounds great - I’m happy to see these optimisations happening, I’m fairly familiar with them: https://github.com/text-utf8/text-utf8/pull/1

I agree on both your other points too, I think that a succinct view over a UTF8 encoded Text is probably a better idea, and can be a package of its own which implements the same interface (this might be one good reason to use backpack actually, and probably a better reason than supporting multiple encodings)

Ah, interesting, I have not seen your PR before. I’m using popcount in my branch, it would be interesting to check whether multiplication by a magic constant can make it even faster.

It’s a very cute trick, and doesn’t require proper SIMD instructions. I believe it would work well with SIMD as well though. Hit me up on IRC if you want to chat about it :slight_smile:

This sounds like a cool project :slightly_smiling_face: It’s a pity HF missed the opportunity to collaborate with an already implemented project issue-wanted with the same goal. Not to mention, that issue-wanted was implemented during GSoC under the official Haskell.org organization.

If one of the HF goals is to be a community glue, I believe it should try to coordinate the contributions of various people from the Haskell community.


It does seem we have some room for improvement in asking the community for prior art before embarking on a project. Our current model is to ask within the HF to see if anyone is aware of work in a given area, but we should reach out further to find projects that may be solid but have not taken off. I will shortly recommend this as a routine practice within the HF.

I went to look at issue-wanted, but I couldn’t learn much about it from a first inspection. Is there a description somewhere of what the project does? The readme at https://github.com/kowainik/issue-wanted has a very high-level introduction and then a discussion of the project’s architecture / getting it to run, etc. I’m more interested in learning about its user experience or interacting with the application itself – is this documented / demonstrated anywhere? Thanks!


Hi, I am surprised because I think this is the first time I’ve heard about issue-wanted, and Google showed me projects like Contribulle before your project. :frowning:

Due diligence has been added to the HF proposal template and we shall give much more attention to this in the future, because we simply do not wish to re-invent the wheel if production-ready solutions already exist in our ecosystems.


Love to see the impact that HF is having already. Keep up the great work.