Including double quotes with string interpolation in 2.10.0 RC3

[Dennis Ranke]

Hi,

I just tried out the new string interpolation feature in 2.10 and found that I cannot include escaped double quotes inside interpolated strings:

scala> s"\""
<console>:1: error: unclosed string literal
       s"\""
           ^

As I haven't seen this documented at http://docs.scala-lang.org/overviews/core/string-interpolation.html, I am wondering whether this is a bug or just a limitation that should be added to the documentation?

Dennis

[Johannes Rudolph]

The SIP for interpolated strings seems to include syntax for escapes
for double quotes and the dollar sign:

http://docs.scala-lang.org/sips/pending/string-interpolation.html

For me it seems like a bug or at least a questionable behavior.

Johannes

--
Johannes

-----------------------------------------------
Johannes Rudolph
http://virtual-void.net

[Rex Kerr]

String interpolation strings are for now always parsed as literal strings by the compiler, save for $-syntax for inserting code; these literal strings are then passed on to the interpolating code that can choose to do things like interpret escape sequences.

Unfortunately, that means that the compiler doesn't interpret escapes for quotes.

You can usually get around this by triple-quoting.

Occasionally (e.g. if you need to embed a triple-quote) you have to include a code block:

  s"${"\"\"\""}"  // Embed non-interpolation syntax as code into interpolated string

Also, interpolated strings make no distinction between " and """ except for what the termination signal is (i.e. another " or """).  The normal """-is-literal, "-is-escaped distinction is lost.

There may be improvements to string interpolation that address some of these things in the future.  For now, maybe better documentation is in order.

--Rex

[Johannes Rudolph]

On Thu, Dec 6, 2012 at 12:14 PM, Rex Kerr <ich...@gmail.com> wrote:
> String interpolation strings are for now always parsed as literal strings by
> the compiler, save for $-syntax for inserting code; these literal strings
> are then passed on to the interpolating code that can choose to do things
> like interpret escape sequences.

Oh, I see. I mistook this line from the SIP:

alphaid`"' {printableChar \ (`"' | `$') | escape} `"'

for meaning that it's possible to quote double quotes with a backslash
but it actually means that double quotes and dollar signs are
forbidden as literal characters in interpolated strings.

Dollar signs can be quoted as $$, why isn't there a similar quote $" ?
What would have been the disadvantages of just allowing the usual
backslash escapes for double quotes and dollar signs? I understand
that you want to leave as much processing as possible to the
interpolator implementation but when that means that you can't express
some literals to begin with it seems overly restrictive and like a
unnecessary departure from the usual conventions. It makes it harder
to change code to use string interpolation because some forms that are
valid strings are no valid interpolated strings any more.

[Rex Kerr]

On Thu, Dec 6, 2012 at 6:56 AM, Johannes Rudolph <johannes...@googlemail.com> wrote:

What would have been the disadvantages of just

Er, well, there you have it.  It's not so "just".  String interpolation is new, so either it requires a lot of thought to get everything perfect the first time, or some experience, which is what we're getting now.

I don't think there's any particular reason that string interpolation cannot be improved.  Even if the change is a breaking change, one can always introduce another prefix letter that does "the right thing".

  --Rex

[Daniel Sobral]

It's not documented there(*), indeed, but that's the specified behavior. From the SIP:

Inside a processed literal none of the usual escape characters are interpreted (except for unicode escapes) no matter whether the string literal is normal (enclosed in single quotes) or multi-line (enclosed in triple quotes).

And, now, let me explain it.

The most important point in understanding string interpolation is that it is NOT ABOUT PRODUCING STRINGS. One would certainly be forgiven for not noticing that, given the name (*string* interpolation) and the fact that the only interpolators in the standard library produce strings. However, string interpolation is about producing OBJECTS from their string representation, and that means respecting the rules of whatever language that string is written in.

The postcard example for it is regular expressions. The backslash character have a special meaning in regular expressions, which varies depending on the type of regular expression. On a basic regular expression, \( and \) are used to indicate matching groups, while on an *extended* regular expression it indicates literal parenthesis characters. The point is that *Scala* parser can't be relied on to make a decision on what the backslash character means, because only the interpolator has enough information to do so.

If you need to put quotes inside the string, use the multiline interpolator instead of the simple interpolator.

(*) However, the existence of the raw interpolator should suggest it.

--
Daniel C. Sobral

I travel to the future all the time.

[Dennis Ranke]

On Thursday, December 6, 2012 1:41:01 PM UTC+1, Daniel Sobral wrote:

It's not documented there(*), indeed, but that's the specified behavior. From the SIP:

 

[...]

(*) However, the existence of the raw interpolator should suggest it.

Thanks Rex and Daniel!

That explains the whole thing well to me. And I actually did wonder how the raw interpolator worked, but didn't make the connection.