Re: #570: Native string interpolation syntax (round two)
Hi everyone, Thanks to Simon, Rodrigo, Erik and Jaro for expressing their votes. We are now 3 weeks into the review period. That means we have about *1 week left* to come to a conclusion. I would be interested in the opinions of - Simon M - Adam - Malte - Matthías - Jakob Thank you! Sebastian Am Do., 16. Juli 2026 um 18:58 Uhr schrieb <code@jaro.addy.io>:
I support the proposal.
I think string interpolation is rarely the most principled solution any problem, but it is very convenient and Brandon and all contributors have put enough thought into making sure the proposed string interpolation has few sharp edges.
Cheers, Jaro
On 29 Jun 2026, at 12:41, Sebastian Graf <sgraf1337@gmail.com> wrote:
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
Hey, I enthusiastically support the proposal. I am very happy to see string interpolation in Haskell. My major pain point is that we couldn’t find a design for the Interpolate type class which prevents Text -> String -> Text conversions when writing a Text into an interpolation for a Text interpolater based on the Interpolate class. However, that is actually a pure library design question orthogonal to the GHC specific plumbing. I am satisfied with the internals and hope we will find a better library solution later. Best, Malte On 2026-07-20 08:12, Sebastian Graf wrote:
Hi everyone,
Thanks to Simon, Rodrigo, Erik and Jaro for expressing their votes.
We are now 3 weeks into the review period. That means we have about 1 week left to come to a conclusion. I would be interested in the opinions of * Simon M * Adam * Malte * Matthías * Jakob
Thank you! Sebastian
Am Do., 16. Juli 2026 um 18:58 Uhr schrieb <[1]code@jaro.addy.io>:
I support the proposal.
I think string interpolation is rarely the most principled solution any problem, but it is very convenient and Brandon and all contributors have put enough thought into making sure the proposed string interpolation has few sharp edges.
Cheers, Jaro
On 29 Jun 2026, at 12:41, Sebastian Graf <[2]sgraf1337@gmail.com> wrote:
Dear committee,
In [3]#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
References
1. mailto:code@jaro.addy.io 2. mailto:sgraf1337@gmail.com 3. https://github.com/ghc-proposals/ghc-proposals/pull/570
_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org
Happy to see the synergy with `QualifiedStrings`. I support the proposal. /Matti Palli On Mon, Jul 20, 2026 at 08:12 Sebastian Graf <sgraf1337@gmail.com> wrote:
Hi everyone,
Thanks to Simon, Rodrigo, Erik and Jaro for expressing their votes.
We are now 3 weeks into the review period. That means we have about *1 week left* to come to a conclusion. I would be interested in the opinions of
- Simon M - Adam - Malte - Matthías - Jakob
Thank you! Sebastian
Am Do., 16. Juli 2026 um 18:58 Uhr schrieb <code@jaro.addy.io>:
I support the proposal.
I think string interpolation is rarely the most principled solution any problem, but it is very convenient and Brandon and all contributors have put enough thought into making sure the proposed string interpolation has few sharp edges.
Cheers, Jaro
On 29 Jun 2026, at 12:41, Sebastian Graf <sgraf1337@gmail.com> wrote:
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
_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org
+1 However, I think it's a shame that with OverloadedStrings the interpolation happens on String and then gets converted with fromString, and I don't really want to use QualifiedStrings. I see there was some discussion about this, including some perf measurements (9x overhead for going via String <https://github.com/ghc-proposals/ghc-proposals/pull/570#issuecomment-4537122848>), but I didn't read the 600+ previous comments(!) so it's not clear to me why this design was chosen over one which allows the interpolation to be specialised. This design introduces a performance pitfall: use Text.s"...", it's 9x faster! This is yet another thing that performance gurus will need to know. Feels a bit unsatisfying. Cheers Simon On Mon, 20 Jul 2026 at 07:12, Sebastian Graf <sgraf1337@gmail.com> wrote:
Hi everyone,
Thanks to Simon, Rodrigo, Erik and Jaro for expressing their votes.
We are now 3 weeks into the review period. That means we have about *1 week left* to come to a conclusion. I would be interested in the opinions of
- Simon M - Adam - Malte - Matthías - Jakob
Thank you! Sebastian
Am Do., 16. Juli 2026 um 18:58 Uhr schrieb <code@jaro.addy.io>:
I support the proposal.
I think string interpolation is rarely the most principled solution any problem, but it is very convenient and Brandon and all contributors have put enough thought into making sure the proposed string interpolation has few sharp edges.
Cheers, Jaro
On 29 Jun 2026, at 12:41, Sebastian Graf <sgraf1337@gmail.com> wrote:
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
_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org
I support the proposal; I consider syntax considerations somewhat less important than I once did, but even so, string interpolation seems like a fairly important thing to have (one I wish I had many times) and the design looks like it's in a good spot. Jakob On Thu, Jul 23, 2026 at 11:02 AM Simon Marlow <marlowsd@gmail.com> wrote:
+1
However, I think it's a shame that with OverloadedStrings the interpolation happens on String and then gets converted with fromString, and I don't really want to use QualifiedStrings. I see there was some discussion about this, including some perf measurements (9x overhead for going via String <https://github.com/ghc-proposals/ghc-proposals/pull/570#issuecomment-4537122848>), but I didn't read the 600+ previous comments(!) so it's not clear to me why this design was chosen over one which allows the interpolation to be specialised. This design introduces a performance pitfall: use Text.s"...", it's 9x faster! This is yet another thing that performance gurus will need to know. Feels a bit unsatisfying.
Cheers Simon
On Mon, 20 Jul 2026 at 07:12, Sebastian Graf <sgraf1337@gmail.com> wrote:
Hi everyone,
Thanks to Simon, Rodrigo, Erik and Jaro for expressing their votes.
We are now 3 weeks into the review period. That means we have about *1 week left* to come to a conclusion. I would be interested in the opinions of
- Simon M - Adam - Malte - Matthías - Jakob
Thank you! Sebastian
Am Do., 16. Juli 2026 um 18:58 Uhr schrieb <code@jaro.addy.io>:
I support the proposal.
I think string interpolation is rarely the most principled solution any problem, but it is very convenient and Brandon and all contributors have put enough thought into making sure the proposed string interpolation has few sharp edges.
Cheers, Jaro
On 29 Jun 2026, at 12:41, Sebastian Graf <sgraf1337@gmail.com> wrote:
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
_______________________________________________ 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
Thanks everyone. I count 9 votes in favour (including my own) and none against. I hereby declare the proposal accepted. Am Mo., 27. Juli 2026 um 07:31 Uhr schrieb Jakob Brünker < jakob.bruenker@gmail.com>:
I support the proposal; I consider syntax considerations somewhat less important than I once did, but even so, string interpolation seems like a fairly important thing to have (one I wish I had many times) and the design looks like it's in a good spot.
Jakob
On Thu, Jul 23, 2026 at 11:02 AM Simon Marlow <marlowsd@gmail.com> wrote:
+1
However, I think it's a shame that with OverloadedStrings the interpolation happens on String and then gets converted with fromString, and I don't really want to use QualifiedStrings. I see there was some discussion about this, including some perf measurements (9x overhead for going via String <https://github.com/ghc-proposals/ghc-proposals/pull/570#issuecomment-4537122848>), but I didn't read the 600+ previous comments(!) so it's not clear to me why this design was chosen over one which allows the interpolation to be specialised. This design introduces a performance pitfall: use Text.s"...", it's 9x faster! This is yet another thing that performance gurus will need to know. Feels a bit unsatisfying.
Cheers Simon
On Mon, 20 Jul 2026 at 07:12, Sebastian Graf <sgraf1337@gmail.com> wrote:
Hi everyone,
Thanks to Simon, Rodrigo, Erik and Jaro for expressing their votes.
We are now 3 weeks into the review period. That means we have about *1 week left* to come to a conclusion. I would be interested in the opinions of
- Simon M - Adam - Malte - Matthías - Jakob
Thank you! Sebastian
Am Do., 16. Juli 2026 um 18:58 Uhr schrieb <code@jaro.addy.io>:
I support the proposal.
I think string interpolation is rarely the most principled solution any problem, but it is very convenient and Brandon and all contributors have put enough thought into making sure the proposed string interpolation has few sharp edges.
Cheers, Jaro
On 29 Jun 2026, at 12:41, Sebastian Graf <sgraf1337@gmail.com> wrote:
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
_______________________________________________ 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
_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org
Coming back to Simon M.'s concern about 9x slowdown of OverloadedStrings vs. QualifiedStrings being annoying: It can be fixed with rewrite rules (as I hoped). See https://github.com/ghc-proposals/ghc-proposals/pull/570#issuecomment-5163846... . Am Mo., 27. Juli 2026 um 08:55 Uhr schrieb Sebastian Graf < sgraf1337@gmail.com>:
Thanks everyone. I count 9 votes in favour (including my own) and none against. I hereby declare the proposal accepted.
Am Mo., 27. Juli 2026 um 07:31 Uhr schrieb Jakob Brünker < jakob.bruenker@gmail.com>:
I support the proposal; I consider syntax considerations somewhat less important than I once did, but even so, string interpolation seems like a fairly important thing to have (one I wish I had many times) and the design looks like it's in a good spot.
Jakob
On Thu, Jul 23, 2026 at 11:02 AM Simon Marlow <marlowsd@gmail.com> wrote:
+1
However, I think it's a shame that with OverloadedStrings the interpolation happens on String and then gets converted with fromString, and I don't really want to use QualifiedStrings. I see there was some discussion about this, including some perf measurements (9x overhead for going via String <https://github.com/ghc-proposals/ghc-proposals/pull/570#issuecomment-4537122848>), but I didn't read the 600+ previous comments(!) so it's not clear to me why this design was chosen over one which allows the interpolation to be specialised. This design introduces a performance pitfall: use Text.s"...", it's 9x faster! This is yet another thing that performance gurus will need to know. Feels a bit unsatisfying.
Cheers Simon
On Mon, 20 Jul 2026 at 07:12, Sebastian Graf <sgraf1337@gmail.com> wrote:
Hi everyone,
Thanks to Simon, Rodrigo, Erik and Jaro for expressing their votes.
We are now 3 weeks into the review period. That means we have about *1 week left* to come to a conclusion. I would be interested in the opinions of
- Simon M - Adam - Malte - Matthías - Jakob
Thank you! Sebastian
Am Do., 16. Juli 2026 um 18:58 Uhr schrieb <code@jaro.addy.io>:
I support the proposal.
I think string interpolation is rarely the most principled solution any problem, but it is very convenient and Brandon and all contributors have put enough thought into making sure the proposed string interpolation has few sharp edges.
Cheers, Jaro
On 29 Jun 2026, at 12:41, Sebastian Graf <sgraf1337@gmail.com> wrote:
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
_______________________________________________ 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
_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org
participants (5)
-
Jakob Brünker -
Malte Ott -
Matthías Páll Gissurarson -
Sebastian Graf -
Simon Marlow