- ghc-steering-committee

#765: Pun warnings, recommendation: accept
by Jakob Brünker 15 Jul '26

15 Jul '26

Hi all, Our own Jaro Reinders, based on a proposal originally by Artyom Kuznetsov, proposes to introduce `-Wpuns` and `-Wpun-bindings`, to warn users when the same name appears in the term namespace and type namespace: https://github.com/ghc-proposals/ghc-proposals/blob/pun-warnings/proposals/… These warnings would not be enabled by default, but would bring us a step forward on the path outlined by the accepted proposal #378 (Support the design for dependent types, https://github.com/ghc-proposals/ghc-proposals/pull/378) by supporting writing code in a way that plays well with the principles described in that proposal (i.e. the lexical scoping principle and syntactic unification principle). They are also a good match for the recently introduced `-XNoListTuplePuns`, which already lets users avoid puns for some builtin types. Any users of `-XNoListTuplePuns` will likely want something along the lines of this proposal. I left some comments on the github thread but I think they are small enough that they don't have to prevent us from voting on it. I recommend we accept. Please indicate whether you wish to accept this proposal. Jakob

3 2

#570: Native string interpolation syntax (round two)
by Sebastian Graf 08 Jul '26

08 Jul '26

Dear committee, In #570 <https://github.com/ghc-proposals/ghc-proposals/pull/570>, Brandon Chinn proposes adding native string interpolation syntax to GHC, along the lines of s"a ${x + 1} b", catching up with and even exceeding similar features in popular programming languages. I think this is an important proposal and I recommend that we accept it. Since the previous submission, Brandon settled on a coherent and simple interaction with -XOverloadedStrings. Although the proposed interpolation API seems more ad-hoc than necessary, I did not find a way to simplify it any further. Cheers, Sebastian

4 3

#570: Native string interpolation syntax
by Sebastian Graf 07 Jul '26

07 Jul '26

Dear committee, In #570 <https://github.com/ghc-proposals/ghc-proposals/pull/570>, Brandon Chinn proposes adding native string interpolation syntax to GHC, along the lines of s"a ${x + 1} b", catching up with and even exceeding similar features in popular programming languages. The desugaring of s"a ${x + 1} b" is: ``` Data.String.Interpolate.Experimental.interpolateString ( \convert raw append empty -> raw "a " `append` convert (x + 1) `append` raw " b" `append` empty ) :: String ``` where the following definitions are added to ghc-experimental: ``` class Interpolate a where interpolate :: a -> String type SimpleStringInterpolator s = ( forall ss. (forall a. Interpolate a => a -> s) -> (s -> s) -> (s -> ss -> ss) -> ss -> ss ) -> s interpolateString :: (IsString s, Monoid s) => SimpleStringInterpolator s interpolateString f = mconcat $ f (fromString . interpolate) id (:) [] ``` With -XQualifiedStrings, the string interpolation function may be rebound as well: ``` SQL.s"select * from users where name = ${Text.toUpper name} and age = ${age}" -- desugars to SQL.interpolateString $ \convert raw append empty -> raw "select * from users where name = " `append` convert (Text.toUpper name) `append` raw " and age = " `append` convert age `append` empty ``` I think this is an important proposal and I would emphatically accept one form or anothter. It is a useful feature with a long history of continued refinement by Brandon. I'm torn however on the particular expansion to a second-order function. See this thread: https://github.com/ghc-proposals/ghc-proposals/pull/570/changes#r3040723908 I would sacrifice generality and implement a simpler expansion instead, such as ``` mconcat [ fromString "a " , interpolate (x + 1) , fromString "b" ] :: String ``` So I abstain from voting for the particular version of the proposal. Cheers, Sebastian

4 7

Assigning Shepherd: #765 Pun warnings
by Simon Marlow 06 Jul '26

06 Jul '26

Jaro Reinders and Artyom Kuznetsov submitted proposal #765 Pun Warnings <https://github.com/ghc-proposals/ghc-proposals/pull/765> for the committee to review. I'd like to nominate *Jakob Brünker* as the shepherd. Please guide us to a conclusion as outlined in the committee processes <https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst#9comm…> . If possible, please aim to make a recommendation by *14 July 2026*. Cheers Simon

3 2

Unordered extra commas
by code＠jaro.addy.io 02 Jul '26

02 Jul '26

Dear fellow committee members, We have a proposal in the pipeline about allowing extra commas <https://github.com/ghc-proposals/ghc-proposals/pull/748> in sequences where the order does not matter. These extra commas (before the first item and/or after the last item) make code layout more consistent and reduce clutter in diffs. This is a limited version of an earlier proposal which did not make it because it sparked too much controversy. The current only allows redundant commas in uncontroversial places, which roughly lines up with the intuition that for all these places the order of the sequence items does not matter. Since there hasn't been much discussion lately on this proposal, I'm asking you to provide your opinion. There are two main points of discussion: 1. Does this proposal make the right selection of places where to allow extra commas? This proposal for example does not include commas in contexts ((...here...) => ...), or in lists. I personally think we should choose carefully to avoid the situation where we do want to allow extra commas in more places in the future, because we then either need a new extension or we need to change the meaning of this extension. 2. Which extra commas do we allow? The current proposal is to allow an extra comma at the start AND at the end of a sequence. I personally think we should be more conservative and only allow one OR the other (exclusively). Another alternative is to allow extra commas anywhere in the list, even multiple in a row. I'm looking forward to your opinions, Jaro

9 25

Please review #752: Lazy Field Annotations
by Adam Gundry 30 Jun '26

30 Jun '26

Dear Committee, Simon Jakobi proposes a new language extension, `LazyFieldAnnotations`, which allows the existing lazy field annotation syntax `~` to be used independently of `StrictData`. https://github.com/ghc-proposals/ghc-proposals/pull/752 https://github.com/sjakobi/ghc-proposals/blob/lazy-field-anns/proposals/000… I'd like to nominate Malte as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst#commi…. 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

The role of the shepherd
by Simon Peyton Jones 28 Jun '26

28 Jun '26

Friends I have realised, rather belatedly, that we don't actually have any written guidance for shepherds of GHC proposals, so we all have to make it up as we go along. Perhaps it'd be helpful to have some. Here's a start. The shepherd does these things: - Makes a recommendation to the committee for whether to accept, reject, or send back for revision, within a week of being appointed. - Actively guide the committee's discussion. - Maintain a list of votes on this spreadsheet <https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu…> . - Actively facilitate the committee discussion, guiding us towards a decision, within the published time frame of 4-5 weeks. - Summarise the committee's thinking for the author's benefit, and work with the author on next steps -- this may often take the form of revisions to the proposal. - - Remind members (by name, not just general exhortation) who are silent that they are highly encouraged to contribute. - If the discussion does not converge within 4-5 weeks, take action to consult the chair, vice-chair, or secretary to decide what to do. It's much more than "make a recommendation and wait". Being a member of the GHC Steering Committee is a real service to the community. But of course we all have day jobs, and so not everything happens as we hope. Any thoughts? Simon

4 13

Please review #678: Amendment to ImportShadowing
by Adam Gundry 25 Jun '26

25 Jun '26

Dear Committee, Gergő Érdi proposes to amend his import shadowing proposal #652 to clarify the behaviour of module re-exports: https://github.com/ghc-proposals/ghc-proposals/pull/678 I'd like to nominate Erik de Castro Lopo as the shepherd, as he shepherded the original proposal. 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

11 17

Meeting at ZuriHac?
by Adam Gundry 10 Jun '26

10 Jun '26

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

7 9

Interpolated strings
by Simon Peyton Jones 05 May '26

05 May '26

Friends We have a proposal in the committee's inbox about interpolated strings <https://github.com/ghc-proposals/ghc-proposals/pull/570>. Very few of you have contributed to a debate about it, but it's our obligation as members of the GHC Steering Committee to give it our serious attention. I have dived into it, and emerged with - This framing of the proposal <https://github.com/ghc-proposals/ghc-proposals/pull/570#discussion_r3164039…> - This articulation of the design choices <https://github.com/ghc-proposals/ghc-proposals/pull/570#discussion_r3166956…> Now it's your turn. I suggest you respond mainly on the discussion thread of the proposal. Sebastian is our shepherd and will doubtless guide our discussion Simon

2 1