Updates for String-related GHC proposals

[brandonchinn178]

Builder.interpolateString would have total control over its definition, so facetiously, you could implement it however you want :

1. Avoid any implicit conversions, force any interpolations to have type Builder by setting convert = id
2. Implement your own Builder.Interpolate class (with a new set of instances)
3. Reuse the existing interpolateS function in the provided Interpolate class and set convert = Builder.fromShowS . interpolateS (assuming Builder.fromShowS fuses correctly)

The “Builder” section in the Appendix of the proposal might be of note to you, but I could augment it if some of these details would be helpful in there.

@rhendric Two different things - if you have just StringInterpolation set, you can use s"..." only for String. If you have StringInterpolation + OverloadedStrings, all s"..." exprs will add fromString invocations. If you have StringInterpolation + QualifiedStrings, you’d separately have access to M.s"...", however M defines interpolateString.

@rhendric

If interpolation goes through String, it isn’t really allowing overloading in the same way that OverloadedStrings does.

I don’t understand this. It’s still overloading in the sense that everything gets coerced to IsString s after initially going through String (either the literal or via interpolate). And in practice, wouldn’t most implementations of interpolate for Text be T.pack $ ...? While I appreciate the conceptual “it’d be nice to not go through String at all in the first place”, I don’t see a practical benefit for the majority of simple string interpolation use cases.