question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

syntax for string interpolation

See original GitHub issue

We have received many complaints about the syntax for string interpolation in Ceylon. The double-backtick syntax was chosen because:

  • double backticks are incredibly uncommon in regular text,
  • we thought it looked quite visually pleasing, and
  • it was very easy to lex, and therefore I figured it would be something that would cause less problems in the IDE.

In the end, the last item has not, to my mind, worked out anywhere near as well as I expected, and I think my reasoning on that was flawed.

Today I finally broke down, swallowed my pride and tried my hand at implementing something else. By wrapping the ANTLR token stream, and recursively lexing string tokens, I’ve been able to add support for the following syntax:

print("Hello, \(name)!");

Now, you were probably expecting this to be the more-common ${name} instead of the less-common \(name). So why did I go for something slightly less familiar?

Well, \ is already the escape character in strings, and $ is not. So this is backward compatible. Also, \{...} is already a syntax meaning a unicode escape sequence. So this is unambiguous.

Now, using the exact same technique, I could implement support for either ${ ... } or \{ ... } though the first would not be backward compatible, and the second would be a bit of a fiddle because the syntax would mean different things depending upon what occurs within the braces.

On the other hand, I think \( ... ) looks good.

I will push this to a branch, and I would like to hear some feedback.

Issue Analytics

  • State:open
  • Created 6 years ago
  • Reactions:3
  • Comments:70 (56 by maintainers)

github_iconTop GitHub Comments

7reactions
zamfofexcommented, Sep 4, 2017

To be honest I really prefer the \() syntax. Not only does it use the already well-known \ character for escaping, but it also uses the familiar () for grouping expressions. ${} feels completely alien to the language; I don’t have a strong preference towards either \() or `` when compared to each other, but I do prefer either over ${}.

6reactions
chochoscommented, Sep 4, 2017

If this is the time to break compatibility, then we should go with the more popular ${foo}.

Read more comments on GitHub >

github_iconTop Results From Across the Web

string interpolation - format string output - Microsoft Learn
String interpolation provides a more readable, convenient syntax to format strings. It's easier to read than string composite formatting.
Read more >
String Interpolation In C#
C# string interpolation is a method of concatenating, formatting and manipulating strings. This feature was introduced in C# 6.
Read more >
String interpolation - Wikipedia
In computer programming, string interpolation is the process of evaluating a string literal containing one or more placeholders, yielding a result in which ......
Read more >
Python String Interpolation - Programiz
String interpolation is a process substituting values of variables into placeholders in a string. For instance, if you have a template for saying...
Read more >
Template literals (Template strings) - JavaScript | MDN
Template literals are literals delimited with backtick ( ` ) characters, allowing for multi-line strings, string interpolation with embedded ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found