round up the usual escape characters

[Paul Phillips]

(I will open a ticket after I find out whether this is a spec bug or an implementation bug.)

This proceeds swimmingly:

  scala> "the quick brown fox jumps over the lazy dog"

  res0: String = the quick brown fox jumps over the lazy dog

  scala> val fox = "bear" ; val dog = "value"

  fox: String = bear

  dog: String = value

  scala> s"the quick brown $fox jumps over the lazy $dog"

  res1: String = the quick brown bear jumps over the lazy value

If the original string has a quote in it, it's a bit of a different

story. It doesn't appear possible to embed quotes anymore.  Here's

the most concise I found inside single quotes:

  scala> "the quick brown fox jumps over the \"lazy\" dog"

  res2: String = the quick brown fox jumps over the "lazy" dog

  // Beautiful!

  scala> s"the quick brown $fox jumps over the ${'"'}lazy${'"'} $dog"

  res3: String = the quick brown bear jumps over the "lazy" value

The string interpolation spec says:

  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).

But if "the usual escape characters" are the ones in SLS 1.3.6, "EscapeSequences",

then in fact all of the usual escape characters are interpreted, except for

the double quote.  (If "the usual escape characters" are some other set, more

specific identification would be appreciated.) (Or if "are interpreted" means something

other than I am understanding it to mean.)

  1.3.6 EscapeSequences

  

  The following escape sequences are recognized in character and string literals.

  \b \u0008: backspace BS

  \t \u0009: horizontal tab HT

  \n \u000a: linefeed LF

  \f \u000c: form feed FF

  \r \u000d: carriage return CR

  \" \u0022: double quote "

  \’ \u0027: single quote ’

  \\ \u005c: backslash \

Okay, skipping \b since I get a '?' for it:

  scala> "\t\n\f\r\"\'\\"

  res6: String = 

  "

  "'\"

  scala> s"\t\n\f\r\"\'\\"

  <console>:1: error: unclosed character literal

         s"\t\n\f\r\"\'\\"

                      ^

  <console>:1: error: unclosed string literal

         s"\t\n\f\r\"\'\\"

                         ^

  // Removing the \" is enough for it to compile - and produce the same string

  scala> s"\t\n\f\r\'\\"

  res7: String = 

  "

  '\"

So I think there is one bug here, or there are six bugs here, or the specification is misleading me.  I'll throw in this one for good measure, just trying to see if \ is one of the usual escape characters.

scala> s"\"

java.lang.StringIndexOutOfBoundsException: String index out of range: 1

at java.lang.String.charAt(String.java:695)

at scala.collection.immutable.StringOps$.extension$apply(StringOps.scala:39)

at scala.StringContext$.treatEscapes(StringContext.scala:123)

at scala.StringContext.s(StringContext.scala:49)

[√iktor Ҡlang]

IT JUMPS OVER THE LAZY DOLLAR!!!

--
Viktor Klang

Akka Tech Lead

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

[martin odersky]

I think it's an implementation bug (and in addition the SIP could be clearer). The intention is certainly that \" is interpreted as " in interpolated strings.

 - Martin

On Wed, Jul 18, 2012 at 10:02 PM, Paul Phillips <pa...@improving.org> wrote:

--
Martin Odersky
Prof., EPFL and Chairman, Typesafe
PSED, 1015 Lausanne, Switzerland
Tel. EPFL: +41 21 693 6863
Tel. Typesafe: +41 21 691 4967

[Daniel Sobral]

This is a bit confusing, but everything is working. What the
specification means to say is that the string passed to StringContext
won't have any escape processing. However, the two existing
interpolators, s and f, will do escape processing on the string.

The point of this is making it possible to write, for example, a regex
interpolator which accepts plain regex without escape-processing, but
still have s and f process work as if escape characters were there.

The thing doesn't work quite well when it comes to \", and also when
it comes to \\, which would be useful to avoid escaping u (\u), the
only one still processed.

--
Daniel C. Sobral

I travel to the future all the time.

[Daniel Sobral]

On Wed, Jul 18, 2012 at 5:51 PM, martin odersky <martin....@epfl.ch> wrote:
> I think it's an implementation bug (and in addition the SIP could be
> clearer). The intention is certainly that \" is interpreted as " in
> interpolated strings.

Are you sure? All of the escape processing is done at the s and f
interpolators, so \" would have no chance of being processed.

[Paul Phillips]

On Wed, Jul 18, 2012 at 1:53 PM, Daniel Sobral <dcso...@gmail.com> wrote:

Are you sure? All of the escape processing is done at the s and f
interpolators, so \" would have no chance of being processed.

That's good - you don't want \" to be processed by the interpolators.  The backslash is for the quote to survive the scanner.  Its days of being escaped should be over before interpolation begins.

[martin odersky]

On Wed, Jul 18, 2012 at 10:53 PM, Daniel Sobral <dcso...@gmail.com> wrote:

On Wed, Jul 18, 2012 at 5:51 PM, martin odersky <martin....@epfl.ch> wrote:
> I think it's an implementation bug (and in addition the SIP could be
> clearer). The intention is certainly that \" is interpreted as " in
> interpolated strings.

Are you sure? All of the escape processing is done at the s and f
interpolators, so \" would have no chance of being processed.

You are right I overlooked that. \" cannot be interpreted as an escape. 

 - Martin

[Paul Phillips]

On Wed, Jul 18, 2012 at 2:00 PM, martin odersky <martin....@epfl.ch> wrote:

You are right I overlooked that. \" cannot be interpreted as an escape. 

Is there are alternative syntax possible?

[Daniel Sobral]

I assume triple-double-quotes are not enticing?

It would be... interesting... if interpolators also worked with ', so
that s'string with a " inside it' would be valid. However, I'm willing
to wait and see how much actual trouble is having to use """ whenever
I want a double-quote inside an interpolated string.

An alternative would be \" and -- *maybe* -- \\ having special
treatment for single-double-quote interpolators. The latter would
provide a way of handling \u, much as I'd like for \u to just not
having any special meaning at all instead.

[martin odersky]

I don't see one, without creating an ugly special case.

At least you can use triple quotes:

s"""foo""""

Cheers

 - Martin