Feature request: String interpolation

I love it :heart_eyes:. I am convinced.
I’m not sure about using Show for anything but basic types but that is now up to the implementor of the function you showed above.

1 Like

@natefaubion Amazing!

Maybe something like some custom Format Display class instead of Show with some default instances for basic types and some more configurable newtypes too could be packaged up?
@i-am-the-slime, @natefaubion what do you think? Do you have any plans related to packaging this solution?

1 Like

I don’t have any plans to package this.

Would it be possible to use the proposed implementation as a library?

1 Like

The only issue with this implementation (which is pretty minor considering the brilliance of the solution and the minor inconvenience) is that the first argument must always be a String value.

For example, this code fails to compile:

interp 42 " apples and " 52 " oranges."
  Could not match type
  with type

while checking that type Int
  is at least as general as type String
while checking that expression 42
  has type String
in value declaration main

I’m not yet sure whether it’s possible to get around that for the below reasons.

If I define a local binding that applies an empty String argument to interp, I can get around this:

main = do
 let interp' = interp ""
 log $ interp' 42 bar "baz" true

However, using the same binding in two different ways will produce problems:

main = do
 let interp' = interp ""
 log $ interp' 42 "baz" true
 log $ interp' 42 true "baz" true
 -- `Boolean` (from true) does not unify with String (from "baz")

This is because of interp :: String -> a, so the initial application is fixed to String. You could probably reformulate this with just interp :: a, or make interp :: a -> b with a multi-parameter typeclass.

I wasn’t sure how to encode the type class using a multi-parameter typeclass. Everything I’ve tried runs into a problem sooner or later. Your solution seems to work only because the first argument is hard-coded to String.

I think if you just change i to be

i = interp ""

you’re good.

Right, this is due to (lack of) let generalization. You need a type signature if it’s in a let.

i :: forall a. Interp a => a
i = interp ""

This is generalized in a top-level declaration, but not in a let binding.

Ah… that’s why my original interp' = interp "" didn’t work.

Otherwise, yeah, this works:

i :: forall a. Interp a => a
i = interp ""

So, I’ve created purescript-interpolate to do this, but I’m getting stuck when publishing this library.

How do I fix the issue?

1 Like

Ah, that’s a problem. We will have to amend the instructions for publishing to Pursuit. Thanks for bringing this to my attention!

I’ve opened an issue for it here: https://github.com/purescript/pursuit/issues/402

Library has been published. See its installation instructions. PR to the official package set builds and is awaiting review. If you have an idea for building off of this, see how to refer to it in your bower.json file

Also, don’t use this library when doing a fold (e.g. foldl i "" arrayOfInts) until the inliner optimization is done. See this benchmark, which I hope isn’t naive.

Edit: the above benchmark was implemented incorrectly. See this comment for an accurate one.


So I saw the benchmark, the blue line indicates standard append and it blows up, while I guess the red should have, right?

I’ve run this benchmark with changed functions with one size = 10000.
Raw data results (because making a graph is beyond my skills :smile:)

  1. foldl (\a b -> show a <> show b) "" array
    causes JavaScript heap out of memory
  2. 0.001428 mean of foldl (\a b -> a <> show b) "" array
  3. 0.001227 mean of foldl i "" array
  4. 0.001106 mean of foldl interp "" array

In the original benchmark (1) is blue (the blow-up one) and (3) is red.


  • Running show on an accumulated string breaks my memory
  • Difference between (2),(3),(4) is negligible - using fold with interp is ok here

I think the performance problem is not here, but when you write a long expression with interp (or when it is generated with another typeclass generic magic)


Simple usage of interp vs. append

fooI = i "a" 1 "b" 2 "c" 3
fooA = "a" <> show 1 <> "b" <> show 2 <> "c" <> show 3

And the compiled JS (without inlining)

var fooI = function (dictInterp) {
    return Data_Interpolate.i(

var fooA = "a" + (Data_Show.show(Data_Show.showInt)(1) + ("b" + (Data_Show.show(Data_Show.showInt)(2) + ("c" + Data_Show.show(Data_Show.showInt)(3)))));

You can convert the outputted json file into a graph by uploading it here and then exporting the result as an SVG or PNG file: http://harry.garrood.me/purescript-benchotron-svg-renderer/

1 Like

Looking at my original benchmark again, I realized I misread it. I thought the blue line was the i a b one, not the a <> b one…

So, the original benchmark I created used \acc next -> show acc <> show next when it should have been \acc next -> acc <> show next. @paluh pointed this out.

Here’s the correct benchmark, which better reflects my expectation:

1 Like

Did anyone check out purescript-template-strings or purescript-formatting?

While those work, they also feel boilerplate-y…

-- purescript-template-strings
"Hello, ${firstName} ${lastName}!" <~> { firstName: "Haskell", lastName: "Curry" }

"The answer: ${answer}" <~> { answer: 42 }

-- purescript-interpolate
i "Hello, " "Haskell" "Curry" "!"

i "The answer: "(show 42)


-- purescript-formatting
inbox :: forall r. Format String r (String -> Int -> r)
inbox = greeting <<< s " You have " <<< F.int <<< s " new messages."

message3 :: String
message3 = print inbox "Kris" 3
--> message3 == "Hello Kris! You have 3 new messages."

-- purescript-interpolate
inbox name amount = i "Hello " name "! You have "(show amount)" new messages."

message3 = inbox "Kris" 3