I don’t know if this is an intended behaviour or not, but just figured out that it’s impossible to use string args inside string interpolation because one cannot correctly specify string:

>>> x := 5.5
>>> "${x}"
5.5 // OK

>>> "${x.toLocale("0.0")}"
ERROR(20): Unexpected end of Str literal, missing }

>>> "${x.toLocale(\"0.0\")}"
ERROR(20): Unexpected symbol: \ (0x5c)

That is by design so that IDEs and text editors can just treat string literals syntactically versus semantically. Work around is to pull it out using concatenation:

"..." + x.toLocale("0.0") + "..."

Well, but if I still can use """${x.toLocale("0.0")}""", what the point of this inconsistency?

I think the problem here is because of "${...}" expression is evaluated before string unescaping is done inside Fantom.

what the point of this inconsistency?

Its a token syntax thing versus a semanatic grammar issue.

Consider a text editor that does color highlighting. It knows that "...." is a string literal. And a good one can be configured so that it knows that """..."...""" is a string literal. For example I do this today in TextPad (one of the editors I use a lot).

But pretty much no editor that wasn't an explicit Fantom IDE would know that this is a single string literal:

"..${"x"}..." 

You would have to understand Fantom's grammar, not just its tokens for that to work.

Brian, sorry for misunderstanding, I actually think that "${x.toLocale(\"0.0\")}" should work, not the another one. Any editor can understand this (i hope :)

Brian, sorry for misunderstanding, I actually think that "${x.toLocale(\"0.0\")}" should work, not the another one. Any editor can understand this (i hope :)

That makes more sense.

But at the same time it doesn't seem right me, too confusing. I think we should force you out of interpolation at that point, otherwise the code becomes insane to read (for example what happens if you want to interpolate a string literal inside a string literal inside a string literal?

I haven't looked at what other langs do either. For example can you do that in Ruby or Python?

I think we should keep interpolation for simple expressions and not worry about how to embed nested string literals.

(for example what happens if you want to interpolate a string literal inside a string literal inside a string literal?

I N C E P T I O N

Ruby allows double-quoted strings inside interpolation directly. E.g.:

"The string is #{"the string".length} characters long"

Editors know, I guess, that #{} marks code.

One solution would be to remove string interpolation and instead use juxtaposition for concatenation (instead of +).

"5 + 5 = #{5 + 5}."   // old

"5 + 5 = " 5 + 5 "."  // new


"The string is #{"the string".length} characters long"

"The string is " "the string".length " characters long"

But that might b hard to read without syntax highlighting so you can see what is a string and what is not.

Umm, isn't it too late to start that now, when triple """ really solve these problems.

But that might b hard to read without syntax highlighting so you can see what is a string and what is not.

I think the problem with that model is that its harder to read. Which is of course subjective, but I really do think its easier to read current way.

Given the extension amount of code using string interpolation, I don't foresee any justification making a breaking change there.

Hi, sorry for reviving old thread.

Is this issue resolved? Is string inside string interpolation allowed?

I'm just playing with something and noticed that if the inner string is prepended by a space, the interpolation works.

"start-${"middle"}-end"   //won't work
"start-${ "middle"}-end"  //but this works

"start-${true?"middle:""}-end"      //won't work
"start-${true ? "middle" : ""}-end" //works

"start-${[1,2,3].join(",")}-end"    //won't work
"start-${[1,2,3].join( ",")}-end"   //works

Not consistent is it? I tried it in fansh, version 1.0.62.

It's low priority I guess, but might introduce other bugs.

I'm going to say we should disallow string literals inside string interpolation. That seems a little to confusing to be worth it.

I didn't even know that worked at all. I agree - its confusing and simpler to disallow altogether.

Promoted to ticket #1479 and assigned to brian

Ticket resolved in 1.0.63

I've made this an error - you can't use a string literal inside a string literal interpolation.