GHC String Interpolation - Prototypes

I suppose it would be possible with extensible-hasclass to define an interpolation function

hacky :: [Either String (HasClass a)] -> Q Exp

Then if you did $hacky"a ${x} b", you’d get to evaluate the splice at compile time. Assuming the parsing works like that.

How does that compare to extensible-th?

Interesting! I like that, let me add it as a note for extensible-hasclass. As mentioned above, you could implement hasclass with the th version, but with your idea, we could also recover the th version with HasClass. One slight difference is that the th version takes in splices as Q Exp, so the th version could theoretically inspect/modify the expressions before interpolation

I’m also not sure how the following would work with hacky:

sumAndInterp :: Int -> Int -> String
sumAndInterp x y = $hacky"the sum is: ${x + y}"

We would like to embed the expression x+y, but from a glance this would only let us embed values.

For instance, this doesn’t compile:

sumAndSplice x y = $(lift $ x + y)
2 Likes

Does

foo x y = $(lift [| x + y |])

work? extensible-hasclass might allow the following for free:

hacky :: [Either String (HasClass Quote)] -> Q Exp
foo x y = $(hacky"a ${[| x + y |]} b")

A future proposal could drop the extra parens if this is sufficiently useful

2 Likes

Rather than $(lift [| x + y|]), I think you want $([| x + y|]).

Good point!
If it gets desugared like so then it should work:

foo x y = $(hacky"a ${[| x + y|]} b")
-- desguars to
foo x y = $(hacky [Left "a", Right (HasClass [| x + y|]), Left "b")

Though this is quite verbose, and eliminating verbosity is the aim of this proposal.

A future proposal could drop the extra parens if this is sufficiently useful

I feel like we should aim to either handle these cases well in this proposal or try to go for something really quite minimal and leave the extensible case wholesale to a later one.

2 Likes