[RFC FS-1001 Discussion] String Interpolation

[v2m]

This issue is used to track discussions of F# RFC FS-1001 - "String interpolation"

[dsyme]

I presume the approach of using Concat is preferred over generating "%d%O%d%O" because of the difficult in inserting "foo" and "bar.bar" at the right points in the argument list?

[dsyme]

Re "Should embedded expressions be restricted to just identifiers\dotted names or we should allow full set of F# expressions" -

I'm fairly strongly inclined to the position that allowing arbitrary expressions will hurt code readability, somewhat needlessly. Restricting to identifiers or a very simple class of expressions seems sensible.

[dsyme]

Re: "Should we provide ways to specify width\precision\alignment similar to what [printf][6] is doing today? If yes - what modification should be made to the proposed syntax?"

I don't tend to like language features that lead to a non-localized discontinuity when you want to "do the obvious next thing" in a programming sequence - for example, format a displated number 5.6234 to two decimal places - 5.62. These kinds of discontinuities are a PITA for teachers - do they teach the "simple but ultimately way too limited" version of printing - %(foo), or do they teach the "complete but more complex" way of doing things - %d, %0.2d etc.

So my inclination is that we need to handle width/precision/alignment specifiers. Does %0.2(foo) seem reasonable?

[v2m]

I presume the approach of using Concat is preferred over generating "%d%O%d%O" because of the difficult in inserting "foo" and "bar.bar" at the right points in the argument list?

Yes, this is one of reasons. i.e. when embedded expressions in format string are interleaved with format specifiers then printf "%d %(foo) %s" should be transformed to fun a b -> printf "%d %s %s" a foo s. Given that user has already specified what values should be put in a placeholders of the format string I see no point in adding extra complexity to implementation (creating an extra closure) and to runtime (avoid manufacturing the function in runtime for cases when format string uses only embedded expressions)

I'm fairly strongly inclined to the position that allowing arbitrary expressions will hurt code readability, somewhat needlessly. Restricting to identifiers or a very simple class of expressions seems sensible.

This is an interesting question from the implementation perspective. We already have implementation for the one extreme: allowing arbitrary F# expression - in this case we can just reuse existing parser. Another extreme: allowing just identifiers\dotted expressions - writing parser for this case will be trivial. Any other options will require making customized parser that will recognize only limited subset of expressions. Personally I would not go in this direction and allow anything so it will be responsibility of the consumer to write the readable code.

Does %0.2(foo) seem reasonable?

Yes, I like it.

[forki]

Unfortunately the corresponding pull request on codeplex was closed because of release pressure. Can we somehow revive this? String interpolation is a feature that a lot of users would like to see.

[forki]

Ok I rebased it on master: dotnet/fsharp#921

[enricosada]

a question: are we supporting localization correctly?

msdn about c# string interpolation

It's not only about a better string format, need to support i18n too. C# does that because string interpolation does implicit type conversion to FormattableString

var s = $"hello, {name}"
System.IFormattable s = $"Hello, {name}"
System.FormattableString s = $"Hello, {name}"

so

var product = "Raspberry Pi";
var price = 25.0;
Console.WriteLine(LocalizationHelper.Format(
    $"The price of {product} is {price}.";
));

However, the string interpolation will be compiled to a FormattableString with “The price of {0} is {1:C}” as the format that will get passed to GetLocalized. In other words, the people doing the localization will still have to localize with numeric indices instead of the more readable named tokens

If the preferred way for f# is explitic, i think we need another function like $ to formattablestring

[jarlestabell]

(I posted this originally in the wrong thread (the implementation thread).)

I assume most people here know the Scala solution to this, but just in case I want to point that one out, as I think it is quite elegant.
I assume it is drastically much heavier to implement though and it may overlap a bit with type provider territory.

The key point is that it has a concise syntax and is extensible.
So the same concept can be used both for string interpolation without formatting:

val name = "James"
println(s"Hello, $name")  // Hello, James

with formatting:

val height = 1.9d
val name = "James"
println(f"$name%s is $height%2.2f meters tall")  // James is 1.90 meters tall

The above examples are taken from:
http://docs.scala-lang.org/overviews/core/string-interpolation.html

And plain SQL queries: (http://slick.typesafe.com/doc/3.1.1/sql.html#string-interpolation)

def insert(c: Coffee): DBIO[Int] =
 sqlu"insert into coffees values (${c.name}, ${c.supID}, ${c.price}, ${c.sales}, ${c.total})"

and even things like ReactJS-like JSX/TSX xml-based syntax:

xml”””
      <body>
        <a href = “some link”> ${linktext} </a>
    </body>
    ”””

(example from http://docs.scala-lang.org/sips/completed/string-interpolation.html)

[enricosada]

scala syntax and extensibility it's really interesting, StringContext it's like System.FormattableString and the rest it's like sprintf.
The extensibility is really nice to have to make a FormattableString version (useful for localization)

[jarlestabell]

Note that ES6 seems to have the same syntax as Scala, even down to the extensibility. ("tagged template literals")
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals
When working in F#, Scala's string interpolation is one of the few things I miss from Scala.
(Although I have done type mistakes with doing string interpolation in Scala)

[cloudRoutine]

I'm with @isaacabraham on using the "%{expr}" syntax over parentheses. Especially if they allow arbitrary expressions, then it is syntactically coherent with the F# conventions of using % for substitution and { } to delineate a block of scope.

Since we'll know the type the expression resolves to we can determine which formatting specifications to enable. For most types -

• %10{**expr**} - sets the width of the embedded expression
• %*{**expr**} - sets the width dynamically
• %-{**expr**} - left justifies the embedded expression

If it resolves to a numeric type

• %0{**numeric-expr**} - pads with zeros
• %+{**numeric-expr**} - shows a plus sign
• % {**numeric-expr**} - shows a blank in place of a plus sign
• %.5{**numeric-expr**} - control precision when expr is a float

The primitive types can follow the same style of formatting that printf uses, defaulting to

%b, %c, %i, %u, %x, %o, %f, %M,

Additional Questions -

• Is interpolation allowed in every string, only printf strings or will it need a prefix operator?
• Should interpolation be allowed in bare strings if only interpolation substitution is used?
  e.g. "hello %{name}, I have your %10{item}"
• Would this be valid "%{root}"B ?
• Should there be an additional specifier to indicate %O format instead of %A format, or vice versa depending on whichever becomes the default.