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_r32259514... 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
-- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/