> That’s not the same as impossible.
What Julian suggested is not string interpolation. It is runtime code evaluation. Proper string interpolation would not require a separate method call, otherwise you could hack together the same thing in Java using reflection and call it string interpolation.
> Given SC is soft-typed interpreted language, let’s say I find that
argument less compelling than you seem to (same goes with ‘invoking the
interpreter for such a simple task’), but we can agree to disagree I
suppose.
Really? Instead of evaluating your code normally, go try writing it all in a string and calling .interpret on it. What we're discussing is exactly the same dichotomy. No syntax highlighting available. Runtime checking of syntax. The only difference between that situation and this one is that you don't like the syntax here.
> If you’re totally opposed to a method approach I’d prefer InterpString”…”
I definitely wouldn't prefer that variant, unless you intend to also introduce string"...", hexnumber0F877, float0.38, etc. It looks way too much like a new function call notation that way, as you already pointed out, or (thinking about highlighting) looks like a new keyword except with different tokenization rules (interpString".." allowed, but interpString ".." with a space not).
I respect the desire to be straighforward and unobscure in notation. But the tempering principle to that is to make common cases simple. This is a common case. People print things with .format and ++ all the time in SC. Just because you don't use it yet, or wouldn't use it frequently, doesn't mean it deserves a long name. Go look at the Wikipedia article for string interpolation. Most of the variants use a different quote character (', ", `) to allow interpolation. Some (Scala, Python) use a single-letter prefix as we've been discussing. This should not be burdensome for the developer to write or read.
Python is also taught to a lot of non-programmers as a first programming language, and has a (well-earned) reputation as intuitive and easy to pick up. It's not that I'm saying SC should look exactly like Python, but rather that I think they've made many good language design choices and that there's no need to reinvent the wheel.
> At the moment I think a method approach, using the back end Julian mentioned would be most generally useful.
This has none of the syntax highlighting benefits and all of the efficiency and runtime error issues. We are talking about a speed difference in runtime on the order of 100, probably more. Precompiled bytecode vs a full invocation of the interpreter and then evaluation of JIT bytecode. It's an incredibly bad solution to force on people just because you are uncomfortable with new notation. What would be the benefit of Julian's suggestion over .format, overall?
One other thing I wanted to mention while it's on my mind is that this would also set a good precedent from a language syntax perspective if we also decided to add raw strings or unicode string literals. I'm not sure of the top of my head if the latter would arise since it's already possible to insert unicode characters directly into string literals, but raw strings would definitely make life easier for Windows users. IME it's a too-common problem that new users forget about backslashes in their path strings and then have to manually escape each one. With raw strings, you could just write r"C:\Users\me\doc.scd".
-Brian