- ghc-steering-committee

Please review #696: Splitting out stable interfaces from template-haskell
by Adam Gundry 14 Jul '25

14 Jul '25

Dear Committee, Teo Camarasu proposes to split out smaller, more coherent packages with more stable interfaces from the template-haskell package: https://github.com/ghc-proposals/ghc-proposals/pull/696 https://github.com/TeofilC/ghc-proposals/blob/wip/th-lift-and-quasiquote/pr… I'd like to nominate Sebastian as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process 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

9 11

Stepping down from the Steering Committee
by Eric Seidel 19 May '25

19 May '25

Hi folks, I have not had time to participate in Committee activities for a few months now. And upon reflection, I don't think that will change in the near future. So I think it's time for me to step down from the Committee and make room for someone else with more capacity to devote to improving Haskell. It makes me sad because I still care deeply about Haskell and its community. But I think it's the right decision for me and for the community. Thank you all, it's been an honor to serve. Eric

3 2

Please review #632: introduction of new language editions (inc. GHC2024)
by Adam Gundry 06 May '25

06 May '25

Dear Committee, I propose to amend the process for introducing new language editions, such that GHC always uses the latest language edition by default. In particular this would change the default language edition to GHC2024 (it currently remains GHC2021): https://github.com/ghc-proposals/ghc-proposals/pull/632 https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposal… https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposal… I'd like to invite Simon Marlow to be the shepherd. (Originally I was shepherding this amendment myself, in the hope that it would be a quick amendment in time for GHC 9.10, but that was clearly a forlorn hope!) Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process 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

9 10

#668: Allow reserved identifiers as fields in OverloadedRecordDot, recommendation: accept
by Adam Gundry 06 May '25

06 May '25

Dear Committee, In the interests of getting things moving on proposal #668 from Matt Parsons, I'll shepherd it myself, and recommend we accept it. https://github.com/ghc-proposals/ghc-proposals/pull/668 This is a small amendment to the OverloadedRecordDot extension to allow reserved identifiers as field names. For example, this program is currently rejected with a parse error, but would be accepted: import GHC.Records x = foo.type -- parse error, "type" is a reserved identifier data T = MkT Int foo = MkT 42 instance HasField "type" T Int where getField (MkT x) = x While "type" is not a valid field name in a traditional Haskell record data type, there is nothing stopping a user defining their own instance for `HasField "type" r a`, and some users would like to do so (e.g. when using HasField to interface with a database). Attempting to use such an instance with OverloadedRecordDot runs into this parse error. However the presence of the dot syntax means there is no ambiguity in what the user means. Even if a user wrote `x.type` by accident, they are likely to get better diagnostic information if the parser accepts the program. The only issue I see is that some syntax highlighters unaware of this change may incorrectly highlight such record projections as keywords. Please indicate whether you are happy to accept this proposal. 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

10 18

Please review #687: Monad of No Return
by Adam Gundry 16 Apr '25

16 Apr '25

Dear Committee, Benjamin proposes to revive and move forward the Monad of No Return proposal: https://github.com/ghc-proposals/ghc-proposals/pull/687 https://github.com/L0neGamer/ghc-proposals/blob/amending-mrp/proposals/0000… I'd like to nominate Matthías as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process 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

4 5

Re: [ghc-steering-committee] #668: Allow reserved identifiers as fields in OverloadedRecordDot, recommendation: accept
by Sebastian Graf 14 Apr '25

14 Apr '25

I vote B > A > C > D as well, barring resolution of a small confusion I raised in the proposal discussion.

2 1

Haskell.org mailing list status
by Ben Gamari 21 Mar '25

21 Mar '25

Hi all, As you may have noticed, yesterday brought an unexpected influx of traffic from haskell.org's mailing lists. This was the result of fixing an interruption in mailing list message delivery which began in late February as a result of on-going infrastructure migration efforts. We are monitoring the situation to ensure that this issue does not recur but if you see anything amiss don't hesitate to contact admin(a)haskell.org. Thank you for your understanding and help! Cheers, - Ben

2 1

GHC Steering committee
by Simon Peyton Jones 20 Mar '25

20 Mar '25

Colleagues Is email service to the GHC Steering Committee now working again? If not, it's a bit of a problem. If this message gets through, presumably it's working. Simon

3 2

#686: Amendment to MultilineStrings, recommendation: accept
by Malte Ott 20 Mar '25

20 Mar '25

Dear committee, in https://github.com/ghc-proposals/ghc-proposals/pull/686 Brandon Chinn proposes to slightly modify the recently accepted MultilineStrings proposal: "For the calculation of whitespace prefix removal string gaps (i.e. the / / syntax) should be regarded as non-whitespace." This is technically a breaking change so we should deliberate on it, but I don’t see why anyone would come into this situation in the first place, so I don’t think we should dwell on this. A motivation for the change is that it is easier to implement. I am torn whether it is more or less surprising to users, with maybe a small tendency to less surprising, so I recommend we go with it. The committee could decide to be annoying about this. This is a not strongly motivated change which theoretically changes the semantics of a released extension without warnings or compile errors. However, the extension would surely count as experimental if we were already using the classification we agreed upon. And this tiny change has already been merged as part of a bug fix and I think we should let this pass out of respect to our implementors. Please voice your opinions, I aim to declare this proposal accepted in 7 days. Best Malte

3 2

#621: Linear constraints, recommendation: accept
by Jakob Brünker 20 Mar '25

20 Mar '25

Dear committee, Arnaud Spiwack and Jack Hughes propose to introduce linear constraints. These work analogously to linear functions - as can be seen with the new syntax, which is %1 =>, reflecting the existing %1 ->. The motivation is that these constraints make it possible to design linearly typed APIs that are more convenient to use: Without the linear constraints, tokens would have to be passed manually into each function in these cases. The proposal also introduces dupable classes, which can be used multiple times even when they appear in a linear context, but cannot be passed to an unrestricted function. This is necessary to make some API designs work, see the proposal for details. To me, it seems that this proposal or something like it is necessary to unlock the full potential of linear types. The proposal lays out why monadic API designs don't provide the same benefits, and while there are potential future GHC developments that could make using it even more convenient (existential types, strict let improvements; see proposal), I believe it would already be sufficiently useful with today's GHC to be a valuable addition. Thus, I recommend acceptance. Please read through the proposal and voice your opinions. Best, Jakob

3 4