#570: Native string interpolation syntax
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
(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
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
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/
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_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
-- 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
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_r31640395...
, This articulation of the design choices < https://github.com/ghc-proposals/ghc-proposals/pull/570#discussion_r31669563...
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. <https://www.google.com/maps/search/e+particular+expansion+to+a+second-order+function.?entry=gmail&source=g> 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
Sebastian I believe that you believe you have sent a message to the committee recommending acceptance <https://github.com/ghc-proposals/ghc-proposals/pull/570#issuecomment-4832068289> . 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_r31640395...
, This articulation of the design choices < https://github.com/ghc-proposals/ghc-proposals/pull/570#discussion_r31669563...
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. <https://www.google.com/maps/search/e+particular+expansion+to+a+second-order+function.?entry=gmail&source=g> 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
Yes, I opened a new thread. It shows in the archive at https://mailman.haskell.org/archives/list/ghc-steering-committee@haskell.org... . 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 <https://github.com/ghc-proposals/ghc-proposals/pull/570#issuecomment-4832068289> .
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_r31640395...
, This articulation of the design choices < https://github.com/ghc-proposals/ghc-proposals/pull/570#discussion_r31669563...
> 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. <https://www.google.com/maps/search/e+particular+expansion+to+a+second-order+function.?entry=gmail&source=g> > 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
participants (4)
-
Adam Gundry -
Erik de Castro Lopo -
Sebastian Graf -
Simon Peyton Jones