Fwd: New SIP-24, backticks in string interpolation

[Kevin Wright]

(cross-posed from scala-internals)

The formatted document can be read directly on Github here:

https://github.com/kevinwright/scala.github.com/blob/master/sips/pending/_posts/2014-02-08-backticks-in-string-interpolation.md

Pull request here:

https://github.com/scala/scala.github.com/pull/297

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?

--
Kevin Wright
mail: kevin....@scalatechnology.com
gtalk / msn : kev.lee...@gmail.com

quora: http://www.quora.com/Kevin-Wright

google+: http://gplus.to/thecoda

twitter: @thecoda

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

[Chris Hodapp]

The non-enhanced version seems pretty tough to argue against. I would personally have no problem with the enhanced proposal going through; I don't think I have ever happened to use backticks in an interpolated string. However, the "law of large user bases" does pretty much guarantee that it will cause pain for someone somewhere (not to mention introducing an additional kind of interpolation delimiter to the language, which some may argue is a sort of complexity), so I'm not sure if it makes the most sense.

[Stefan Zeiger]

On 2014-02-13 17:31, Chris Hodapp wrote:
> The non-enhanced version seems pretty tough to argue against. I would
> personally have no problem with the enhanced proposal going through; I
> don't think I have ever happened to use backticks in an interpolated
> string. However, the "law of large user bases" does pretty

Backticks are used to quote identifiers in MySQL, so you'll find them
used in SQL interpolators in Slick, e.g.:

sql"select `foo` from `bar`"

-sz

[Justin du coeur]

Honestly, I find the backticks-only proposal unintuitive.  (Along with having potential edge cases like this.)  By now, I've trained my eyes to interpret $ as the marker for interpolation -- having backticks work without it not only doesn't feel necessary to me, I actually suspect it would hurt my comprehension of the code.

I agree with other folks that the non-enhanced proposal is a clear and obvious win, and should go in -- that's fixing a straightforward hole in the current syntax.  But I don't think the enhanced proposal is nearly so obvious; I think for me personally, I'd view it as a net negative...

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

[Nicolas Passerini]

Reading the document

val qual = "some"
s"I am $`qual`body"

Where short form is invalid because there's no non-alphanumeric character to delimit the identifier from subsequent text:

s"I am $qualbody" //invalid
s"I am ${qual}body" //current solution, but less readable than backticks

I think that the last assertion is questionable. May be I am just used to it, but I find ${qual}body much more readable than $`qual`body".

May be is just that curly braces are more visible than backtics, so it is easier to see the identifier in the interpolated string.

[Som Snytt]

s"I am $`qual`body"

I suggest calling this use of backticks, "scare ticks", by analogy to "scare quotes."

http://en.wikipedia.org/wiki/Scare_quotes

to imply that it may not signify its apparent meaning

or perhaps $care ticks. (It would have been scarier without the dollar sign, of course.)

I'm sorry we won't have "scare guillemets."

Maybe it's worth backporting "$care quotes" for interpolation as a whole.  I got tired of typing the word interpolation.  Since quasiquotes, any interpolator needs a catchy name to break out.

--

You received this message because you are subscribed to the Google Groups "scala-sips" group.

To unsubscribe from this group and stop receiving emails from it, send an email to scala-sips+...@googlegroups.com.

[martin odersky]

I very much agree. And: It's better not to have two different ways for achieving this.

 - Martin

--
You received this message because you are subscribed to the Google Groups "scala-sips" group.

To unsubscribe from this group and stop receiving emails from it, send an email to scala-sips+...@googlegroups.com.

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

--

Martin Odersky
EPFL