I wrote: I have also been reconsidering percent-sign derefs in quoted strings, as they were primarily an attempt at integrating the "legacy" syntax with expressions and bringing more consistency to the language. Though I'm reluctant to deviate from the v1 expression syntax, I think there are more readable alternatives for variable/expression substitution within strings.
Source: Removal of command syntax
Early v2 alpha builds allowed #DerefChar to specify a starting and ending character, and allowed the ending character to be omitted. The directive was removed because I prefer to not encourage different incompatible syntax variations within the main program, and the ending character requirement was restored to allow expressions within %..%.Chris and others wrote:[...]Code: Select all
var = "The value in x is ""$x""." ; Alternative: Resolve $var inside double-quoted strings ($ seems easier than %%).
The $var approach is attractive because not only is it easier to type than the dual-percent-sign method, the $ character might need to be escaped less often (due to being more rarely used than %). However, if $ seems too confusing or ambiguous (especially for PHP users, who are used to a $ being the mandatory first character in all variable names), the double-percent-sign method could be used instead.
Another thing about the $var method is that it could also be applied to all commands. For example: MsgBox The value in var is $var. However, there would be some ambiguous situations such as $varstring, in which string is intended to be literal text (not part of the variable name). Something like ${var}string could be used in these cases. It's important to verify the rarity these cases because if the braces are needed too frequently, staying with the percent-sign method is probably the better choice.
(Titan: What about an explicit end char like $var;string instead of braces? This goes for RegEx too.)
-> Interesting idea, but it doesn't seem as readable. In fact, it might seem cryptic to anyone unfamiliar with the syntax, not to mention breaking from tradition and thus having more of a learning curve for people going to (or coming from) other languages. On the other hand, it's clearly easier to type. But if the semicolon-or-braces are rarely needed in practice, perhaps the choice between semicolon and braces doesn't matter too much.
Source: AutoHotkey v2
More recently, I implemented Format() based on a mix of .NET (String.Format/Console.Write) syntax and C++ format specifiers. I think that using something balanced like braces makes it easier to discern which parts are the placeholders/variables and which parts are literal.
Even more recently, C# and VB got string interpolation. Instead of String.Format("Name = {0}, hours = {1:hh}", name, hours), you can write $"Name = {name}, hours = {hours:hh}", putting the expression directly into the string, along with the optional format specifier. (I think they were initially planning "Name = \{name}, hours = \{hours:hh}", but later changed it.)
Also recently, JavaScript got template literals: `Name = ${name}, hours = ${hours}`.
For AutoHotkey, plain {} isn't ideal because it's used frequently with Send, and `backquote` isn't ideal because we want to allow escape sequences inside the string (and I don't want to change the escape character). "Name = `{name}" is one idea, but I think it looks especially strange because of the amount of whitespace under the backquote.
I think it's reasonable to use () in place of {}, since expressions are often enclosed in (). But it would probably need to be immediately preceded by another symbol to avoid confusion (as opposed to starting the string literal with a special symbol and then using only () around expressions).
So I'm not set on any particular idea, but considering combinations of methods:
- Using a special character immediately before the quote mark, as with $" ... ", to denote that it contains sub-expressions.
- Enclosing the expression in balanced symbols, like {}, () or [].
- Preceding the enclosing symbols and/or a variable name with a special symbol, such as $, %, or something else.