New SIP-24, backticks in string interpolation

152 views
Skip to first unread message

Kevin Wright

unread,
Feb 8, 2014, 5:35:30 PM2/8/14
to scala-internals

Pull request here:

Looking at the queue though, it seems as though pull requests aren't getting much love.

Would someone suitably acquainted with the current setup be able to glance over the current docs for SIP submission and make sure that they aren't missing any other steps I needed?

Denys Shabalin

unread,
Feb 9, 2014, 6:24:47 AM2/9/14
to scala-i...@googlegroups.com


--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Kevin Wright

unread,
Feb 9, 2014, 8:42:40 AM2/9/14
to scala-i...@googlegroups.com

Jason Zaugg

unread,
Feb 17, 2014, 8:19:47 AM2/17/14
to scala-i...@googlegroups.com
On Sat, Feb 8, 2014 at 11:35 PM, Kevin Wright <kev.lee...@gmail.com> wrote:
I don't see a problem with s"$`a b c`". I'm against the extended proposal, though.

There is another proposal floating around to fill a hole in interpolation: to add a new escape: $"


Kevin, would you like to incorporate that into the SIP so both could be discussed together?

-jason

Kevin Wright

unread,
Feb 17, 2014, 9:03:15 AM2/17/14
to scala-internals
Sure, I can add that :)

I also have another enhanced variant that I've been mulling over,to use guillemets (french/angle quotes) for interpolation.  Some of the examples previously seen would then become:

s"implicit def hlistTupler«arity»[«A..N»] : Aux[«A::N», «(A..N)»] = ..."
s"I am «qual»body"
val `"` = '"'
s"a=«"»$a«"»"
In this form, I'd only allow string-literal identifiers and not full expressions - so as to avoid ambiguity in parsing.

The precedent has already been set for using unicode characters with arrows for lambdas and in comprehensions, so this doesn't seem *too* shocking to me.  There would still, potentially, be a some already featuring angle-quotes in interpolated strings. So even this proposal isn't entirely risk-free.


--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.



--
Kevin Wright
mail: kevin....@scalatechnology.com
gtalk / msn : kev.lee...@gmail.com
vibe / skype: kev.lee.wright
steam: kev_lee_wright

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

Jason Zaugg

unread,
Feb 17, 2014, 9:15:40 AM2/17/14
to scala-i...@googlegroups.com
On Mon, Feb 17, 2014 at 3:03 PM, Kevin Wright <kev.lee...@gmail.com> wrote:
Sure, I can add that :)

I also have another enhanced variant that I've been mulling over,to use guillemets (french/angle quotes) for interpolation.  Some of the examples previously seen would then become:


s"implicit def hlistTupler«arity»[«A..N»] : Aux[«A::N», «(A..N)»] = ..."
s"I am «qual»body"

val `"` = '"'
s"a=«"»$a«"»"
In this form, I'd only allow string-literal identifiers and not full expressions - so as to avoid ambiguity in parsing.

The precedent has already been set for using unicode characters with arrows for lambdas and in comprehensions, so this doesn't seem *too* shocking to me.  There would still, potentially, be a some already featuring angle-quotes in interpolated strings. So even this proposal isn't entirely risk-free.

In my opinion, having a $ before every interpolation is something we should keep. Its consistent with string interpolation from other languages, as is use of ${} when whitespace isn't enough to demarcate the end of the identifier.

-jason

virtualeyes

unread,
Feb 17, 2014, 2:51:57 PM2/17/14
to scala-i...@googlegroups.com
Interesting, I don't have a burning need for backticks, but I'll agree that they are slightly more readable.

However, s"$foo" and s"${foo}" won't surprise new comers (of course s"$foo.bar" will ;-))
Reply all
Reply to author
Forward
0 new messages