March 2025 - ghc-steering-committee

Please review #669: Initial categorization of language extensions
by Adam Gundry 07 Aug '25

07 Aug '25

Dear Committee, Trevis Elser proposes a classification of (some) language extensions based on previous work in proposal #601 establishing categories: https://github.com/ghc-proposals/ghc-proposals/pull/669 https://github.com/telser/ghc-proposals/blob/initial-extension-categorizati… I'd like to nominate Malte Ott 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

7 8

#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

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 20 Mar '25

20 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 19 Mar '25

19 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

ghc-steering-committee mailing list deliverability issues
by Adam Gundry 19 Mar '25

19 Mar '25

Hi everyone, It has come to my attention that there are email deliverability issues affecting the ghc-steering-committee(a)haskell.org mailing list (and probably other haskell.org mailing lists). At least, I have personally not received most email sent to haskell.org lists since mid-February. Has anyone else been affected? You can see what you may have missed in the online list archives: https://mail.haskell.org/pipermail/ghc-steering-committee/ I'm trying to get the issues resolved at the haskell.org level, but it may take some time given limited volunteer administrator bandwidth. Cheers, Adam P.S. Apologies if you receive this twice, as I'm BCCing the whole committee individually. -- 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

8 9

#668: Allow reserved identifiers as fields in OverloadedRecordDot, recommendation: accept
by Simon Peyton Jones 14 Mar '25

14 Mar '25

I'm happy to accept this proposal. B > A > C > D. As you'll see on the GitHub thread <https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-272406…>, I have convinced myself that (C), allowing keywords in traditional record syntax, is untenable. And I really don't think we should reject (D). I'm favouring (B) over (A) for simple consistency reasons; the fewer exceptions the better. Plus at least one person has said the extra generality would be useful. Simon

1 0

Re: [ghc-steering-committee] #686: Amendment to MultilineStrings, recommendation: accept
by Sebastian Graf 11 Mar '25

11 Mar '25

I vote accept.

1 0