String interpolation

[lpil]

Currently to join together strings in Gleam we have to use a library that calls out to the host language (i.e. Erlang, JavaScript). This is also true of other string operations such as converting ints and floats to strings.

It is rather verbose in practice.

name
|> string.append("'s score: ")
|> string.append(int.to_string(score))
|> string.append("!")

With an interpolation syntax we could have these common operations be more concise and more portable across target languages.

This would be similar in function to the existing bit string literal syntax which permits the programmer to construct bit strings from multiple parts, with annotations to indicate the types of each part.

Edit: An issue has been created #1473

Interpolatable types

• String - The default. This can be annotated as string, but as the default the annotation is optional.
• Int - Annotated as int
• Float - Annotated as float
• anything - Annotated as debug, any, or raw? Name tbd. Converts any type to a string. There's no guarentee about the output format, it is platform specific and may change between versions.

Possible syntaxes

"#{name}'s score is #{score:int}!"

"#{name}'s score is #int{score}!"

"$name's score is $score:int!"

"${name}'s score is ${score:int}!"

"${name}'s score is $int{score}!"

Future expansions

This syntax could also possibly be used for pattern matching on string prefixes.

More annotations could be added to control the manner in which items are formatted.

Prior art

• Scala https://docs.scala-lang.org/overviews/core/string-interpolation.html
• Python https://www.python.org/dev/peps/pep-0498/#format-specifiers

[hayleigh-dot-dev]

Is there actual any practical benefit for needing the annotation? It doesn't look like these interpolated strings can be passed around unfilled, eg you couldn't do:

let template = "#{name}'s score is #int{score}"

template(name: "Andy", score: 9001)

so what do we gain by requiring the annotation?

[lpil]

It permits the syntax not to be overloaded, the same way we do with bit strings.

Consider this code in a Gleam that does not have annotations

pub fn go(x) {
  "#{x}"
}

What is the type of x here?

[hayleigh-dot-dev]

Ah I see. That makes sense.

I'd almost sooner see this as a compiler error:

Undecidable type in string interpolation:

    pub fn go(x) {
      "#{x}"
         ^

I'm having trouble working out what type `x` is here, is it a
String, or an Int, or a Float? I don't know! Try annotating `x`
where it is defined.

I'm not entirely convinced this is better but maybe it's more confusing that you can assert the type of x after-the-fact? I suppose it's not really any different than inferring x's type from usage.

[lpil]

One thing we could do in future is relax the need for annotations if the type is already known.

// Implicit, x is String as that is the default
pub fn go(x) {
  "#{x}"
}

// Explicit, x is String
pub fn go(x: String) {
  "#{x}"
}

// Explicit, x is Float
pub fn go(x: Float) {
  "#{x}"
}

This is the approach that SML takes I believe.

I would like to think more before we decide to do this, but it can be added in future in a non-breaking way so I think that is ok. If we do this I think we may want to revisit bit strings and maybe the maths operators as they could benefit from this also.

[hayleigh-dot-dev]

it can be added in future in a non-breaking way so I think that is ok.

Yeah this is a good point. Also the type annotations would work in reverse for pattern matching on these template strings. I think you're right, annotations sound good.

[inoas]

One thing we could do in future is relax the need for annotations if the type is already known.
That's cool and starting with requring explicit types in string interpolation would speed up implementation time, I guess?

[CrowdHailer]

Question, Would the output of interpolation be a String or a String Builder? I could see performance benefits of String builder.

[lpil]

One thing that is cool about JavaScript (at least on V8) is that it transparently uses the same technique as iolists when you build strings. (it's also a problem because it means on JS iolists are actually less performant than using string concat)
I wonder if there's a way we could have the same with Gleam when targetting Erlang.

I could see FFI and pattern matching being a challenge as we would need to insert conversions to binary, which could result in some very unexpected performance thanks to these unexpected implicit conversions. edit: I guess we could not automatically do this and leave it up to the programmer in their bindings? Could be error prone.

It could also make debugging challenging as printing a term with a string in it may instead have a big-ole iolist in it instead

[lpil]

This is a really interesting idea. What if Gleam strings were always iolists?

Another problem would be how we deal with pattern matching on data structures that contain strings- we would need to map over them to convert them to binaries before we pattern match. Sounds difficult. Hmm

Could be a good one to discuss further beyond this interpolation issue.

[lpil]

Ah it would break string comparison with == :(

[dch]

generally with iolists we are building up a [..] which will subsequently be pushed out a socket or to a file. The case for reading/matching them is far less common, and ofc the type signature is completely different. The entire point of the iolist is to avoid needless concatenation for data that will be piped to some buffer. I guess one can interpolate ["foo", "#{ var }", ...] anyway.

[resolritter]

99% of the time in user code, which is far more common, one would not care about string performance at all, so I'd definitely favor ergonomics over performance. For library authors and specialized use-cases you could use something else, but that can be designed later as in to not block this feature from being available; I think it's obviously useful enough even with no optimizations.

[UnsolvedCypher]

Perhaps having typeclasses as discussed further here would make the syntax for this better. The string interpolation would only be able to work when a displayable type is passed in, and then there would be no need for the explicit typing inside of the interpolation.

[inoas]

I generally prefer curley braces, for readability and also because you rarely actually type ${something} and don't want a variable (conflicts).

I suspect that escaping will break interpolation? so \${something} or $\{something} or ${something\} will work?

What about having another string quotation mark like javascript does with its backticks for interpoaltion, does that help with ease of implementation and/or speed?

---

Edit 1

As for explicit types I would just make them appear the same as in function heads:

${score: Int}
// ...and/or...
${score:Int}
// ...the formatter would then decide what is recommended

---

Edit 2

As for the anything-type, as there is now string.inspect(), maybe we can just use that for representation?

[inoas]

I just discovered: gleam-lang/suggestions#118

Maybe there should just be one way, not two, for interpolation and templating?

// Single line
"Score: {{ score }}"

// Heredoc
"""
Score: {{ score }}
"""

When we start with just {{ }} it will feel natural to extend that to a templating language?

[mixmastamyk]

Hi, might consider sticking with the backslash escape, as it looks like gleam already uses it for replacement:

https://tour.gleam.run/basics/strings/

"\t \{name}'s score is \{score:int}! \n"

[godalming123]

Personally, I would prefer the type to go outside the brackets/braces (like $Int{number} instead of ${number:int}), since that means that the text inside the brackets/braces is just a value, which would also allow this syntax to replace the (in my opinion) more cluttered <> operator for string concatenation. I also think that the type should have a capital first letter, since that's more consistent with the rest of the language, and might be extended to allow for automatically converting any gleam type into a string with this syntax in the future. Any of the syntax's suggested in OP could also be used for variable capture in case statements:

case user_input {
   "$Int{number}" -> "You entered the integer: $Int{number}"
   "$Float{number}" -> "You entered the float: $Float{number}"
  _ -> "Please enter either an integer or a float"
}