Yes, I opened a new thread. It shows in the archive at https://mailman.haskell.org/archives/list/ghc-steering-committee@haskell.org/thread/SBWRD36OC3P34CCQXEB35EQPELRGPDQX.

Has anybody else had trouble receiving that message?

Am Mo., 6. Juli 2026 um 10:21 Uhr schrieb Simon Peyton Jones <simon.peytonjones@gmail.com>:
Sebastian

I believe that you believe you have sent a message to the committee recommending acceptance.  

And yet I cannot find that message.  Maybe I missed it and others received it -- or maybe it got lost somewhere.  Has anyone else responded?

Could you re-send? Thanks

Simon

On Sat, 16 May 2026 at 08:49, Sebastian Graf <sgraf1337@gmail.com> wrote:
Dear Committee,

It appears Brandon is still doing some edits to the proposal. I suggest you hold back on reading it until he resubmits.
Apologies for the churn.

Cheers,
Sebastian 

Adam Gundry <adam@well-typed.com> schrieb am Fr., 15. Mai 2026, 09:02:
Hi Committee,

Brandon has been making great efforts on this proposal, and has already
revised it in response to feedback from committee members. The current
iteration eliminates the controversial higher-order representation in
favour of exporting more top-level functions to define (qualified)
interpolation.

I'm in favour of acceptance. There are a few details of the interaction
with OverloadedStrings and QualifiedStrings that I've suggested
fine-tuning, but these are secondary details.

There is also a library design question here around the `Interpolate`
class (which I think might be better generalised into a general
`Display` class). This class can go in `ghc-experimental` initially, but
really belongs in `base` as many packages will be encouraged to define
instances for it. Brandon has brought this to the attention of the CLC
(https://github.com/haskell/core-libraries-committee/issues/416). In the
interests of making progress I don't think we need to wait for complete
consensus on the final class naming before accepting the ghc-proposal,
on the understanding that the CLC can decide the final `base` interface
and then the proposal amended if needed.

Cheers,

Adam



On 15/05/2026 03:48, Erik de Castro Lopo wrote:
> Hi Sebastan,
>
> I did look at this when there were about 100 comments and again when
> there were about 350. Its now at over 460 comments.
>
> I will devote some time to looking again over the weekend.
>
> Cheers,
> Erik
>
>
> Sebastian Graf wrote:
>
>> Dear fellow committee members,
>>
>> Here's also a reminder that the proposal has been in the committee's inbox
>> since 19 April. *We have less than 2 weeks remaining to come to a
>> conclusion* (before 24 May).
>> Given there were no enthusiastic proponents so far for the proposal as-is,
>> I can see that we will hand this proposal back to Brandon for revision.
>>
>> However, we should try to guide Brandon towards a design that we will
>> accept. (I'm still convinced this is a practically important feature.)
>> *In order to do that, we need design input from more members of the
>> committee, even if it is just a reinforcement of existing positions.*
>> I sympathise with everyone who is scared off by the length of the
>> discussion and the huge design space of the proposal, but it is better to
>> shape it right now than in a few more weeks when Brandon submits the next
>> iteration. He has been heroically working through many many iterations of
>> the proposal already; I don't want him to lose his energy.
>>
>> In that light, I would welcome design input from
>>
>>     - Adam
>>     - Malte
>>     - Erik
>>     - Jakob
>>     - Jaro
>>     - Rodrigo
>>
>> Thank you!
>> Sebastian
>>
>> Am Di., 12. Mai 2026 um 13:58 Uhr schrieb Sebastian Graf <
>> sgraf1337@gmail.com>:
>>
>>> (Responding to Simon's post here, because that's the thread that tracks
>>> the String Interpolation proposal.)
>>>
>>>> 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_r3164039563>
>>> , This articulation of the design choices
>>> <https://github.com/ghc-proposals/ghc-proposals/pull/570#discussion_r3166956351>
>>>> 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
>>>
>>> I felt like the design space spiraled out of control, so in
>>> https://github.com/ghc-proposals/ghc-proposals/pull/570#discussion_r3225951448
>>> I cut it down. Let me know what you think.
>>>
>>> Am So., 19. Apr. 2026 um 15:53 Uhr schrieb Sebastian Graf <
>>> sgraf1337@gmail.com>:
>>>
>>>> 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
>>>>
>>>
>
>

--
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

_______________________________________________
ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org
To unsubscribe send an email to ghc-steering-committee-leave@haskell.org
_______________________________________________
ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org
To unsubscribe send an email to ghc-steering-committee-leave@haskell.org