Thanks to those who came to the meeting earlier. For the benefit of those who aren't at ZuriHac, I've attempted to summarise. There was much discussion so apologies if I've misrepresented anything. Cheers, Adam Date: 7th June 2026 Present: Adam, Jaro, Malte, Rodrigo, Simon PJ, Teo (CLC), Ben, Igor, Marten, other ZuriHac attendees observing 1. Extra Commas proposal We narrowed our options to three: - Accept the "maximal" version of the proposal (applying to all commas) - Accept the "minimal" version of the proposal (only commas in import/export lists) - Reject However there was not consensus about which option to adopt. Jaro as shepherd will run a vote on the mailing list between these options. 2. String Interpolation proposal There is broad consensus to accept this, and gratitude for Brandon's hard work. While there are open questions about the final `Interpolate` class API, and whether it will be accepted by the CLC as-is into `base`, the implementation can be merged and the class exposed through `ghc-experimental` to allow for experimentation. It should thus be made clear to users that this means the API may yet change. 3. Known-keys work Simon and Rodrigo explained the recent progress on redesigning the known-keys mechanism to allow for moving code from `ghc-internal` back to `base`. They will investigate options for supporting multiple `GHC.Essentials` modules (in `base`, `ghc-internal` and perhaps `ghc-experimental`). 4. CLC interactions The division of responsibility between the GHC SC and CLC is generally clear, but we could make the proposer's experience easier by helping navigate the committees. The shepherd of a proposal should be responsible for communicating with the CLC where necessary, rather than expecting proposers to do so. Typically GHC proposals should expose library changes through ghc-experimental in the first instance, so should not formally require CLC approval, but it makes sense to invite CLC comments early on APIs that are ultimately intended to live in `base`. 5. Proposals process We discussed possible refinements to the process. - When an author first submits their proposal, a shepherd should be assigned and the committee invited to discuss and provide feedback. We could imagine assigning shepherds immediately on proposal submission, but ideally proposals would have a period for community discussion first. - An automatic comment on PRs pointing out key aspects of the process to authors, notably that they need to submit explicitly, would be helpful. - Following an explicit discussion period, the shepherd should request a decision from the committee. Proposals should not change significantly during the decision phase. If there is a need for changes, the proposal should return to the discussion phase. It should be made clear which proposals are awaiting committee decisions and which are under community/committee discussion. Following a batch of discussion, the shepherd (not the proposer) should be responsible for summarising the conclusions and responding to the proposer. - We want to make the process easier for people who actively contribute patches to GHC, as they are the people most likely to implement changes. - Perhaps accepted-but-not-implemented proposals should be unaccepted if they are not implemented within a reasonable period (e.g. 2 years). - It would be good to curate the accepted proposals more, e.g. structuring them by category. Perhaps we could list them in the user's guide, although they might be redundant with the rest of the guide. - It would be good to view proposals as more of a collective/team effort, rather than exclusively the responsibility of a single proposer. The process involves many different skills: coming up with an idea, writing a proposal, responding to community feedback, and implementing the changes. We may be able to encourage matchmaking between people. In particular, some people are willing to be "proposal buddies" who can help authors with the feedback/discussion stage; this wouldn't be a mandatory assignment like the shepherd, and wouldn't necessarily be a committee member. We can try to identify a list of willing individuals. - Brandon has raised the issue of GitHub PR top-level comments having poor UX. We are generally willing to try other options for a threaded conversation accompanying the proposal (most likely a GitHub discussion linked from the PR comment, with inline comments allowed on the PR but top-level comments disallowed). 6. Status of Template Haskell Teo raised the question of authority to make changes to Template Haskell and its libraries. There was general agreement that: - Major changes to how Template Haskell works, which necessarily involve changing the compiler, should go through the proposals process. - Smaller changes, including library API changes in the template-haskell package, can be decided by the package maintainer (currently Teo). The CLC is responsible for stewarding the library (i.e. ensuring it has an active maintainer). This is the same situation as for other core libraries, such as `containers`. On 06/06/2026 12:52, Adam Gundry wrote:
Hi everyone,
Scheduling is tricky but I suggest we could meet over lunch tomorrow, say 1pm in the courtyard near the food trucks? Everyone at ZuriHac is welcome, I don't think we need limit it to SC members. (Apologies to Erik that I don't think adding a remote option is feasible.)
Possible topics to discuss (feel free to add your ideas):
* Status of current proposals (e.g. extra commas, string interpolation)
* Interactions with CLC: the division of responsibilities is now fairly clear, but can we make the process easier for proposers (e.g. the recent discussion of string interpolation first at the GHC SC then at CLC)?
* Potential process improvements - UX for discussions - Encouraging collaborative proposals rather than expecting one author to drive the process? - Avoiding the accumulation of merged, accepted-but-not-implemented proposals
Cheers,
Adam
On 29/05/2026 21:18, Rodrigo Mesquita wrote:
Hi Adam,
I’ll be there from Thursday for HIW (where I’ll give a talk on the debugger).
I’d be happy to join in on such a meeting.
Cheers, Rodrigo
On 28 May 2026, at 09:30, Adam Gundry <adam@well-typed.com> wrote:
Hi everyone,
Who is planning to attend ZuriHac this year, and is there any interest in having an in-person GHC SC meeting / language design discussion / general chat by the lake?
FWIW, I'll be around for the full event including HEW and HIW.
Cheers,
Adam
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England