{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihmlz6mtgcfdcjmtgfysbbcmlly5wjcobw4mse7pa5xxqdhxu74wa",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mnzdcr7ovah2"
  },
  "path": "/t/final-call-for-ghc-string-interpolation-proposal/14234#post_14",
  "publishedAt": "2026-06-11T13:12:40.000Z",
  "site": "https://discourse.haskell.org",
  "textContent": "> Have you read the actual proposal? It doesn’t work for arbitrary Haskell values, it uses a typeclass to render the value.\n\nI have read the proposal, yes. What I mean by “arbitrary Haskell values” here is that the template is basically just a string, and nothing in the toolchain knows anything about any potential structural constraints of that template string. Any value for which a typeclass instance for string interpolation exists can be injected into a template string at any point, regardless of what that string represents.\n\nIn other words, the problem is that we’re constructing strings from a template and data within a particular domain (e.g., SQL, HTML, a greeter program’s output, etc.), but the mechanism we’re using for that is completely unaware of the structure.\n\n> People are generally aware of what string interpolation can do, and what you shouldn’t do with them\n\nAnd yet my experience is that people are not as aware of the issue as you’d expect.\n\nbrandonchinn178:\n\n> Things like SQL injection could be mitigated with a SQL string interpolator, as I described in the proposal, which allows ergonomic query parameterization using interpolation syntax while escaping interpolated values.\n\nAh, that part actually went slightly past me. SQL is probably not the best example here, because what you _really_ ought to do is send the parameters separately from the query string and not doing any interpolation at all, but I get the idea, and for things like HTML, it sounds like a decent approach. I guess it would hinge on whether the correct solution (using those domain-aware interpolators) would be more obvious and more ergonomic than the incorrect one (using naive string interpolation) in practice.",
  "title": "Final call for GHC String Interpolation proposal!"
}