Feature request: String interpolation

language
#1

Although I know Strings are evil etc. it’s often possible to construct some. The problem with:

  "a really really" <>
  "long string " <>
  age

Is that it’s easy to forget spaces. Would there be interest in string interpolation syntax?

1 Like
#2

Two thoughts: firstly, you can use the same “whitespace gap” syntax as Haskell has. If you have a backslash followed by any whitespace within a string, then all whitespace is ignored up until the next backslash, so you can write e.g.

x = "a really really \
  \long string \
  \" <> age

although this doesn’t really address the issue that it’s still easy to forget spaces around interpolated values from variables like age.

Secondly, I have to give the usual spiel about how syntax additions are, in general, pretty unlikely to be accepted, as they are kind of antithetical to language stability, which I think is one of the most highly desired things across the community. In particular, syntax additions are a problem for tooling such as syntax highlighters or autoformatters. Then again I want to add \u character escape sequences like JavaScript has (https://github.com/purescript/purescript/issues/3750) so maybe this is a little hypocritical of me.

michaelficarra on github asks: could this be added in a backwards-compatible way? I think it could, if we used a backslash escape sequence for them. Perhaps, for instance:

greet name = "hello, \#{name}"

which could desugar to

greet name = "hello, " <> name

One problem, though, is what types are allowed inside an interpolation block. In dynamic languages it makes sense to insert an implicit toString call inside any interpolation block, so that you can put anything in and hopefully it will usually do what you want. In the context of dynamic languages, that’s acceptable, because there is already an expectation that the language can’t help you if you have null when you expected a string or whatever.

The PureScript analog of this approach would probably be adding a type class Display, with a member display :: forall a. Display a => String, and inserting an implicit display in interpolation blocks (note: we can’t use Show, because a number of instances won’t do what we want - consider e.g. Show String and Show (Maybe a)).

However, I think there’s also a strong case to be made for requiring interpolation blocks to be strings, so that the conversion to string (if any) is explicit.

2 Likes
#3

if we’re talking about a world where PS syntax gets extended in a backwards compatible way:

I’d really love to see this as a feature that corresponds to JS template string literals. the idea of a Display typeclass is also pretty great. use of the anonymous argument would be great. backticks probably wouldn’t work since they’re used for inlining (I think other languages will use triple quotes), but for these examples, lets assume backticks for templates just to demonstrate some ideas:


hellofunc :: Display x => x -> String
hellofunc = `Hello, ${_}!` 

hellofunc2 :: Display x => x -> String
hellofunc2 x = "Hello, " <> display x <> "!"

With the anonymous argument, these two functions would be equivalent.

I for one would really value how terse this could make string construction while maintaining type safety.

I’m not too concerned with explicit conversions for something that is a language feature. however this would add to the typeclass ‘load’ that a beginner - even one coming from haskell would need to grok in order to be proficient with the language features. perhaps we default it to Show instead of Display, but if you want to use a custom conversion you just supply the string, that would probably be the best compromise of intuitive usage and explicit conversion.

1 Like
#4

Scala also added string interpolation late. As a point of comparison on syntax and decoding https://docs.scala-lang.org/overviews/core/string-interpolation.html

#5

I share the desire to introduce as little machinery as possible but I don’t think Show is an option, because it will just do the wrong thing far too often. You will easily end up with things like, say, “Hello, (Just “Jos\x0000e9”)” or “Your balance is (fromNumber 14.34)”. Show instances are almost always intended for use in the repl, whereas I suspect this feature would mostly be used in very different settings, eg for generating strings which are to be used in user interfaces. In fact I am struggling to think of any Show instances which will do what you want here other than Int and Number.

#6

IIRC Rust has a separate Debug display typeclass for that reason

#7

Probably not worth going down this route, but if we were also trying to replicate JavaScript and its syntax (so that we can just compile to the same syntax, after transforming our variable names inside the literals), tagged template literals don’t necessarily need their expressions and result to be Strings, for eg:

"use strict";

function expression(strings, a, b) {
  switch(strings[1]) {
  case "+":
    return a + b;
  ...
  };
};
var a = 10;
var b = 20;
var c = expression`${a}+${b}` 
// c === 30

exports.expression = expression;
// String.raw is the default tag for template literals
exports.raw = String.raw;

exports.mkTag = function (tag) {
  return function (strings, ...args) {
    return tag(strings, args);
  };
};

As tags would now be first class, the user can just pick if they want the Show/Display etc abstraction or not. Biggest limitation of this is that now all expressions have to be the same type, as below I’m using Array a, and not some other ordered product representation. Might be possible to overcome that with a type class however

-- Can't use normal functions to type this, as it has var args
-- JS template implementation guarantees that num strings = num expr + 1
foreign import data Tag :: Type -> Type -> Type
foreign import expression :: Tag Int Int
foreign import raw :: Tag String String
foreign import mkTag :: forall a b
    . (Array String -> Array a -> b)
  -> Tag a b

class Display a where
  display :: a -> String

displayTag :: forall a. Display a => Tag a String
displayTag = 
  mkTag \strings args -> someIntercalater (map display args) strings

sum = expression`${a}+${b'}`
  where
    a = 10
    b' = 20 -- note this will require us parsing the template and swapping
            -- b' for b$prime (or whatever we change it to)

helloWorld = raw`${hello}, ${world}!` -- displayTag`...` would also work if we had a String instance
  where
    hello = "Hello"
    world = "world"

The point of this approach would be to avoid doing as much as possible in the compiler, only require renaming variables inside the template/checking they exist` and marking them as used (or whatever, just so we don’t optimise them away), and then emitting almost the same code as the source purs. Actually I suppose there’s more work than that, like all transformations such as 123 -> 123|0, but I imagine it’s not too difficult to do?

1 Like